Move a live Lovable app: rehearsal and cutover checklist

Use this checklist together with the complete live-migration process. It adds the Lovable-specific decisions. The end state is your application running outside Lovable, with a repository you can develop using other tools.

Identify what you actually need to move

• Lovable Cloud backend: migrate the backend as well as deploying the app outside Lovable. Inventory database, auth, storage, functions, secrets, scheduled jobs, and managed integrations.
• Supabase project you already own: if you are keeping it, move the frontend and its development workflow. A database copy adds unnecessary work. Still test production URLs, auth callbacks, and deployment behavior.
• Moving an existing Supabase backend too: use the full freeze, fresh-copy, and verification sequence below.

Lovable documents code, frontend hosting, and backend as separate parts. Exporting the repository alone does not move every runtime dependency. Keep existing integrations working or replace them before the live move.

0. Rehearse to the preview stage

1. Connect the project’s GitHub repository and record a known working commit. Inventory source services and prepare a separate target Supabase project. Disable destination schedules and use test credentials for external effects before running the copy.
2. Follow the Staticbot Lovable migration guide. When available and supported for your project, use the official Cloud database export. Record its generation time and review which components are outside that export, including file contents and provider settings.
3. Review the chosen path before executing it. The alternative documented path uses a temporary source helper for discovery/export. Source application data and live routing stay in place, but installing a helper is a source configuration change. Confirm an export-only path if your rehearsal must make no source changes at all.
4. Deploy the migrated version only to its preview URL. Keep Lovable’s production settings and the live domain unchanged. Do not merge migration credentials into the branch Lovable publishes.
5. Test existing accounts, permissions, recent records, uploads, functions, and critical workflows. Verify network requests use the target Supabase project. Record transfer time, findings, and the exact fixes to repeat for production.

Prove sign-in continuity. Staticbot’s documented Supabase migration path can preserve password hashes and identities when the source export/access provides them. Lovable’s general external hosting guide describes password-reset limitations for its manual path. Inspect your actual export and test a known account; do not promise unchanged passwords from the builder name alone. Reconfigure OAuth providers, callback URLs, email delivery, and any MFA requirements. Existing sessions may require a new sign-in.

Rehearsal passes when: critical journeys work, no unexplained data differences remain, access controls pass, and every required integration has a tested destination. Fix failures before booking downtime.

1. Prepare a source freeze that you can prove

There is no generic “maintenance page means read-only” shortcut. Write the exact controls for your app in the worksheet. Have a developer or operator prepare and test them before the window.

• Protect all business tables against ordinary client writes while keeping export reads available. Save the original permissions and the reversal procedure. Include storage uploads and deletes.
• Stop writes from privileged functions, service-role clients, scheduled tasks, admin edits, and webhook consumers separately. Supabase service access can bypass row-level security, so changing client policies alone is insufficient.
• Handle sign-ups, profile updates, password changes, and other authentication writes explicitly. Do not assume table policies govern the authentication service.
• Prove an old browser session, the default Lovable URL, and a direct API request cannot still write. Keep source export access working. If Lovable Cloud does not give you the controls needed, resolve that with support or a migration operator before proceeding.

Do not pause or remove the entire Cloud backend as a substitute without checking the consequences: export access and the ability to recover must remain available. Keep the project until the new system has passed its observation period.

2. Execute the live move

1. Notify users with a window, timezone, status URL, and sign-in expectations. Freeze code changes. Prepare target TLS and domain routing, save old DNS records, and agree the abort deadline.
2. At the start, show maintenance on the old app, stop new work, drain in-flight requests, pause writers, and buffer or arrange replay of incoming events. Apply and verify the backend write freeze.
3. Request a new source export after the freeze. Confirm it represents the frozen period; yesterday’s rehearsal export is stale. Capture file inventories and the latest users as well as database records.
4. Run the tested migration into a fresh production target or an explicitly reviewed clean target. Keep copied cron jobs, email sends, and other production effects off. Repeat manual provider configuration and the verified code fixes.
5. Compare source and target data and files. Test login, permissions, functions, and critical journeys against this final copy. Check the target backend URL in the built app, including server-side configuration if applicable.
6. With maintenance still active, switch routing or DNS to the destination and check the real domain through operator-only access. Keep the old origin on maintenance and its backend frozen for clients with cached DNS or old JavaScript.
7. Record approval, enable target production writes, remove maintenance, and resume target jobs and events once. Publish the reopening update and watch errors, logins, and support reports.

If anything fails: follow the recovery procedure. Before new production writes, you can restore the untouched source and routing in a controlled order. After new writes, preserve and reconcile them before any return to the old backend.

3. Choose how you keep building

You can keep using Lovable for ideation, UI changes, and its own previews. Continuous Sync applies each incoming change to your Supabase (destructive SQL pauses for review), builds a separate Staticbot preview of the frontend, and health-checks it. Choose manual approval of that preview or automatic promotion once it is healthy. The promoted version reaches users on your main domain; then the cycle repeats. You can also work in the repository with Claude Code, Codex, or Cursor.

Keep the source frozen through the agreed recovery period. Confirm backups, monitoring, ownership of secrets and billing, and a working release process from your repository. Remove temporary helpers and credentials once no longer needed. Disable old production deployment triggers if you will now develop with Codex, Claude Code, Cursor, or another tool. Continuous Sync is optional if you choose to keep editing in Lovable.

Use the full acceptance checklist before declaring the move complete. Staticbot’s migration status and a healthy homepage do not by themselves prove that your users can do their work.

Let your AI coding agent run the checklist

The live-migrate-ai-built-app and live-migrate-lovable-app skills take Claude Code or Codex through this checklist step by step. The agent runs the Staticbot migrations, deployments, and DNS records, and prepares the Lovable write freeze and its checks for you to apply. It stops for your approval at every phase. What the skill does and how to install it.