Database Migration Strategy
The approach for moving data to a new store, which is usually the longest pole and the highest risk in any modernisation.
Application migration is well understood. Data migration is where programmes overrun, because data is large, has history, has quality problems nobody documented, and cannot be rolled back once written.
The approaches, by downtime tolerance:
Big-bang cutover — stop writes, migrate, verify, resume. Simple and only viable where the outage window is long enough for the volume, which for large datasets it is not.
Continuous replication with a short cutover — replicate to the target, keep it synchronised with change data capture, then cut over in minutes. The standard approach for anything of size.
Dual write with backfill — the application writes to both, history is backfilled, reads move when verified. More control, and the dual write must be done through an outbox or an equivalent rather than two independent writes.
What determines success more than the approach:
Verification. Row counts, checksums, and business-level reconciliation — not just "the job completed". This is where silent data loss is caught.
Schema change scope. Migrating and restructuring simultaneously multiplies risk. Move first, restructure after, unless the restructure is the point.
Rollback. Once writes land on the new store, rolling back means reverse migration. That path must exist and be tested before cutover, not designed during an incident.