Cloud migration checklist: the 12 things that break most migrations

Most migration plans focus on the big decision, lift-and-shift or re-architect, which cloud, which region. Those decisions matter, but they're rarely what actually breaks a migration. The things that break migrations are smaller and more specific: a firewall rule that didn't get copied, a DNS record with a 24-hour TTL nobody lowered in advance, a licensing model that behaves differently on the new platform. Here are the 12 that come up again and again, grouped by when you need to catch them.

Before you migrate

This is where most of the real risk gets created or removed. Skipping planning doesn't save time, it just moves the cost to the middle of cutover weekend.

• 01

  Map every dependency, not just the app

  The application is rarely the whole picture. Cron jobs, internal services calling each other by hostname, shared databases, a reporting job that reads directly from a replica nobody documented, these get missed constantly. Build the dependency map before you plan the move, not while you're debugging why something broke after it.

• 02

  Plan the data migration separately from the app

  Moving the app is often the easy part. Moving the data correctly, with an acceptable sync strategy, an understanding of replication lag, and a plan for what "consistent" means at cutover, is where migrations actually get hard. Decide upfront whether you need a maintenance window, a dual-write period, or continuous replication with a short final sync.

• 03

  Review network and security, don't just replicate it

  Copying your old firewall rules and security groups onto the new cloud carries over whatever was already too permissive, and cloud providers structure networking differently enough that a literal copy often doesn't even work correctly. Treat this as a chance to tighten access, not just a step to get through.

• 04

  Check licensing and vendor terms before you commit

  Software licensed per-core, per-instance, or by physical host can cost dramatically more or less depending on how the new environment is sized and structured. Confirm this before migration, not after the first invoice arrives.

During cutover

This is the highest-risk window, and the mistakes here tend to be about timing and access, not big technical decisions.

• 05

  Lower DNS TTLs days in advance

  A 24-hour TTL means your "quick" cutover can take a full day to actually route all traffic to the new environment. Lower it to a few minutes at least 48 hours ahead of the cutover window.

• 06

  Build IAM from scratch, don't copy-paste

  Different clouds structure identity and access differently enough that a direct copy of your old permission model usually recreates old mistakes or breaks outright. Rebuilding it deliberately, with least-privilege as the default, is more work upfront and considerably less work later.

• 07

  Set cost guardrails before traffic moves

  Budgets and billing alerts should exist before the migration, not after a surprising invoice. Autoscaling groups, storage tiers, and data transfer settings that were fine on the old provider can produce a very different bill on the new one.

• 08

  Always have a tested rollback path

  Not a rollback plan you assume would work, one you have actually tested. If you can't describe exactly how you'd revert DNS, data, and traffic within a defined window, you are not ready to cut over yet, regardless of how confident everything else looks.

After you're live

The migration isn't finished when the application responds to requests. It's finished when you can prove the new environment is actually equivalent, or better.

• 09

  Rebuild monitoring before you need it

  Dashboards, alert thresholds, and on-call routing built for the old environment don't automatically carry over. Confirm your team has real visibility into the new environment before the first incident forces you to find out the hard way.

• 10

  Validate data integrity, not just that "it copied"

  Row counts, checksums, and spot-checks against known records catch the silent data problems that a successful-looking migration job can still hide. Do this before you decommission the old environment, while you still have a source of truth to compare against.

• 11

  Confirm compliance and residency didn't change

  A new region can mean new regulatory exposure, especially for data residency requirements tied to healthcare, finance, or EU customers. Confirm this explicitly, don't assume the new setup inherited the same compliance posture as the old one.

• 12

  Load-test and failure-test before declaring victory

  The happy path working isn't the same as production-ready. Test under realistic load, and test what happens when something fails, before you tell the business the migration is complete.

Common mistakes

• Treating it as pure lift-and-shift with no re-architecture review. Sometimes that's the right call, but it should be a decision, not a default born from time pressure.
• Underestimating the human side. Runbooks, on-call rotations, and team familiarity with the new environment matter as much as the technical migration itself.
• Scheduling cutover for a Friday. Give the team a full working week to catch and fix problems before the weekend, not after.
• No defined "done" criteria. Without an explicit checklist for what "migration complete" means, work quietly stalls at "mostly working."

What to do next

Most of these 12 items are cheap to fix when caught early and expensive when caught during cutover weekend. A Cloud Migration engagement plans the move in stages, tested at every step, with the dependency mapping, network review, and rollback plan built in from day one rather than assembled under pressure.