failure
The Cutover Is Half Done and Breaking — How Do You Roll Back Without Losing Data?
Stop writing to both systems, establish which checkpoint both sides agree on, and move everything back to that state before diagnosing anything. The instinct to fix-forward under pressure is how half-migrated systems lose records permanently. ExitCanvas's role in this moment is narrower than you might hope but real: it holds the staged plan with its rollback checkpoints, so the question becomes “which checkpoint are we returning to” instead of freeform panic. This guide is for the team already mid-cutover. You can open these pages and sign in to the workspace today. That does not mean ExitCanvas has connected accounts on Bubble, Airtable, Webflow, or whichever platforms your migration touches, and it does not mean the product has formally launched.
Why half-cutovers are dangerous specifically
A completed migration that fails fails visibly. A half-done one fails silently: some records exist in both systems with different values, some exist only in the new one, and every hour of continued operation widens the divergence. The damage compounds through normal usage, not through dramatic errors.
That is why the first moves are about stopping divergence, not finding the bug. Diagnosis before freeze guarantees a larger mess to diagnose.
What you need on hand
Your staged migration plan with checkpoint timestamps, the export taken immediately before cutover began, write logs or recent-change records from both systems if they exist, and the names of whoever can press pause on each connected integration.
If no pre-cutover export exists, stop reading and take one of both systems now, before anything else changes.
Step 1: Freeze writes and announce the freeze
Suspend the sync jobs, put the old system back into read-write if users still touch it, and tell everyone who matters that the system of record is ambiguous until further notice. Ten minutes of frozen writes is cheaper than a weekend of reconciliation.
Step 2: Establish the last agreed checkpoint
Identify the most recent moment both systems provably matched, usually the pre-cutover export or a planned checkpoint. Everything after that point is suspect on both sides, regardless of which system looks healthier.
Step 3: Compare divergent records against evidence
Diff the two systems from the checkpoint forward. Bring the diffs into ExitCanvas to sort them into categories: records only in one system, records conflicting, and records that merely look different through formatting. Ask the planner to rank conflicts by business impact so reconciliation starts where being wrong costs most.
Step 4: Roll back to the checkpoint, or forward past a clean diff
If divergence is wide, restore both sides to the checkpoint and reschedule the cutover with fixes; if divergence is narrow and fully understood, completing the stage may beat rolling back. Either way the decision belongs to the owner, since cutover, cost and security decisions require owner review. Document which path was taken and why.
Proving the recovery worked
After restoring or completing, re-run the comparison from Step 3 and confirm zero unexplained conflicts. Then run the two or three workflows the business cares most about end to end in the surviving system. A recovery nobody verified is a rumor, not a recovery.
Honest limits in a bad moment
ExitCanvas plans and sorts from the evidence you supply; it cannot reach into either platform to freeze jobs or restore data, and connectors to external platforms are not part of this path. Source-platform exports may omit behavior or metadata. A diff built on exports alone can miss logic that broke without leaving a record.
Cutover, cost and security decisions require owner review. Do not promise lossless migration, fixed savings, or zero downtime in your own communications about the incident. Do not claim platform behavior was captured without verification, and do not claim production availability or guaranteed results for the workspace itself.
What ExitCanvas does during recovery
Mid-incident, ExitCanvas is the calm documentarian: it holds the original staged plan, marks which checkpoint you fell back to, organizes the diff findings into ranked categories, and records the rollback decision next to the evidence that justified it.
Afterward, the same record becomes the postmortem's spine. What failed, when divergence started, and which decision restored safety are all written down while memories are fresh.
FAQ
Questions this guide is for
Should we always roll back when a cutover wobbles?
No. Roll back when divergence is wide or unexplained; push forward when the remaining diff is small, fully understood, and owned. The worst choice is deciding by momentum instead of by comparing both systems against a checkpoint.
How long should we keep the old platform alive after migrating?
Until one full billing cycle and one full reporting cycle have run cleanly on the new stack, plus whatever your compliance requires. Cancelling the source platform the day after cutover removes your only escape route.
Can ExitCanvas undo the migration in the platforms themselves?
It cannot act inside Bubble, Airtable, or any external system; there is no such connection. It restores direction: which checkpoint to return to, what diverged, and who decided what.
Start in the workspace
Plan the retry with checkpoints that hold
Sign in or create an account and open the ExitCanvas planner. Rebuild the cutover plan from your exports and notes with a rollback checkpoint at every stage line, so the next wobble has somewhere safe to land.