Zero-downtime modernization gets sold as a deployment capability, as though it were something you switch on at cutover. It is not. It is the consequence of constraints applied months earlier, mostly around how data is written and how change is released. Teams that adopt those constraints find the cutover is uneventful. Teams that do not end up scheduling a maintenance window and hoping.
01Dual writes come before everything
Until both systems hold the same data, nothing else is possible. That means writing to the old and the new store simultaneously, well before any read traffic moves, and reconciling continuously rather than at the end.
The reconciliation is the part teams underestimate. Divergence is normal early on and each cause has to be found and fixed. A migration where reconciliation has never been clean is not ready to cut over, regardless of what the project plan says.
02Reads move before writes, in percentages
Once data agrees, shift a small fraction of read traffic to the new path and compare responses. Reads are safe to move because a wrong answer can be discarded; a wrong write cannot.
Only after reads are stable at full volume does write traffic move, and it moves the same way - a percentage at a time, with the ability to shift back within seconds.
| Stage | What moves | Reversible in |
|---|---|---|
| Dual write | Nothing user-facing | Instantly |
| Shadow read | Nothing - responses compared only | Instantly |
| Read shift | A percentage of reads | Seconds |
| Write shift | A percentage of writes | Seconds, if dual write is still on |
| Decommission | Legacy path removed | Not reversible - do it last |
03Schema changes have to be backward compatible
During the transition both systems are live, so every schema change has to work for both. That means additive changes only: add a column, backfill it, start writing it, and only drop the old one once nothing reads it.
This is slower than changing the schema directly and it is the constraint that makes everything else possible. A single destructive migration during the transition window forces a maintenance window, and at that point the zero-downtime property is gone.
04What skipping it costs
A planned maintenance window is not automatically wrong. For an internal tool used in one timezone, taking two hours on a Sunday is cheaper than months of dual-write discipline, and pretending otherwise is engineering vanity.
The calculation changes when the system takes revenue continuously, when customers are in several timezones, or when the rollback plan is 'restore from backup and lose the transactions in between'. At that point the window is not two hours of downtime, it is two hours of downtime plus the risk that the restore is needed.
- Internal tools, single timezone: a window is usually the right call
- Revenue-carrying systems: dual write and traffic shifting pay for themselves in one avoided incident
- Regulated data: check whether your rollback plan is even permissible before relying on it
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.