Why 'lift and shift' still causes outages in 2026
Every migration plan promises zero downtime. Most don't deliver it. In a 2026 compilation of enterprise cloud-migration survey data, 47% of organizations reported at least one major outage after moving production applications to the cloud, and 26% of projects fell behind schedule as a result (Gitnux's 2026 cloud migration statistics, drawing on Deloitte, IBM, Gartner and PwC research). The technology to migrate without an outage window has existed for years now — replicated databases, blue-green environments, canary traffic shifting. What's usually missing isn't tooling. It's a sequenced plan that treats the cutover itself as the highest-risk five minutes of the entire project, and engineers accordingly.
The stakes are higher than most teams budget for. New Relic's 2025 Observability Forecast, based on a survey of more than 1,700 IT professionals across 23 countries, put the median cost of a high-impact outage at $2 million per hour — roughly $33,000 a minute — with surveyed organizations reporting a median of $76 million a year in downtime-related losses. ITIC's 2024 downtime survey found that 97% of large enterprises now say a single hour of downtime costs more than $100,000, and 41% report hourly costs of $1 million to $5 million or more. A botched cutover window isn't a minor operational hiccup. It's a line item a CFO will ask about.
There's a cost-overrun angle too. 23% of cloud migration projects exceed their original budget, and cost overruns are cited as a factor in 31% of delayed or failed projects (Gitnux, 2026). Downtime and budget blowouts tend to travel together — the same missing dependency map that causes an outage is usually what causes the schedule slip that burns the budget.
The 8-step framework
This is the sequence we run on production migrations, whether we're moving a monolith off a data center, replatforming to managed cloud services, or decomposing a legacy system behind a strangler fig facade. Skipping steps is where the downtime comes from.
- Map every dependency before you touch infrastructure. Inventory every service, cron job, webhook, and third-party integration that talks to the system you're migrating, including the undocumented ones. Data-migration complexity and legacy-system entanglement are among the top blockers cited by teams whose migrations ran over schedule, and most of that complexity is dependencies nobody wrote down.
- Pick the pattern that matches your risk tolerance, not the one that's trendiest. A stateless API service is a good candidate for straightforward blue-green deployment. A tightly coupled legacy monolith with years of undocumented business logic is a better fit for the strangler fig pattern, where you route traffic to new services incrementally and let the old system shrink over months rather than one weekend.
- Stand up the target environment in parallel. Don't migrate in place. Build the new environment (blue-green's 'green', or the new microservice behind the strangler facade) fully provisioned and load-tested before it takes a single byte of production traffic. This is also the point to bring in dedicated cloud and DevOps engineering support if the target architecture — Kubernetes, managed databases, infrastructure-as-code — isn't something your team runs day to day.
- Replicate data continuously, not as a single big-bang export. Use change-data-capture (CDC) or native database replication to stream writes from the old system to the new one in real time, starting well before cutover. The cutover only happens once replication lag is small and stable, not once the initial bulk copy finishes.
- Shift traffic gradually with canary releases. Route a small slice of live traffic, often 1-5%, to the new environment first, watch error rates and latency, then step up in stages: 10%, 25%, 50%, 100%. Google's SRE team, which popularized this pattern at scale, treats a canary as a cheap experiment: if it fails, you've exposed a small slice of users, not everyone.
- Lower DNS TTL days before cutover, not the day of. Drop your DNS record TTL to somewhere between 60 and 300 seconds at least 24-48 hours before the planned cutover, so the change propagates fast once you flip it. Cutting over with a stale 24-hour TTL still in place is one of the most common, and most avoidable, causes of a longer-than-planned outage window.
- Drain connections instead of killing them. Configure your load balancer to stop sending new connections to the old environment while letting in-flight requests finish — a deregistration delay typically measured in minutes — before decommissioning it. Terminating instances the moment traffic shifts is what turns a clean cutover into dropped transactions and support tickets.
- Keep the old environment warm and ready to roll back. Don't decommission the source system until the new one has run a full production cycle — a full business day at minimum, a full billing cycle for anything financial — without incident. A rollback plan you never use is cheap insurance. A rollback plan you need and don't have is a postmortem.
The single number that determines whether your cutover is measured in seconds or hours is replication lag. Teams running mature CDC-based cutovers hold replica lag under 1 second — ideally under 0.5 seconds — as a hard gate before flipping traffic, and treat 'lag is low enough' as a go/no-go checklist item, not a hope. If lag is climbing when you planned to cut over, the answer is to wait, not to push through.
Which strategy fits which migration
No single pattern is right for every system. Here's how the four most common approaches actually compare in practice.
| Strategy | How it works | Best for | Downtime risk |
|---|---|---|---|
| Blue-green deployment | Full duplicate environment; traffic flips at once | Stateless services, well-tested releases | Low, if rollback plan is ready |
| Canary release | Small traffic percentage shifted first, scaled up gradually | High-traffic systems where blast radius matters | Very low; issues caught early |
| Strangler fig | New services incrementally intercept and replace legacy functionality | Large legacy monoliths, long migrations | Low, but requires months of dual-running |
| Rolling update | Instances replaced in batches; old and new versions run side by side briefly | Container and Kubernetes-native workloads | Low to moderate, depends on batch size |
The technical pitfalls that actually cause the outage
Framework aside, the outages we get called in to clean up after usually trace back to one of a handful of repeat offenders.
- DNS cutover timed wrong. Teams flip the DNS record and assume traffic moves instantly. It doesn't, because caching resolvers, ISPs, and even some browsers ignore or override TTL values. The fix is boring but reliable: lower TTL days in advance, verify propagation with multiple resolvers before declaring success, and keep the old environment serving traffic until you've confirmed the new one is receiving it.
- Replication lag ignored under load. Lag that looks fine in a quiet staging test can spike the moment production write volume hits the new pipeline. Monitor lag continuously during the migration window itself, not just before it, and set an explicit lag threshold that pauses the cutover automatically if it's breached.
- Connection draining skipped. Killing old instances the instant traffic shifts drops any request that was mid-flight, which shows up as a burst of failed transactions right at cutover even though the migration 'succeeded.' A deregistration delay of a few minutes on the load balancer, timed to your longest expected request, prevents this.
- Misconfiguration in the new environment. 48% of cloud outages tracked in the same 2026 survey compilation were linked to misconfiguration rather than the migration technique itself — permissions, security groups, and environment variables that were never fully replicated from the old environment. A configuration diff between old and new environments, run automatically before cutover, catches most of these before they become an outage.
What this looks like on a real project
None of this is exotic. It's disciplined sequencing, applied by people who've done the cutover before and know where it usually breaks. That's the difference between a migration that finishes in a quiet weekend maintenance window and one that turns into an all-hands incident call at 2am. If your team is planning a migration and doesn't have someone who's run a production cutover under real traffic, that's the gap worth closing before you schedule the date, not after.
Planning a migration you can't afford to get wrong?
We've run production cutovers for systems where a bad hour costs real money. Let's map your dependencies and build a cutover plan before you set a date.
Frequently asked questions
How long should a zero-downtime migration cutover actually take?
A well-prepared cutover — DNS already propagated, replication lag already under a second, connection draining already configured — typically takes seconds to a few minutes of actual traffic transition. The migration project around it can run weeks or months; the cutover moment itself should be short and boring.
Can you really achieve zero downtime for a database migration, or is it always near-zero?
For most production systems it's near-zero rather than absolutely zero. CDC-based replication with a sub-second lag threshold gets you to a cutover window measured in single-digit seconds, which for practical purposes reads as zero downtime to users even though a strict definition would call it near-zero.
What's the real difference between blue-green deployment and canary release?
Blue-green flips all traffic from the old environment to the new one at once, with the old environment kept warm for instant rollback. Canary release shifts traffic gradually, a small percentage first, so problems surface with a limited blast radius before the rest of your users see them. Many teams use both together.
How much more does it cost to migrate this carefully versus just scheduling a maintenance window?
The upfront engineering work — replication setup, canary tooling, a tested rollback plan — takes real time and costs real money. But weighed against a median $2 million-per-hour cost for a high-impact outage, or the 23% of migration projects that already exceed budget due to problems caught late, the math almost always favors doing the cutover properly the first time.