Move a live Base44 app: rehearsal and cutover checklist

Use this checklist alongside the complete live-migration process. Native Base44 is more than a hosted database: its SDK, managed login, integrations, and automations may be part of your app’s behavior. A working copy needs those behaviors checked too.

Choose the correct source path

• Native Base44: the app uses Base44 entities and services through its SDK. Staticbot’s migration maps supported behavior onto Supabase using its compatibility layer. Review the compatibility report and known boundaries before choosing a live date.
• Base44 with your own Supabase: identify which features still depend on Base44. If the Supabase backend is staying, you may only need a frontend and integration move. If that backend also changes, use the complete freeze-and-copy process.

0. Rehearse without switching your live app

1. Connect the repository and record the code version. Inventory entities, roles, user-owned records, files, backend functions, integrations, automations, and all app URLs. Choose a separate target Supabase project.
2. Follow the Staticbot Base44 migration guide for your source type. Review discovery and compatibility findings. Resolve any unsupported feature that is essential to daily use before scheduling the move.
3. Before the target can run copied code or jobs, disable schedules and production side effects. Use sandbox payment settings and controlled email delivery. Restrict the preview to your testers.
4. Run to the preview stage and test the migrated app there. Leave production DNS and the source app’s backend secrets unchanged. Any source-side setup or helper required by the selected path must be reviewed separately; do not treat the rehearsal as a live switchover.
5. Verify each role sees the correct existing records. Check create, update, delete, filtering, file upload/download, backend functions, and every critical integration. Confirm requests use the new backend rather than silently continuing to depend on Base44.

Account continuity is different from password continuity. For native Base44, Staticbot’s documented path migrates accounts by email and uses magic-link or email-code sign-in because source password hashes are not available to that path. Test delivery to representative mailboxes, account-to-record ownership, the regenerated login UI, and OAuth providers where used. Prepare support for users who no longer control their registered email. For an existing Supabase source, confirm password preservation with the actual export and a test account.

Tell users about the new sign-in method before the outage. Keeping the same domain does not make this change invisible. Do not send migration sign-in messages to every customer during rehearsal.

1. Resolve the Base44 write-freeze requirement

Changing the homepage or making the app private is not evidence that all writes have stopped. Prepare a specific source freeze with an operator and record how to undo it.

• For native entities, save existing security settings and prepare rules that deny create, update, and delete for normal clients while retaining the export reads you need. Rehearse the controls before the live window.
• Base44’s security documentation states that service-role functions bypass entity rules. Block writes through those functions or pause them and their callers, including webhooks and admin tools.
• Inventory and pause scheduled and event-driven automations. Record pending work and arrange durable buffering or a verified retry/replay method for external events.
• Control managed authentication changes, uploads, integrations, and writes through the default Base44 URL. Entity permissions alone do not establish a freeze across these separate services.
• Test old sessions, direct SDK/API calls, privileged writers, and file operations. Wait for in-flight work to settle. Record what proves each writer is stopped.

Before you continue: if your Base44 plan or app architecture does not expose a way to stop a required writer while preserving export access, stop here. Ask Base44 support or a migration operator to establish a supported freeze. A universal Base44-wide maintenance switch is not assumed or promised by this guide.

For a Supabase-backed app, also follow the Supabase write-freeze considerations; Base44 integrations can remain writers even when ordinary database clients are blocked.

2. Make the live move after the rehearsal passes

1. Announce the maintenance window, timezone, status channel, and any login change. Prepare domain routing and target TLS. Save current settings and set the abort deadline. Freeze code changes.
2. Show maintenance, stop new work, drain in-flight operations, pause automations, and activate the verified source write controls. Check the default builder URL and old sessions as well as your custom domain.
3. Take a fresh extraction of entities, users, and files after the freeze. Verify export pagination and totals, plus ownership mappings and the latest records. Save the final source timestamp and inventories.
4. Run the rehearsed migration against a fresh production target or a reviewed clean target. Do not append the final data to rehearsal edits. Keep target integrations and automations inactive until cutover approval.
5. Repeat compatibility and business checks on the final copy: accounts and roles, data ownership, sensitive-field access, files, functions, payments, and replacement services. Test email-code or magic-link login and OAuth on the intended domain.
6. Switch routing or DNS while maintenance remains on. Verify HTTPS, deep links, and the destination backend on the real domain. Keep the source frozen for clients still using old DNS or browser bundles.
7. Approve reopening, enable target writes, and resume jobs and queued events on the target only. Use duplicate protection when replaying events. Announce completion with the tested sign-in instructions.

If checks fail, use the shared recovery procedure. A DNS reversal after target writes is not a data rollback. Preserve new activity and agree reconciliation before reopening on the old source.

3. Choose how you keep building

You can keep using Base44 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.

During the observation period, watch authentication, missing records, failed integrations, and support messages. Confirm that files and runtime services will still work after Base44 is retired: a copied URL that still points to Base44 is not an independently hosted file.

Hand over the repository, deployment workflow, backup/restore process, and service credentials. Verify one change using your new development tools. Retire Base44 only after the agreed recovery period and dependency checks; remove migration access and stale data copies. Keep Continuous Sync only if you intentionally continue editing in Base44.

Download the worksheet to record every owner, stop/go decision, and verification result. Staticbot provides migration and preview tooling; the full live cutover is coordinated with these manual steps today.

Let your AI coding agent run the checklist

The live-migrate-ai-built-app and live-migrate-base44-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 Base44 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.