# Live migration worksheet

Complete this with your app owner and migration operator before setting a live date.
Process: https://www.staticbot.dev/blog/live-app-migration
Lovable: https://www.staticbot.dev/migration-guides/lovable-live-migration
Base44: https://www.staticbot.dev/migration-guides/base44-live-migration

## Ownership and scope

- App / existing domain:
- Source builder and architecture (Cloud / native Base44 / own Supabase):
- Source project ID / rehearsal target ID / final target ID:
- Code commit and production deployment branch:
- App owner (acceptance and reopening):
- Operator (maintenance, source, target, domain):
- Support and escalation contact:
- Independent status URL:
- Critical workflows / roles / test accounts:
- Known compatibility gaps and agreed resolutions:

## Step 0 — rehearsal acceptance

- [ ] Source and target are different projects; production domain/settings stay unchanged.
- [ ] Any source helper installation/removal is recorded and reviewed.
- [ ] Target schedules, triggers and external effects are controlled before they can run.
- [ ] Payments use sandbox settings; email recipients and outbound webhooks are controlled.
- [ ] Preview access is restricted; it is excluded from search indexing.
- [ ] Requests go to the target; no unintended source or builder dependency remains.
- [ ] Login methods, account ownership, roles and private-data isolation pass.
- [ ] Critical workflows and file operations pass.
- [ ] Data differences and compatibility findings are resolved or explicitly accepted.
- [ ] Export, transfer, configuration and verification timings are recorded.
- Preview URL / evidence / findings / accepted by / date:

## The write-freeze plan — fill every row

For each writer, name its exact control, owner, proof that writes fail, export-read exception, and reversal procedure. “Maintenance page” is not a backend control. If any required writer cannot be controlled, stop and obtain a supported procedure before scheduling.

| Writer | Control and owner | Evidence / failed-write probe | How to restore |
| --- | --- | --- | --- |
| Existing browser sessions / default builder URL | | | |
| Direct client API / SDK calls | | | |
| Privileged functions / service-role clients | | | |
| Scheduled jobs / automations / admin tools | | | |
| Storage uploads / updates / deletes | | | |
| Auth sign-ups / profile or password changes | | | |
| Webhooks / payments / external integrations | | | |

- In-flight drain timeout and completion evidence:
- Durable queue or provider retry/replay plan (including retention and deduplication):
- How export reads remain available:
- Source permissions/configuration backup and restoration procedure:

## Window and communications

- Date, start/end and timezone:
- Measured estimate + verification/recovery buffer:
- Abort deadline before reopening:
- Maintenance control and operator-only target access:
- Original DNS records / old TTL / time TTL was lowered:
- Target records / hostname verification / TLS readiness:
- Source and target behavior for clients with stale DNS / old bundles:
- [ ] Advance notice sent; login changes explained; users asked to save work.
- [ ] Maintenance response and independent status channel tested.
- [ ] Code and deployment changes frozen for the window.

Advance notice: “We're moving [app] on [date], [start–end, timezone]. Please save work before [start]. [Unavailable actions]. Your usual address stays the same. [Sign-in change]. Updates: [URL]. Help: [contact].”
Maintenance: “[App] is temporarily unavailable while we move it. Next update: [time, timezone]. Updates: [URL]. Help: [contact].”
Delay: “The move needs additional checks. The app remains unavailable. Next update: [time, timezone]. [Known impact and support contact].”
Completion: “[App] is available again at [domain]. [Sign-in instructions]. Contact [support] if anything is missing or not working.”

## Live execution — record the time and results at each step

- [ ] Maintenance on; new work blocked; in-flight work drained.
- [ ] All source writers frozen and verified, including auth and storage.
- Source writes stopped — timestamp / evidence / operator:
- [ ] Fresh final export and file inventory captured after source writes have stopped.
- Export source ID / timestamp / artifact / code commit:
- [ ] Recoverable source backup and old configuration retained.
- [ ] Fresh target or reviewed clean-target procedure used; no rehearsal data mixed in.
- [ ] Final transfer completed; errors and skipped components reviewed.
- [ ] Destination jobs and external effects remain controlled.
- [ ] Counts, key totals, IDs, relationships, latest records and files reconcile.
- [ ] Login, permissions, critical journeys, integrations and callbacks pass.
- Final copy checked and accepted / evidence / owner / time:
- [ ] Routing switched while maintenance stays on; real domain, TLS and backend checked.
- [ ] Old origin stays on maintenance; old backend remains frozen.
- Approval to enable target writes and reopen / owner / time:
- [ ] Target writes enabled; maintenance removed; jobs resumed on target only.
- [ ] Queued events replayed with duplicate protection and reconciliation.
- Target authoritative from (include the first external-event write):
- [ ] Completion update sent; monitoring and support active.

## Recovery decision

Before target production writes: keep maintenance on, stop target jobs, restore old routing if needed, verify the source, restore source permissions/jobs, and replay held events once. Account for cached routes on both origins.

After target production writes: enter maintenance again, preserve new target activity and external-event records, and investigate. Prefer a forward fix where practical. Do not reopen the old database until new/updated/deleted records and external effects have a reviewed reconciliation plan.

- Recovery decision-maker and deadline:
- Exact pre-opening recovery procedure:
- Post-opening reconciliation owner and escalation:
- Incident record / data preserved / decision / time:

## Aftercare and handoff

- Observation period and normal business cycle to cover:
- [ ] Login failures, application errors, files, payments and event backlog reviewed.
- [ ] Source remains frozen during the agreed recovery period.
- [ ] Target backups and restore procedure verified.
- [ ] Repository, deployment, billing, domain and monitoring owners recorded.
- [ ] One change released through the chosen development workflow: builder preview, Staticbot preview and health check, then manual approval or automatic promotion to the main domain; or the agreed direct-repository workflow.
- [ ] Old builder production triggers disabled if leaving it.
- [ ] Temporary helpers and migration credentials removed when no longer needed.
- [ ] Source retirement and rehearsal-data deletion scheduled after acceptance.
- Final acceptance / unresolved issues / owner / date: