How to Migrate to the Cloud with Zero Downtime

“We can’t be down” is a requirement, and it’s an achievable one, but it’s bought with parallel infrastructure and replication discipline, not with luck on cutover night. Here’s the actual mechanics.

What “zero downtime” buys, and what it costs

The core idea is simple: never have a moment where the only working copy of your system is mid-move. Old and new run in parallel, data flows between them continuously, and traffic moves over gradually. Users never see a maintenance page.

The costs are equally concrete:

• Double infrastructure for the overlap period (typically 2-6 weeks), if your environment costs $8k/month, budget ~$4-12k extra for the overlap.
• Replication engineering, setup, monitoring, and rehearsal time, easily 1-3 weeks of skilled effort for a nontrivial stack.
• Residual seconds-to-minutes of write-freeze at the database switch for most architectures. Call it what it is; don’t promise literal zero unless you’ve built dual-writes.

Weigh that against the cost of scheduled downtime. An internal tool used weekdays can take a Saturday-night window for a fraction of the effort, the roadmap treats that as the default for internal apps. Zero-downtime technique is for the systems where an hour dark costs real revenue or SLA penalties.

The architecture: blue-green across environments

Classic blue-green deployment runs two copies of production and flips between them; a zero-downtime migration is the same pattern stretched across your datacenter (“blue”) and the cloud (“green”):

1. Green is built complete in the cloud, app servers, load balancer, workers, config, inside your landing zone’s VPC, all pointing at a replicated copy of the data.
2. Blue keeps serving all production traffic, unaware anything is happening.
3. Data replicates continuously blue → green (the heart of the whole operation, next section).
4. Traffic shifts gradually blue → green, with a tested route back at every step.
5. Blue is retired only after green has survived weeks of full production load.

Everything below is the detail of steps 3-5.

Step 1, Replicate the database (the hard 80%)

Stateless things move trivially, you can run app servers in both places all day. State is the problem. The pattern, regardless of engine:

1. Initial load: snapshot the source into the cloud target (a native dump/restore, or a migration service’s full-load phase).
2. Continuous change capture (CDC): apply every subsequent write to the target as it happens. Options by stack:
   • PostgreSQL: logical replication (pgoutput) to the target, works to RDS/Cloud SQL/Azure Database.
   • MySQL/MariaDB: binlog replication; all major managed services support being a replica of an external primary.
   • SQL Server: transactional replication or a log-shipping variant, or a migration service.
   • Engine-agnostic / heterogeneous: AWS DMS, Azure Database Migration Service, or GCP Database Migration Service handle full-load + CDC and are the pragmatic choice when versions or engines differ. Fine for migration; don’t expect them to be zero-config, LOB columns, triggers, and sequences all have footnotes.
3. Watch replication lag until it holds steady in the low seconds. Lag that grows under daytime write load means the target is undersized or the network path is too thin, fix that before planning cutover.

Full detail, including validation queries and the sequence-collision trap, in how to migrate a production database.

The write-cutover moment. When traffic shifting is done and you’re ready to make green authoritative: pause writes at the application (a maintenance flag, a connection-pool drain, seconds), confirm lag = 0 and row counts/checksums match, promote the target, repoint blue’s app servers (now your fallback) at the new primary, resume writes. Rehearsed, this is 30 seconds to 5 minutes. Unrehearsed, it’s the worst hour of your quarter, rehearse it.

Then reverse the flow: replicate green → blue for the first days after cutover, so a rollback loses nothing.

Step 2, Shift traffic gradually

With data flowing, move the users. Three mechanisms, often combined:

Mechanism	Granularity	Speed to shift/revert	Notes
Weighted DNS (Route 53, Traffic Manager, Cloud DNS)	Percentage of resolvers	Minutes, bounded by TTL	Simplest; imprecise because clients cache
Load balancer / reverse proxy weighting	Exact percentages, per-request	Seconds	Put a proxy in front of both environments; the gold standard for control
Feature-flag / app-level routing	Per-user, per-tenant	Seconds	Most precise; requires app changes

The pragmatic sequence for most teams:

1. T-48h: drop DNS TTL to 60s. The old TTL must expire everywhere first, this is the step everyone remembers too late.
2. Shift 5% → green. Watch error rates, p95 latency, and business metrics (orders, logins) side by side for a few hours. Note: until write-cutover, green is either serving reads only or writing back to blue’s primary across the network link, keep that link’s latency in your p95 math.
3. 25% → 50% → 100% over hours or days, at whatever pace your risk tolerance and traffic patterns allow. Every step has a one-command path back.
4. After 100% holds steady: perform the database write-cutover (above), making green fully self-contained.
5. Keep blue answering, proxying to green, for 1-2 weeks. A stubborn minority of clients ignores TTLs; killing blue at the switch is how “zero downtime” grows an asterisk.

Session state has a footnote here: if sessions live in server memory, users bounced between environments get logged out. Move sessions to a shared store (Redis, database-backed) before the shift, or use sticky routing so a user stays on one side.

Step 3, Hold the rollback door open

A zero-downtime migration is really a zero-commitment migration until you decide otherwise. At every stage, know the answer to “how do we go back, and how long does it take?”

• During traffic shifting: rollback = reweight to blue. Seconds to minutes. Trivial, if green hasn’t become the write primary yet, which is exactly why write-cutover goes last.
• After write-cutover: rollback = promote blue back, using the reverse replication stream. Minutes, no data loss, if you set up reverse replication. Without it, rollback means losing every write since cutover, which in practice means there is no rollback.
• Define the tripwires in advance: “error rate >1% for 10 minutes,” “p95 latency doubles,” “payment success rate drops.” Naming them beforehand removes the 2 a.m. debate about whether things are bad enough. One named person decides.

The traps that break “zero”

• The 24-hour TTL discovered on cutover day. Check TTLs a week early. Check the apex/CNAME chain too, the TTL that bites is often on a record you forgot existed.
• Hardcoded IPs and hostnames in config files, cron jobs, and that one integration partner’s firewall allowlist. The discovery scan from your assessment phase is where these should surface.
• Background jobs running twice. Schedulers active in both environments during overlap will double-send emails and double-process queues. Inventory every cron/scheduled task; each runs in exactly one place, by explicit decision.
• Replication lag under real load. Lag tested at midnight looks great; Tuesday 11 a.m. write volume is the real test. Measure across at least one business-day peak.
• The forgotten writer. A reporting tool, an ETL job, an old admin script still writing to blue after cutover. Audit database connections on the old primary before you trust the switch; better, revoke write credentials on blue post-cutover so stragglers fail loudly instead of silently diverging.

FAQ

Is zero-downtime migration really zero downtime?

Almost. For most stacks the honest number is a write-freeze of seconds to a few minutes at the moment the database primary switches, which users experience as a slow request rather than an outage. Reads typically continue uninterrupted throughout. True zero, no user-visible pause at all, requires dual-write application logic and is rarely worth the engineering cost outside 24/7 revenue systems.

How does database replication work in a migration?

You take an initial snapshot of the source database into the cloud target, then apply the source’s change stream continuously (via native replication like Postgres logical replication or MySQL binlog, or a service like AWS DMS or Azure Database Migration Service) so the target stays seconds behind. At cutover you stop writes briefly, let the target catch up, verify positions match, and repoint the application.

What DNS TTL should we set before a migration cutover?

Lower it to 60 seconds at least 48 hours before cutover, because the old TTL (often 3600s or 86400s) has to expire from resolvers worldwide first. Even then, a small percentage of clients ignore TTLs, so keep the old environment answering (or proxying to the new one) for days after cutover rather than shutting it off at the switch.

How long should we keep the old environment running after cutover?

Two to four weeks is typical: long enough to cover a full business cycle (month-end jobs are the classic late failure), stragglers on cached DNS, and any rollback decision. Keep reverse replication running for the first days so rollback loses no data. The cost of the overlap is real, budget it, but decommissioning on day 2 to save money is how a bad week becomes a bad month.

When is scheduled downtime the better choice?

When your users would never notice. An internal app used 8am-6pm weekdays can cut over on Saturday night with a simple, cheap, well-rehearsed maintenance window, no parallel infrastructure, no replication complexity. Zero-downtime techniques earn their cost for customer-facing systems, 24/7 operations, and SLA-bound services. Match the technique to the actual cost of an hour of darkness.

---

Cutovers reward experience more than any other part of a migration, most of the traps above are only obvious the second time. If you have a system that can’t go dark, talk to a Webisoft cloud engineer; we’ll design the replication and cutover plan with you, or run the rehearsal at your side.