Cloud Migration Checklist: What to Assess Before You Move Anything

A cloud migration is usually pitched around the destination: lower cost, better scaling, less hardware to manage. The actual risk lives in the assumptions made about the current environment before the move starts. Most of the migrations we get called in to unstick failed at the assessment stage, not during the cutover.

Map dependencies before you map a timeline

Every application looks self-contained until you trace what it actually talks to: a database on another server, a scheduled job on a different machine, a firewall rule that only makes sense given the current network layout. A migration plan built before dependency mapping is a plan built on guesses, and guesses are where downtime comes from.

• List every inbound and outbound connection a workload makes, not just the ones already documented
• Identify hardcoded IP addresses and hostnames that will break the moment something moves
• Flag shared resources, such as a database serving more than one application, before deciding they can move independently

Data gravity decides your sequencing, not the other way around

Large datasets are expensive and slow to move, and every application that reads or writes them is effectively anchored to wherever that data lives. Deciding what moves first should start from the data, not from which application team is most eager to go. Moving an application ahead of the data it depends on usually means running it against the old environment over a slow, unreliable link until the data catches up, which quietly becomes the new normal for longer than anyone planned.

Cost modeling has to include the operating pattern, not just the resource size

Cloud pricing calculators are good at comparing a fixed amount of CPU, memory and storage against an on-premises equivalent. They are much worse at capturing how differently teams actually use cloud resources: autoscaling that responds to real traffic, data transfer costs between services, and the tendency for cloud environments to accumulate small, forgotten resources that keep billing quietly. A realistic estimate needs actual usage patterns, not just a snapshot of current server specifications.

• Model data transfer costs between the new environment and anything staying on-premises during a phased migration
• Account for the cost of redundancy the current environment might not have, such as multi-zone deployment
• Set a review point 60 to 90 days after migration to catch cost drift before it becomes a budget conversation

Decide your rollback plan before you need one

A rollback plan written after something has already gone wrong is really just an improvisation with extra pressure attached. Before migrating a workload, it is worth deciding explicitly: how would we know this is failing, who makes the call to roll back, and how long would that actually take. If the honest answer is that rollback would take longer than the acceptable downtime, that changes how the migration should be sequenced, not just how it is documented.

Identity and access design deserves its own decision, not a lift and shift

It is tempting to replicate existing user accounts, permissions and network access rules as closely as possible in the new environment, because it feels lower risk and faster to implement. This usually just moves an accumulated mess of unused accounts and overly broad permissions into a fresh environment where it is harder to notice. A migration is a rare, natural opportunity to redesign access around what is actually needed today, and skipping that opportunity means redoing the same cleanup later under worse conditions.

Test the failure modes, not just the happy path

Migration testing usually focuses on confirming the application starts and responds correctly in the new environment. That is necessary and not sufficient. The more useful test is what happens when a dependency the application relies on is briefly unavailable, since network paths, latency and failure behavior are rarely identical between the old and new environments, even when everything else matches on paper.

A short checklist before the first workload moves

• Every workload has a documented list of what it depends on and what depends on it
• Data movement is sequenced ahead of the applications that need it
• Cost estimates reflect actual usage patterns, not just resource specifications
• A rollback trigger and owner are defined before migration, not during an incident
• Identity and access are redesigned deliberately, not copied as-is
• Failure-mode testing happens in the new environment, not only happy-path testing

None of this makes a migration risk-free, and it does not need to. It removes the avoidable risk, the kind that comes from an assumption nobody checked rather than from a genuinely hard technical problem. That distinction is usually what separates a migration that goes quietly from one that becomes a memorable incident.