Zero-downtime cutover
Also: live cutover, blue-green migration
What is Zero-downtime cutover?
A zero-downtime cutover switches production traffic from an old system to a new one without a maintenance window, using parallel running, incremental data sync and a rehearsed, reversible switch.
What Zero-downtime cutover means
A zero-downtime cutover is the moment a modernized or migrated system takes over from the old one while users keep working. It relies on preparation: the new system runs alongside the old, data is synchronised continuously rather than copied once, and the switch is a routing change that can be reversed. Common mechanics include change-data-capture to keep databases aligned, dual writes with a single system of record, blue-green environments, and DNS or gateway flips.
The plan matters more than the tooling. A serious cutover has a written runbook, a rehearsal on production-like data, agreed success checks, a named person who can call a rollback, and a defined point after which rollback is no longer possible because new data has diverged.
It is not simply a fast maintenance window. Nor is it required for every system. A back-office tool used from nine to five can often be cut over at night with an hour of downtime for a fraction of the engineering effort. Zero-downtime is worth its cost for customer-facing, always-on or transaction-heavy systems where any outage has a direct cost.
Who it really matters to
- Operations head: no pause in order taking, dispatch or patient registration during the switch.
- CTO / Head of Engineering: the rehearsal and rollback discipline turns cutover from the riskiest day of the programme into a routine change.
- CFO: avoids lost revenue and penalty exposure from an outage on a transactional system.
- Support manager: customers see no error pages and support is not flooded on cutover day.
Why it exists
Cutover is where modernization programmes fail visibly. A one-shot migration copies data, flips the switch and hopes; if something is wrong, the rollback often loses transactions created in between. Zero-downtime techniques exist so the switch becomes gradual and reversible: data stays in sync, traffic can be moved a percentage at a time, and problems are found while the old system still holds the truth. The trade-off is considerable extra engineering, including sync pipelines and dual-write logic that are thrown away after cutover, so it should be reserved for systems where downtime genuinely costs money or trust.
Where it is applied
- Switching a payment gateway integration for a fintech app while transactions keep flowing, with both processors live during the transition.
- Migrating a retailer's storefront database to a new platform in the weeks before a peak-season sale.
- Moving a hospital's appointment scheduling to a new system while the front desk continues booking.
- Replacing a logistics firm's dispatch service with traffic shifted rider-region by rider-region.
- Cutting a SaaS product over from single-tenant to multi-tenant infrastructure tenant by tenant.
Is Zero-downtime cutover a skill?
Technique / practiceAn engineering practice combining data synchronisation, traffic routing and runbook discipline. Eazyware plans and executes cutovers as part of Legacy-to-AI Modernization and platform implementations, with rehearsal and rollback criteria agreed before the date.
Eazyware service that covers it: Legacy-to-AI Modernization Program. Starting prices are on the pricing page.
Frequently asked questions
Does every migration need a zero-downtime cutover?
No. Internal tools with predictable usage hours can take a short scheduled window at much lower cost. Reserve zero-downtime approaches for customer-facing, transactional or round-the-clock systems where an outage has a direct cost.
What is the point of no return?
The moment after cutover when the new system has created data the old one cannot absorb, so rollback would lose transactions. A good runbook names that point explicitly and front-loads the checks that must pass before it.