Cloud27 Aug 2026 · 9 min read
Migrating without a maintenance window
The dual-write pattern we use to move production databases while customers keep transacting.
TZ
The Zaphrix TeamEngineering
In plain terms
You can move a production database with zero downtime, but it costs calendar time, not money you can skip. We run the old and new systems in parallel, write to both, verify the new one is correct under real traffic, and only cut over once shadow reads have matched for as long as it takes to see the client's real traffic patterns.
The core idea
"Can we do this without downtime?" is the first question on almost every cloud migration we scope, and the honest answer is: yes, almost always, but not for free. Zero-downtime migration is a trade of calendar time and engineering discipline for the maintenance window you are trying to avoid. Here is the pattern we default to when we move a production database or re-platform a service onto cloud native infrastructure without taking the system down.
The core idea is dual writes with a verified cutover, not a single big-bang copy. Rather than freezing the application, exporting data, and importing it into the new system during a scheduled window, we run the old and new systems in parallel for a period, writing every change to both, and only redirect reads to the new system once we have proven the two are in sync under real traffic.
Four phases
01Backfill. Copy the existing dataset into the new environment using a snapshot plus a streaming replication or change-data-capture pipeline, so the copy keeps catching up to live writes.
02Dual write. The application writes every mutation to both the old and new systems, synchronously or via a reliable queue, so from this point forward no new data exists in one system but not the other.
03Shadow read. Read from the new system in shadow mode — the response is computed from both systems but only the old system's answer is served — and diff the two continuously.
04Cutover. Once reconciliation has run clean for a representative window, flip reads to the new system, keep dual writes running as a rollback buffer, and decommission the old system only once there's no reason to go back.
Where the time actually goes
The part clients underestimate is the shadow-read phase. Reconciliation is where the actual engineering time goes, because it is where you find every assumption your application made about the old system that the new one does not share: a default value that was implicit in the old schema, a sort order that depended on insertion order rather than an explicit column, a foreign key constraint the old database enforced and the new one does not. None of these show up in a demo migration with sample data. They show up when real customer data, with its real edge cases, flows through both systems side by side. This is exactly why the dual-write pattern is worth the extra weeks — it surfaces those mismatches while the old system is still authoritative and nothing is at risk, instead of after cutover when the new system is live and a data bug is now a production incident.
This pattern generalizes past databases. We use the same shape — parallel run, shadow verification, gradual cutover — for moving monolith services onto cloud native infrastructure behind a service mesh, for migrating authentication providers, and for re-platforming a legacy on-prem deployment onto managed cloud services like RDS, Cloud SQL, or their equivalents. The specifics of the tooling change; the discipline of never trusting a migration until it has been proven under live, shadowed traffic does not.
What it costs, and what it buys
What this costs versus a maintenance-window migration is mostly calendar time and a slightly more complex application layer during the transition — the dual-write logic is temporary scaffolding, not permanent architecture, and gets removed once the old system is decommissioned. What it buys is that customers never see the migration happen at all, and the team gets a real rollback path instead of a prayer.
If a database or infrastructure migration is on your roadmap and a maintenance window is not an option, this is the exact kind of problem our cloud native engineering team scopes as a fixed sprint. Reach out and we can map your system onto this pattern before you commit to a date.
TZ
Written by The Zaphrix TeamEngineering. Written by the engineers who shipped the work.
Keep reading
Free · 30 minutes · No sales deck
Rather talk it through than read it?
Thirty minutes and you'll know the shortest path to the result.