Cloud Migration Without the Downtime: A Practical Checklist

"Zero-downtime migration" sounds like marketing language until you're the one explaining to customers why the app was down for six hours on a Tuesday. It's genuinely achievable for most systems — but only with a sequence that treats the cutover as the last step, not the first.

Here's the checklist we work through on almost every migration, whether it's a single app moving off an aging server or a multi-service platform moving between cloud providers.

Before touching anything: baseline and scope

• Inventory every dependency — databases, cron jobs, third-party webhooks, DNS records, background workers, file storage, and anything with a hardcoded IP or hostname.
• Establish real baselines for latency, error rate and throughput on the current system, so you have something concrete to compare the new environment against — not just a feeling that "it seems slower."
• Decide what "done" means before you start: a specific list of services running cleanly in the new environment for a defined soak period.

Build the new environment alongside the old one

The old system keeps serving production traffic the entire time the new one is being built. This is non-negotiable — it's what makes the rest of the checklist possible.

• Provision infrastructure as code, so the environment is reproducible and reviewable, not clicked together by hand.
• Set up monitoring and alerting on the new environment before it carries any real traffic, so you're not flying blind during cutover.
• Replicate data continuously rather than doing a single export/import — this keeps the gap between old and new small right up until cutover.

Test with real traffic before the real cutover

This is the step most timelines skip under pressure, and it's the one that prevents the worst surprises.

• Shadow traffic: mirror a copy of live production requests to the new environment without serving the response, to see how it behaves under real load.
• Canary release: once shadow testing looks clean, route a small percentage of real users (often 1–5%) to the new environment and watch error rates closely before increasing.
• Rollback plan, written down: know exactly how to revert DNS/routing back to the old environment, and how long that takes, before you need it.

If your rollback plan is "we'll figure it out," you don't have a migration plan — you have a bet.

Cutover day

• Migrate during a genuinely low-traffic window, even if downtime isn't expected — it shrinks the blast radius if something does go wrong.
• Lower DNS TTLs days in advance so the eventual switch propagates quickly instead of taking hours.
• Increase traffic to the new environment gradually (10% → 50% → 100%) rather than flipping a single switch, watching error rates and latency at each step.
• Keep the old environment warm and ready to receive traffic again for at least 24–48 hours after full cutover.

After cutover: the part people forget

A migration isn't finished when traffic moves — it's finished when you're confident enough to decommission the old environment. That means a defined soak period, a final data reconciliation to confirm nothing was lost in transit, and only then, shutting the old system down.

Done this way, "zero-downtime" isn't a lucky outcome — it's the natural result of never putting yourself in a position where a single step has to work perfectly under pressure.