Can you move an AI-built app?
Sometimes, but an export button answers only part of the question. First identify what you are moving: a static marketing site, an app with accounts and records, or a service with payments and background jobs. Each additional service needs its own owner, transfer method, and acceptance check. The inventory below is our planning framework, not a claim that every builder exports all six layers.
Custom-code editing is not an export contract. For a visual website builder, see Dora AI's publishing and export checks: its reviewed older guidance describes custom code, but full-project export and independent hosting remain UNKNOWN. Confirm the actual artifact and a working build outside the platform before planning a move.
This guide is for an app you already have. For an initial product shortlist, use the AI app builder guide; for choosing a replacement specifically for Lovable, use the alternatives guide.
The migration inventory
| Layer | Take with you | Acceptance check |
|---|---|---|
| Source and build | Repository or archive, commit, lockfile, runtime, build command | A clean checkout produces a working build without the old editor. |
| Database | Schema, records, migrations, access policies, backup ownership | An approved sample survives restore and is visible only to the intended account. |
| Authentication | Identity provider, user migration constraints, callback URLs | An existing test identity can sign in; a second account cannot read its private data. |
| Files | Original assets, user uploads, object storage, access rules | A private file stays private and a public asset still loads. |
| Secrets and integrations | Variable names, credential owners, webhooks, schedules | A sandbox integration succeeds without exposing a private key to the browser. |
| Hosting and operations | Runtime, domains, redirects, monitoring, billing, rollback | Critical routes work on the new host and a recovery path has been rehearsed. |
Mark an unused layer as not applicable. Mark an unconfirmed transfer path UNKNOWN, with the next question and the person responsible for answering it. Do not turn a missing answer into a zero-cost assumption. Keep the inventory free of secret values and personal records.
Example: Bolt project files are not a database backup
Bolt documents Export → Download under the project title, which produces a ZIP of project files. It also supports GitHub integration. These are useful source-code paths, but neither a successful download nor a repository connection demonstrates that a complete app works on another host.
The same backup documentation explicitly separates project version restoration from database restoration: going back to an earlier project version does not change the current Bolt or Supabase database. Keep code recovery and data recovery as separate entries in your plan.
Bolt's Supabase guide also distinguishes Claim from Connect. Claim migrates an existing Bolt database into Supabase and requires Supabase organization-owner permissions. Connecting a different database replaces the connection and can cause data loss. Do not click Connect as a shortcut for copying existing records; confirm the supported path and a recoverable backup first.
Example: identify the database behind a Replit app
Replit documents different behavior for current development databases and legacy Neon projects. Identify the actual infrastructure in its database guide before assuming a remix, preview, or separate checkout has isolated data. An editor-level copy should not be your evidence that a test cannot affect production.
If your immediate issue is a broken public URL, first use the Replit publishing checklist. Moving platforms adds variables; it is not a substitute for finding the original failure.
A rehearsal before the domain switch
- Freeze a baseline. Record the source revision and working user journeys. Retain the old service and document how new writes will be handled during a cutover.
- Prepare an isolated target. Use approved test data and separate credentials. Review build and install scripts before executing an unfamiliar export.
- Prove one complete journey. Try sign-in, one harmless record, an upload if applicable, and a refresh. Check permissions with a second test identity.
- Reconcile state. Compare representative records, file access, background jobs, and integration endpoints. Disable duplicate live payment or notification jobs in the test target.
- Authorize the cutover. Only after acceptance, plan the final data sync, domain change, monitoring window, and rollback trigger with the owner.
If the new app accepts writes after the switch, sending traffic back to an old database can hide or lose those writes. Decide in advance whether recovery requires reconciliation, a temporary write freeze, or a forward fix. A DNS change alone is not a complete rollback plan.
When to stop and ask for help
Pause if you cannot restore a backup, do not control a required account, cannot separate test traffic from real customers, or have no supported identity migration path. Export capability and legal rights are also separate: check your agreement and asset licenses before transferring work.
Use Stack Builder to assign responsibility for the backend, deployment, and monitoring layers. Review the Bolt and Replit Agentprofiles for source-backed context, not a tested portability ranking.