Move a workspace to another account

You can move a workspace from one account to another. This is useful when you built a workspace for a client and need to hand it to their account, or when you signed up twice and want your work in one place.

The workspace keeps its ws_ id, its projects, members, secrets, history and API keys. It stops using everything the old account lent it: shared connections, account admins, team access and settings inherited from the account. After the move, a Finish moving this workspace checklist on the workspace's overview page lists what to reconnect.

Who can move a workspace

• You must own both accounts. You need the account owner role on the account the workspace is in and on the account it is moving to. Being an account admin is not enough, because a move changes who controls the workspace and who pays for it.
• The destination must be on a paid plan, with an active or trialing subscription. The account the workspace leaves can be on any plan, including Free.
• The destination must have room for the workspace under its limits: workspaces, members (the workspace's members count as new seats), projects, managed repositories and brokered secrets.
• A person must do it, signed in within the last 15 minutes. An API key, service principal or agent cannot move a workspace.

From	To	Allowed?
A standard account, any plan	A standard account on a paid plan	Yes
An openproduct account	A standard account on a paid plan	Yes. The workspace becomes private first.
Any account	A standard account on the Free plan	No. Upgrade the destination first.
Any account	An openproduct account	No

Only workspaces move. An account itself cannot be moved.

When a workspace cannot move

The move is refused, with the reason, while:

• the workspace is archived, scheduled for deletion, or under legal hold;
• a deploy, agent session or managed run is in progress (the refusal lists them);
• another move of the workspace is in progress;
• the workspace moved in the last 30 days.

One exception to the 30 days: you can move a workspace straight back to the account it just left within 24 hours, once, to undo a mistake. This does not reset the 30 days.

Move a workspace

In the console

1. Open the workspace's Settings page. Under Move to another account, next to Archive and Delete, click Move….
2. Pick the destination. Only accounts you own are listed. An account that cannot take the workspace is greyed out with the reason, for example a Free plan.
3. Review what changes: the new address, the connections that stop working, who loses access, settings no longer inherited, what is kept, and how this month's usage is billed.
4. Confirm. Type the workspace's slug and give a reason. If the slug is already taken in the destination, choose a new one. If it has been more than 15 minutes since you signed in, you are asked to sign in again.
5. You land on the workspace's new overview page, where the checklist is waiting.

With the CLI

orun-cloud workspace move <workspace> --to <account>

<workspace> takes a ws_ id, account~workspace, or a slug. The CLI prints the same review, asks for a reason, and asks you to type the workspace's slug. Useful flags:

• --dry-run prints the review and stops.
• --new-slug <slug> renames the workspace when its slug is taken in the destination.
• --yes-make-private accepts that an openproduct workspace becomes private.
• --reason <text> and --confirm <slug> answer the questions for scripts. With --output json both are required, and the CLI never prompts.

The CLI signs in with a pasted token, so it cannot ask you to sign in again in a browser. If your sign-in is older than 15 minutes, sign in to the console again, run orun-cloud login with a fresh session token, and run the command again.

What moves and what stays

	After the move
ws_ id, projects, config, secrets, history, audit log	Kept, unchanged
Members and their workspace roles	Kept
API keys and service principals	Kept, and keep working
The workspace's own model and sandbox keys	Kept
Connections from the old account (GitHub and others)	Cut off. Reconnect them from the checklist.
Repository links on those connections	Unlinked, and relinked when you reconnect
Account admins and team access from the old account	Removed
Pending invitations and join links	Revoked. Reissue them from the checklist.
Settings and secrets inherited from the old account	No longer inherited. The destination's account settings apply instead.
Prepaid credits, subscription, billing history	Stay with the old account
An app's chat (orun.work)	Stays with the old account

Finish moving this workspace

The checklist on the overview page is worked out from the workspace's current state each time you open it, so it ticks off items you fix anywhere, for example on the Connections page. For each connection that was cut off it offers one of:

• Use the new account's connection, when the new account already connects to the same provider account. One click grants it to the workspace and relinks the repositories.
• Move this connection to the new account, when the old connection was used only by this workspace.
• Connect, which starts the normal connect flow in the new account. When it finishes, use the one-click relink on the checklist.

The card goes away when every item is done. An owner or admin of the workspace can also dismiss it.

Addresses and links

Console addresses include the account, so the workspace's address changes, for example from /rahul/storefront to /acme/storefront. Old addresses redirect to the current one forever, including bookmarks and links in old emails. The one exception: if the old account later creates a new workspace with the same name, that address belongs to the new workspace and stops redirecting.

API calls that use the old account~workspace address keep working for reads, and the response carries a Workspace-Moved-To header with the new address. Writes to the old address are refused with 409 workspace_moved, so update scripts that write to a workspace by its address. Calls that use the ws_ id are not affected.

Billing

Usage in the current billing period is split at the moment of the move. The old account pays for usage before it and the new account for usage after it, so the workspace appears on both accounts' statements for that month. Credits and subscriptions belong to the account and do not move.

openproduct workspaces

An openproduct workspace is public, and only an openproduct account can hold a public workspace. So moving one into a standard account makes it private first, and that cannot be undone. Its pages on openproduct.live are taken down and it stops being listed. Members keep their access. You are asked to confirm this before the move.

If an openproduct workspace's repository has gone private, the warning band at the top of the workspace offers Move to a paid account when you own a standard account to move it to. Moving it clears the warning.

Both accounts are told

The move is recorded in the audit log of both accounts, and the owners and admins of both accounts get an email saying where the workspace went and who moved it.