How to move a live app off Lovable or Base44

Moving production out of an AI builder gets more consequential once people depend on what you built. A successful move means people can still sign in, find their records, and finish their work. It also means you can keep using Lovable or Base44 to develop and preview changes, or switch to other tools using your own repository.

Staticbot handles the migration and provides a preview of the migrated app. Someone still needs to tell users what’s happening, stop changes to the old system, check the result, switch the domain, and keep an eye on the app afterward. This guide walks through those steps. All of them need to be done before you reopen the app.

Choose your builder’s checklist

• Lovable: Cloud export or an existing Supabase backend
• Base44: native entities and auth, or an existing Supabase backend

These guides assume a planned downtime window is acceptable and that you can block every source of writes. If your app already uses a Supabase project you own and you are keeping that backend, you may only need to move hosting. Inventory the app before deciding to copy a database.

0. Run a test migration while the live app stays live

1. List what must keep working. Include sign-in, account roles, important records, uploads, payments, emails, scheduled work, integrations, and your most important user journeys. Pick test accounts with different roles.
2. Create a separate target. Use a Supabase project you own for the rehearsal. Confirm its project ID is different from production. Keep the live domain and the source app’s backend settings unchanged.
3. Prepare an isolated preview. Disable copied schedules and production side effects before allowing the target to run them. Use payment sandbox credentials and an email test sink, and disable outbound webhooks. Restrict preview access and keep it out of search indexes; an unlisted URL is not access control.
4. Run Staticbot to the preview stage. Follow the builder guide, review the migration findings, and open the resulting preview URL. Confirm its requests go to the target backend. Do not update source builder secrets, merge a branch that repoints the live app, or change DNS.
5. Test and record the outcome. Sign in, inspect existing records, create and edit test records, upload and retrieve a file, and test access with two different accounts. Record failures and fixes. Measure export, transfer, and verification time.

What “safe to try” means: the rehearsal copies into a separate target and leaves your live traffic and source application data in place. Some documented migration paths install a temporary source-side helper function. Review that setup and its removal; it is a source configuration change. If you require absolutely no source changes, confirm an export-only path for your app before starting.

A rehearsal copy may be older than production by the time you finish testing. It proves compatibility, not that the target contains the final live state. Resolve every critical failure before scheduling the move. If copied schedules cannot be disabled before they run, fix that isolation problem before proceeding with the rehearsal.

1. Prepare the maintenance window

Decide who will make the call to continue or stop. Name who controls the source, target, domain, and user communications—even if that is all you. Keep an independent status page or support channel available while the app is down.

• Record the tested code version, source and target IDs, export method, critical integrations, and unresolved findings. Freeze code changes during the live move.
• Write down how to block each source writer and how to restore its previous settings. Include browser clients, old open tabs, the builder’s default URL, direct APIs, uploads, sign-ups, admin tools, background jobs, and incoming webhooks.
• Prepare the destination hostname and TLS certificate. Save current DNS records. If switching DNS, lower the relevant TTL ahead of time and wait out the previous TTL before the window. Leave mail and unrelated DNS records alone.
• Rehearse the maintenance page and operator-only access to the destination. Prefer serving maintenance at the existing domain through your current routing layer, so maintenance itself does not depend on a second DNS change.
• Set the window using measured timings plus a buffer for verification and recovery. A “15-minute migration” estimate is not a downtime guarantee. Set a deadline for aborting before reopening.

Notify users in advance: start and expected end time with timezone, which actions will be unavailable, where updates appear, and whether they will need to sign in again. For an internal tool, also agree how urgent work will be handled during the pause.

We’re moving [app] to new infrastructure on [date], from [start] to [expected end, timezone]. Please save your work before [start]. The app will be temporarily unavailable. Your usual address will stay the same. [Explain any sign-in change.] Updates: [status URL]. Help: [support contact].

For a short whole-site outage, serve a temporary maintenance response with HTTP 503 and a sensible Retry-After value. Avoid permanent redirects for maintenance. Keep the page useful: what is happening, when the next update will arrive, and how to reach support. See Google’s guidance on temporarily pausing a site.

2. Stop new work, then prove writes have stopped

At the announced start, show maintenance and stop new work. Let in-flight operations finish within a bounded drain period. Pause schedules and background workers; arrange durable buffering or a verified provider retry/replay path for incoming events. Do not acknowledge a webhook as successfully processed if you have discarded it.

Then enforce the source write freeze at the backend and every privileged writer. Keep the read access needed for export. Include files and authentication changes, not just business tables. A frontend maintenance screen cannot stop a previously opened browser tab from calling the old backend.

Evidence required: use a designated test record to attempt a write from an old session and a direct API client; confirm it is rejected. Check scheduled jobs, admin/service-role paths, uploads, and event consumers separately. Wait for in-flight work to settle and record the final source timestamp and relevant counts. Stable counts alone do not prove a freeze: updates can change values without changing the number of rows.

Stop if any writer remains uncontrolled. Do not take the final copy while hoping users will stay away. Neither builder has a universal write-freeze procedure assumed by this guide. Your exact control must be documented and proven during preparation, with technical help where needed.

3. Take the final copy and migrate

Once the source is quiet, capture a fresh export and file inventory. Record which source, time, and code version they belong to. Preserve a recoverable source backup and the original routing and configuration. All components must represent the same frozen period.

Run the rehearsed Staticbot migration with that fresh state. Use a fresh production target or a specifically reviewed reset procedure for the rehearsal target. Do not blindly import over test writes, append the final export, or assume rerunning a partially completed job is safe. Keep destination schedules and outbound effects disabled.

Check the migration report for missing or failed components. Resolve errors and rerun the relevant checks before continuing. The source remains frozen, and users remain on maintenance throughout transfer and verification.

4. Verify the result before opening it

Staticbot’s preview and available health checks are a starting point. You still need to check that people can do their work in the app. Save the evidence for each check against the final copy, even if the rehearsal passed.

Write down whether the app is ready to reopen, and who checked it. Missing records, failed sign-in, broken access controls, unexplained differences, or an unproven source freeze are reasons to stop. Decide whether to continue within the window or use the pre-opening recovery procedure below.

5. Switch the domain, then reopen deliberately

While maintenance remains visible, switch the routing layer or the relevant DNS records to the destination. DNS points a hostname at a destination; it does not redirect an already running app’s API calls. Verify HTTPS and backend requests using the real production domain through operator-only access.

Allow for clients that still resolve the old address. Keep the old origin on maintenance and its backend frozen. Invalidate stale frontend caches where you control them and account for service workers and old browser sessions. Preserve the domain and important paths; changing hosts does not require changing customer bookmarks.

Once the owner approves, enable target writes and remove maintenance. Resume integrations and jobs on the target only, in a recorded order. Replay queued events with duplicate protection. Record the moment the target becomes authoritative. Tell users the app has reopened, including any sign-in instructions.

The goal is the same familiar app at the same address. A brief outage and a new sign-in may still be visible to users, especially when moving native Base44 accounts. Set that expectation before the move.

Recovery changes once real writes reach the target

• Before target production writes: keep maintenance on, stop destination jobs, restore source routing if it changed, verify the source, then restore source write permissions and jobs. Replay held events to the source exactly once before declaring recovery complete. Account for DNS caches at both origins.
• After target production writes: put the app back into maintenance and preserve the target’s new records and events. Fix forward where possible. Returning to the old database requires a deliberate reconciliation of new, changed, and deleted records and external side effects. Simply pointing DNS back can lose customer work.

Keep a recovery deadline and escalation contact in the checklist. If the move overruns, publish a revised update instead of letting the promised reopening time pass silently.

6. Watch real use and hand over ownership

Monitor sign-in failures, application errors, uploads, payments, webhook backlogs, and support reports through an agreed observation period. Check at least one normal business cycle, including scheduled jobs. Confirm target backups and a restore procedure before retiring the source.

Keep the old system frozen for the agreed recovery period, then remove temporary helpers, revoke migration credentials, and securely retire obsolete copies. Record who owns billing, backups, domains, monitoring, and incident response.

Make a small change from your chosen development tool, deploy it to a preview, and verify the new release process. If you are leaving the builder, disable its production deployment triggers. Continuous Sync is optional for teams that keep using the builder; it is not a substitute for the write freeze or database CDC in this process.

After migration: keep your builder, with a preview before every release

Moving production does not require leaving Lovable or Base44 as your development tool. Use the builder for ideas, UI changes, and its familiar preview. Continuous Sync then carries those changes through your connected repository into Staticbot’s release workflow.

1. Build and preview in Lovable or Base44. Iterate until you are happy with the direction.
2. Review a Staticbot preview on the migrated stack. Staticbot applies database and function changes to your Supabase (destructive SQL pauses for your review), builds a new frontend preview, and health-checks it.
3. Choose promotion. Manually review and approve the checked preview (the default for migrated apps), or enable automatic promotion of healthy previews. An unhealthy preview is never promoted.
4. Serve the promoted version on your main domain. Return to your builder for the next change and repeat the cycle.

This preview and promotion pipeline is available today. It is distinct from the one-time live migration described above, whose maintenance window and source write freeze still need coordination. See the illustrated Continuous Sync workflow. You can also work in the repository with Claude Code, Codex, or Cursor; those changes go through the same preview and promotion.

What Staticbot does today, and what you coordinate

Staticbot provides the supported migration pipeline, compatibility findings, target deployment, preview, and available health checks. The exact transfer scope depends on the source and findings. You or your migration operator own the maintenance window, user updates, source write controls, acceptance evidence, traffic switch, recovery decision, and aftercare. These steps form the first complete workflow around the tool.

Supported Migration provides the assistance described in its current scope. It does not automatically include someone operating a live cutover. Agree any additional coordination and responsibilities before scheduling the window.

Download the migration worksheet and go/no-go checklist. Start with Lovable or Base44, complete the rehearsal, and only then choose a live date.

Run the cutover with your AI coding agent

The live-migrate-ai-built-app skill turns this guide into a session with Claude Code or Codex. The agent uses Staticbot’s tools for the migrations, deployments, and DNS records, and prepares everything else for you: the cutover plan, user notices, the write-freeze steps for your builder, and the checks that prove writes have stopped. It stops for your go or no-go at each step.

• Test migration first. It migrates to a separate Supabase project, shows the preview findings, and records timings to size your window. It never picks the backend switchover that repoints your live app.
• Maintenance page and domain. Days before the move, it deploys your production site with Staticbot, which issues and renews the TLS certificate for you, and loads a maintenance version onto it. At the start of the window your domain moves to Staticbot once. Reopening swaps the maintenance version for the tested app, with no second DNS change. The records depend on your app: a Cloudflare custom hostname for full-stack apps, AWS CloudFront for static sites. If your DNS is on Cloudflare and connected, Staticbot writes the records after you approve; otherwise the agent gives you the exact records to enter.
• Builder-specific write freeze. For Lovable, it prepares SQL that stops writes but keeps export reads working, a check to prove it, and a step that removes the freeze from the new database, since a fresh export carries the freeze with it. For Base44, it takes Staticbot’s snapshot of your security rules before you lock down writes, so the new app keeps its normal permissions.
• A state file you can resume from. Every ID, saved DNS record, check result, and decision is written down, so a long evening does not depend on one chat session.

Some steps still need you: applying the freeze inside Lovable or Base44, editing DNS at a registrar Staticbot is not connected to, and sending notices to your users. The agent prepares each one and waits for you to confirm.

Install it with the other Staticbot skills, together with live-migrate-lovable-app or live-migrate-base44-app, then ask: “Use $live-migrate-ai-built-app to plan the live cutover of this app. Start with a test migration and stop for my approval at every phase.”

Enterprise: minimize downtime with a custom migration

If a planned outage is not acceptable, talk to Staticbot about an enterprise engagement. The approach is blue-green migration with CDC: prepare a separate destination, capture source changes while production stays live, reconcile the two, then coordinate the final switch. Feasibility depends on source access and replication support, including how files and authentication are handled. This is custom engineering scoped per project, not a self-service feature or a universal zero-downtime guarantee.