Going Live with Cutover
Cutover is the irreversible part, so it is built to refuse rather than to proceed. Change capture keeps the target current while your application keeps writing to the source; when you are ready, the stream is drained, both sides are compared in full, and the flip happens only if they are equal. Every stage before the flip can be aborted with nothing changed.
Before you start
- A completed migration with incremental sync (CDC) running and caught up.
- A maintenance or read-only mode you can put the application into.
- A rollback decision made in advance: who calls it, and what they do.
Steps
- 1
Finish a migration with zero-downtime CDC running (Incremental Sync → Start)
- 2
Open the project's Cutover tool — the readiness check shows a go/no-go per precondition
- 3
Put your application into read-only / maintenance so the source stops taking writes
- 4
Start the cutover: it drains the change stream (CDC lag → 0, no new events for the quiet window)
- 5
Verification re-compares every table (row counts + checksums) — the flip only happens if the target provably equals the source
- 6
After the flip the target is authoritative and CDC stops — point your application at the target
- 7
You can abort at any stage before the flip; CDC keeps running and nothing changes
What goes wrong
The source must actually stop taking writes
The quiet window is how the system knows the stream has drained. A background job or a cron that keeps writing will keep resetting it, and the cutover will wait rather than flip a moving target.
Verification failing is the system working
A refused flip means the two sides genuinely differ. Read the table it names — this is the last point at which a divergence costs you nothing.
CDC stops at the flip, by design
After cutover the target is authoritative and the stream ends. If you need to fail back, that is a fresh migration in the other direction, not a resumed stream — plan the rollback as its own path.