01 — Data migration
Moving data. Keeping it correct.
Your application has outgrown its database. Moving the records is easy. What happens to the writes that arrive along the way?
↓ Scroll to change the situation. Use the controls to explore it.
First, stop the world.
One application. One database. Six records to move. Pause writes, take a snapshot, and copy it to a new home. Nothing changes underneath you.
Copy all six records. They match—but the application cannot accept writes for the entire transfer.
Migration controlsBut the application keeps running.
Now keep writes open. Half the snapshot has been copied when record 01 changes from v1 to v2 in the source. The snapshot still holds v1.
Finish the copy. All six records are there, but record 01 is already out of date. A complete copy is not necessarily a current copy.
Migration controlsKeep the changes, too.
Start again, this time retaining every change after the snapshot boundary. Copy the snapshot, then replay those changes in order. This is the idea behind change data capture, or CDC.
Update record 01 during the copy. Finish copying, then apply changes. The target catches up without a second full copy.
Migration controlsCatching up is not switching over.
The snapshot is copied, with two changes still waiting. Even if the target catches up, the next write can put it behind again. Briefly pause source writes, drain the stream, compare the records, then move traffic.
Try catching up while writes are open. Then pause writes and apply the remaining changes. Switching is allowed only at that stable boundary.
Migration controlsThe destination is incomplete.Source record 01: v1 · Destination record 01: —
What this model leaves out
Six records, one sequential writer, one consistent snapshot and an ordered, lossless change stream captured from the same boundary. Each action is one logical step; no action advances automatically. Only record 01 changes. Replay starts after snapshot copying finishes, avoiding old snapshot rows overwriting newer changes. Cutover assumes all writers can be fenced and all traffic can be moved atomically; it ends the simulation. Real migrations also need transaction boundaries, deletes, schema compatibility, retries, validation at scale and a rollback plan. Scene changes start a fresh scenario; reset and reload discard state. This is a visibility model, not a durability or performance claim.
Under the surface
For concrete implementations of snapshots and change streams:
Debezium — snapshots ↗PostgreSQL — logical decoding ↗