What's happening
A base44 workspace move is not irreversible. Moving an app changes only which workspace owns and manages it: the app keeps its ID, data, owner and Base44 address, a connected custom domain stays with it, and it can be moved again. What traps an app is the permission rule. Only the owner of the workspace the app sits in can move it out (on a Business or Enterprise plan, admins can too unless App transfers is restricted), and the person moving it needs an editor role or higher in the workspace it goes to. If you moved an app into a workspace you do not own, that workspace's owner has to move it back: invite them to your workspace as an editor, ask them to run Move app from the app's Overview page, then reconnect any workspace-owned connectors. Rebuild only if that owner cannot be reached.
You moved your base44 app to a different workspace — maybe to share it with a client or a teammate, maybe by picking the wrong entry in the Target Workspace drop-down. Now you want it back, and Base44 will not let you move it. The app looks trapped.
It is not lost. The move did not copy or rebuild anything: per Base44's docs, "Your app's data and settings move with it," and the app owner does not change. What changed is who controls it. The app now follows the target workspace's permissions and settings, draws credits from that workspace, and can leave it only through someone that workspace allows to move apps out.
Why this happens
Base44 treats a workspace as the container that owns and manages an app, and it lets the people who run that container decide when an app leaves. The documented rules for moving an app out:
- You must be the workspace owner to move an app out of the current workspace.
- On an Enterprise plan (Business or Enterprise), workspace admins can move apps out by default. Owners and admins can restrict this under App transfers to workspace admins and owners, workspace owners only, or Disabled. On other plans, only workspace owners can move apps out.
- The person moving the app needs an editor role or higher in the target workspace, and if someone else owns the app, the app owner needs that role there too.
- The Move app option only appears if you belong to another workspace, and purchased apps cannot be moved.
Put those together and the trap is plain. Owning the app does not let you take it out of a workspace you do not own. If you moved your app into a client's workspace, or a teammate moved it into theirs, the only people who can move it out are that workspace's owner and, on Business or Enterprise, its admins. If they have left, will not answer, or have set App transfers to Disabled, the app stays where it is until someone with that role acts. The server enforces the rule; Base44's CLI documentation gives "Only workspace admins and owners can move apps out of this workspace" as an example of the error it returns.
Moving and transferring ownership are separate actions. A move changes the workspace and keeps the owner. An ownership transfer, started from the collaborators panel or the app's Danger Zone, changes the owner, and the new owner must accept it before it takes effect. This page is about the move.
Sources: Base44's guide to managing workspace apps and its workspace move CLI reference (both read 17 Oct 2026).
How to reproduce
Use throwaway apps, not a production one.
- In a workspace you own, create a test app.
- Join a second workspace as an editor, not as its owner.
- From the test app's dashboard, click Overview, open the More actions menu next to View usage, click Move app, choose the second workspace under Target Workspace, and click Move App to confirm.
- Open the app. It has the same Base44 address and the same data, and you are still its owner.
- Try to move it back to your own workspace. The move is refused, because you are not the owner of the workspace the app is in now (or, on Business or Enterprise, an admin there with App transfers allowing admins).
- Ask the second workspace's owner to move it back. It returns with its ID, data and address unchanged.
This shows where the real limit sits: in who may move an app out of a workspace, not in the move itself.
Step-by-step fix
The fix is a second move by someone who is allowed to make it. Rebuilding is the last resort, not the default.
1. Find out who controls the app's current workspace
You need the owner of the workspace the app is in now, or, on a Business or Enterprise plan, an admin there if App transfers allows admins. If you can open that workspace's settings, Settings → Members and groups lists every member with their role. Otherwise ask whoever invited you.
2. If you own that workspace, move the app back yourself
From the app's dashboard, click Overview, open More actions next to View usage, click Move app, pick your workspace under Target Workspace, and click Move App. From a terminal, the Base44 CLI does the same: base44 workspace list shows the workspaces you belong to, and base44 workspace move <workspace-id> --app-id <app-id> moves the app after asking you to confirm. You need an editor role or higher in the workspace you move it to.
3. If you do not, give the owner a role in your workspace
The person who moves the app needs an editor role or higher in the target workspace, so invite the other workspace's owner to yours first. Click your workspace name at the bottom left, then Settings → Members and groups → Invite Members → Invite by email, choose Editor, and send the invite. They must click Accept Invitation before your workspace shows up as a target. Base44's own enterprise onboarding calls moving an app "often a 2-step process" for the same reason.
4. Ask them to move it back
Send them the app's name and ID and the workspace it should return to. They run Move app from the app's Overview page, exactly as in step 2. If you are the app's owner, make sure you also have an editor role or higher in the target workspace, because the move needs it from the app owner too. On a Business or Enterprise workspace, if an admin's move is refused, check Settings → Governance → App transfers: an owner or admin can change who may move apps out.
5. Check what the move left behind
After the move, the app keeps its Base44 address, and a custom domain keeps working if your workspace's plan supports custom domains. The app draws credits from your workspace again and follows its permissions and settings. Some workspace-owned connectors and integrations may need to be reconnected, so test each one once. If the move was made with the CLI's --disconnect-integrations flag, the app's OAuth integrations were disconnected on purpose and need connecting again.
6. Last resort: rebuild in your own workspace
Do this only if nobody who controls the app's current workspace can or will move it. You are still the app's owner, because a move does not change the owner, but downloading the code as a ZIP or connecting GitHub needs a Builder plan or higher, and only app owners can connect an app to a repository. On Free and Starter plans neither route is available — see vendor-lock-in-sdk-dependency.
Export what you can: the code through GitHub or a ZIP, each table's data from the Export action on its card on the Data page, and any custom domain DNS records. Create the app again in your own workspace, recreate the entities, import the data and check that row counts match, then move the custom domain over in a maintenance window, watching for the domain-dns-stuck-pending issue. If the old copy is deleted later, it waits in Recently deleted for 30 days and can be restored, but restoring does not bring back the external resources it released.
DIY vs hire decision
Moving an app back is DIY: it is a few clicks for the right person. The real work is getting that person to act, and giving them an editor role in your workspace first.
Hire help only when a rebuild is unavoidable and one of these applies:
- The app is in production. Cutting over with no downtime means a parallel build, tested thoroughly before the domain switch.
- Data integrity matters. Re-imported data has to be checked against the original, table by table and field by field, before cutover.
- The app has many backend functions. Functions that reference each other rarely work on the first paste.
Hire if a rebuild is the only way out and your app has more than ~5 entities, more than ~3 backend functions, or more than ~100 production users. Otherwise it is a long weekend of careful work.
Need this fix shipped this week?
If the owner of your app's current workspace cannot be reached and a rebuild is the only route left, we handle it as a complex multi-bug fix. Scope includes export audit, parallel rebuild in your own workspace, data integrity validation, cutover plan, and DNS handover. Two-week turnaround for typical apps; fixed-fee.
Order a complex fix or book a free 15-minute call to scope the rebuild.
Related problems
- Data loss after returning to your app — when records really do go missing, rather than moving with the app.
- Bulk deletes at scale — clean up duplicate data in a rebuilt app with
deleteManyand a dry-run count first. - Support tickets sit ignored — how to escalate if you need Base44 support because the workspace owner is unreachable.