Zero-Downtime Cutover
Moving traffic to a new system without an outage, using replication, dual running and progressive traffic shift.
The mechanism is well established and the difficulty is entirely in the details.
The sequence: replicate continuously to the new system so it is current; shift reads progressively, starting with a small percentage, comparing results; shift writes, which is the irreversible step and therefore the one requiring the most preparation; run both for a period with reconciliation; then retire the old path.
What makes it work in practice:
Expand-contract schema changes. Add the new structure, write to both, migrate readers, then remove the old. Never a change that breaks the previous version, because both versions run simultaneously during any progressive shift.
Idempotent writes, since replication and retry mean an operation may be applied more than once.
A tested rollback for each step, and honesty about which step is one-way. Once writes are on the new system, rollback is reverse migration.
Reconciliation running throughout, comparing the two systems continuously rather than checking once at the end.
The scheduling point that is often mishandled: cut over at low traffic but not at an unstaffed hour. The right window is when volume is low and the people who understand the system are awake and available, which is usually mid-morning rather than 02:00 on a Sunday.