Every cloud migration plan I've seen starts with the same promise: zero downtime. And most of them get pretty close — right up until the one dependency nobody mapped out decides to fall over at 2 a.m.
Here are a few of the patterns that tend to cause the most pain, and what's worked to avoid them.
1. DNS is never as fast as you think
TTL settings get set once, early in a project, and then forgotten. If your DNS TTL is sitting at 24 hours when you cut over, your "instant" switch is actually a multi-hour rolling failure for a chunk of your users.
Drop the TTL days in advance, not the morning of.
2. Stateful services get left for last — and that's backwards
Stateless app servers are easy to migrate: spin up new ones, point traffic at them, done. Databases, queues, and anything holding session state are the actual hard part, and they're usually the thing teams plan for last because it's the scariest piece.
Flip that. Start migration planning with the stateful layer and work outward.
3. CI/CD pipelines assume an environment that no longer exists
If your pipeline has hardcoded IPs, region-specific credentials, or scripts that assume a particular host's filesystem layout, migrating infrastructure without touching the pipeline just moves the failure point.
A pipeline that's portable across environments (parameterized configs, environment variables instead of hardcoded values, containerized build steps) survives a migration. One that isn't will quietly break the first deploy after cutover.
4. Monitoring gaps show up exactly when you need them least
It's common to migrate the app and the infrastructure, and forget that your monitoring stack was scraping metrics from the old environment's internal network. You don't find out until the first incident happens and the dashboards are just... empty.
Stand up monitoring in the new environment before cutover, and run both in parallel for at least a few days.
5. Rollback plans that were never tested aren't rollback plans
A rollback plan that lives in a doc and has never been executed is a hypothesis, not a plan. If you can't dry-run the rollback in a staging environment, budget time to build that capability before migration day, not after something's already gone wrong.
It comes down to sequencing, not tooling
None of this is exotic — it's mostly discipline and sequencing. The teams that get through migrations cleanly aren't the ones with the fanciest tooling, they're the ones who mapped their dependencies honestly before they started moving things.
If you're in the middle of planning a migration or a CI/CD overhaul and want a second set of eyes, Web Matrix Lab's Cloud & DevOps team has written up more detail on how they approach this.
Top comments (0)