Zero-downtime database migration with the dual-write pattern

Migrating a database without downtime almost always comes down to the same core pattern: write to both the old and new systems simultaneously, verify they agree, and only then cut reads over. It sounds simple. The details of doing it correctly are where most of the risk actually lives.

The pattern

During the migration window, every write goes to both the legacy database and the new one. Reads continue to come from the legacy system while the new one builds up a verified track record. Once the two systems have agreed on enough real production writes, reads move to the new system too, with the legacy system kept as a fallback until confidence is fully established.

Where it gets hard

Dual writes have to handle partial failure: what happens when the write to the new system succeeds but the write to the old one fails, or vice versa? Without a clear reconciliation strategy, dual-write can quietly introduce the exact data inconsistency it was meant to prevent. This is usually solved with an idempotent write log and a reconciliation job that catches and replays anything that didn’t make it to both sides.

Verifying agreement, not just presence

It’s not enough to confirm both systems received a write — you need to confirm they represent the same state. That means comparing actual query results between old and new, not just checking that a write didn’t error. Any drift needs to be understood and fixed before cutover, not treated as noise.

When dual-write isn’t the right tool

For very high write-volume systems, running two databases in parallel can be expensive, and for systems with complex multi-step transactions, keeping both sides consistent gets substantially harder. In those cases, a different verification strategy — like replaying a production traffic sample against the new system before it goes live — may be a better fit. The goal is always the same regardless of pattern: never trust a migration you haven’t verified against real data. For what “verified” actually has to mean before you cut over, see how to prove a data migration is correct before you flip the switch.