Transfer an app to another workspace

Built an app in the wrong workspace, or handing a finished tool to a client? A transfer moves the whole app to a workspace the recipient manages. The app stays online the entire time.

How it works

1. 1

   Send the request

   In the builder open Settings → Danger zone → Transfer app, enter the email of an owner or admin of the receiving workspace, and add an optional note. Only workspace owners and admins can send.
2. 2

   They accept

   The recipient gets an email link. After signing in (or signing up) they pick which of their workspaces receives the app — or create a new one — and accept. Requests expire after 7 days; either side can cancel or decline before then.
3. 3

   Done

   The app now lives in the receiving workspace. Builders in the sending workspace lose access; app users keep theirs.

What moves

• The app definition, its version history and settings.
• Its data sources — EmberDatabases, connected Postgres databases and Airtable bases — with their data. Credentials are re-secured under the new workspace.
• App users and their roles (they are matched by email, so nothing changes for them).
• Public links, workflow history, notifications and connector connections.
• Uploaded files — URLs stay the same.

A published app stays live at the same /a/<slug> address throughout, and scheduled workflows keep running.

Plan limits on the receiving side

Accepting is checked against the receiving workspace's plan: published apps, rows per database, and file storage. If the app would push it over a limit, the accept button explains which one and links to billing; the request stays open until it is resolved or expires. The sending workspace is never checked — its usage only goes down.

While a transfer is pending

The app stays fully editable in the sending workspace, with a banner in the builder. Whatever the app looks like at the moment of acceptance is what moves. One request can be pending per app at a time.