Migrating live data without downtime: the parallel-run pattern

The scary part of any migration isn't moving the data — it's that the business keeps operating while you do. The pattern that works is parallel running: replicate data to the new system, keep both in sync, and move traffic in small slices with a rollback that's one command, not a restore-from-backup prayer.

The setup matters more than the cutover. Dual writes (or a change-data-capture stream) keep both systems current; a reconciliation job compares records hourly and reports drift; and the DNS TTL gets lowered days before cutover so traffic shifts are minutes, not days. If any of these three can't be built, the migration isn't ready.

Cutover by slice: internal users first, then one region or one store, then the rest — with a checkpoint after each slice. Every slice has a defined rollback: flip the flag back, and the old system picks up exactly where it left off. Practice the rollback in staging until it's boring.

The last mile is the honest one: freeze a write window only for the final delta (usually minutes), reconcile one last time, and run both systems read-only in parallel for a week as insurance. Migrations fail from impatience far more often than from technology — the parallel run is how you buy the patience.