Every migration plan promises zero downtime. Few enterprises define, upfront, which pattern will actually deliver it.
"Zero downtime" appears in nearly every data migration statement of work we review, and it is nearly always aspirational rather than architected. A big-bang cutover scheduled for a low-traffic weekend window is not a zero-downtime pattern; it is a bet that the business impact of an outage will be small enough to tolerate if something goes wrong, and a bet that nothing will go wrong during a multi-hour maintenance window under conditions the team has rarely rehearsed at full scale. Sometimes that bet pays off. When it does not, the cost is measured in lost transactions, damaged customer trust, and a leadership team that is now far more skeptical of the next migration proposal.
Through the migration engagements we run under our migration practice, the enterprises that actually achieve zero or near-zero downtime share a common trait: they choose a specific migration pattern deliberately, based on the shape of their data and their tolerance for eventual consistency, rather than assuming that a well-written runbook and a quiet weekend will be enough.
The foundation of most zero-downtime migrations is keeping the source and target systems synchronized while the cutover is prepared, so that the actual switch is a routing change rather than a bulk data transfer performed under time pressure. Dual-write, where the application writes to both the old and new systems during a transition period, is conceptually simple but operationally fragile: any bug in the dual-write logic, or any write path that is missed, silently produces divergence between the two systems that may not surface until well after cutover.
Change data capture (CDC) is generally the more reliable approach for enterprise-scale migrations. Rather than modifying application code to write twice, a CDC pipeline reads the source database's transaction log and streams every change to the target system continuously, which means the application code does not need to know a migration is happening at all. This decouples migration risk from application risk — a bug in the CDC pipeline can be fixed and replayed without touching production application logic — and it gives the migration team a running, continuously updated target system they can validate against the source at any point before cutover, rather than a snapshot that is stale the moment it is taken.
For migrations that involve not just moving data but also modernizing the application logic sitting on top of it, the strangler pattern reduces risk by replacing the old system incrementally, function by function, rather than in one large cutover. A routing layer sits in front of both the legacy and new systems, initially directing all traffic to the legacy system, then progressively redirecting individual functions or user segments to the new system as each is validated in production. The legacy system continues handling whatever has not yet been migrated, and it is only decommissioned once every function has been strangled out of it.
The operational benefit is that a failure in the newly migrated function affects only that function's traffic, not the entire system, and it can be rolled back by adjusting the routing layer rather than restoring an entire database from backup. This makes the strangler pattern particularly well suited to migrations where the business cannot tolerate any single high-risk cutover event, even a well-rehearsed one, and would rather absorb a longer overall migration timeline in exchange for a much smaller blast radius on any individual step.
Whichever synchronization pattern an enterprise chooses, the cutover moment itself — the point at which the target system becomes authoritative and traffic is redirected to it — is where zero-downtime plans most often fail in practice, precisely because teams treat it as a one-time event rather than a rehearsed procedure. The migrations that go smoothly are the ones where the cutover has been executed multiple times against a staging environment that mirrors production scale, with the team timing each step, identifying every manual intervention that could be automated, and building explicit rollback criteria and a rollback procedure that is just as rehearsed as the forward path.
A rehearsed cutover also defines success criteria in advance rather than deciding in the moment whether things look "good enough." Row counts must reconcile within a defined tolerance, checksums on critical tables must match, and a fixed set of smoke tests must pass before traffic is fully cut over — and just as importantly, the team must agree in advance on what triggers a rollback, so that decision is not being made for the first time under pressure with executives watching a dashboard. This discipline is what separates a genuinely zero-downtime cutover from a migration that merely got lucky.
Zero downtime is achievable, but it is an architectural outcome, not a scheduling decision. Enterprises that pair change data capture or a strangler-pattern rollout with a rehearsed, criteria-driven cutover consistently migrate with confidence. Enterprises that rely on a quiet weekend and a hopeful runbook are simply deferring the risk to the moment it is hardest to manage.