A cloud migration checklist has three jobs. Before the move, it forces you to inventory what you actually run and decide what deserves to come with you. During the move, it keeps each workload’s cutover boring and reversible. After the move, it catches the two things that always slip, which are cost and access permissions nobody cleaned up.
Most migration plans fail on the first job. Teams inventory servers, not dependencies, and find out in week three that the reporting database everyone forgot is what feeds the invoice run.
This is the full checklist we work from, split into the three phases. Copy it, cut what does not apply, and treat the “Before” section as the part you are not allowed to rush.
List every server, database, application, scheduled job, and integration. Then draw the connections. The inventory is the easy half. The dependency map is the half that decides your migration waves, and Microsoft’s Cloud Adoption Framework is blunt about why: workloads with direct dependencies that need low latency have to move together, or you get an application in one environment calling a database in another over the public internet at three in the morning. (Migration wave planning, Microsoft Learn)
Things people miss on the first pass:
A migration readiness assessment is not a survey. It is a scored answer to one question: for each workload, what does it cost to move, what breaks if it moves badly, and is anyone here able to run it once it is in the cloud?
Score each workload on four axes:
Axis | What you are measuring |
Business criticality | Revenue impact per hour of downtime |
Technical complexity | Dependencies, custom code, data volume, licensing |
Change tolerance | How much downtime the business will accept |
Team readiness | Whether anyone on staff can operate it after the move |
That last row is the one skipped most often. A workload can be technically simple and still a bad early candidate if the only person who understands it is a contractor on a three-month notice period.
There is no single answer to how you migrate. AWS defines seven strategies, commonly called the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor. (About the migration strategies, AWS Prescriptive Guidance)
Our position, and it is not a popular one: refactor during migration is usually a mistake. AWS says the same thing in its own large migration guidance, recommending rehost, replatform, relocate or retire for the move itself, and modernization afterward. Rewriting an application while also changing the ground it runs on means that when something breaks, you cannot tell which change caused it. Move it, stabilize it, then modernize it.
The two strategies people underuse are retire and retain. Every environment we assess has servers running that nothing depends on any more. Retiring them is the cheapest win in the entire cloud migration project plan, and it happens before you spend a dollar on the target environment.
The plan needs six things, and a cloud migration plan template that has more than that is usually padding.
A data migration checklist deserves its own document, because data is where migrations do irreversible damage. Applications can be redeployed. A truncated table cannot be un-truncated.
Per database, decide and write down:
A cloud database migration checklist that does not include a tested restore is a wish, not a plan.
Before anything moves, record what normal looks like. Response times at p50 and p95, batch job durations, peak concurrent users, monthly infrastructure spend, error rates. Without a baseline you cannot answer the question the CFO asks in month two, which is whether this is actually better.
The steps repeat per wave. That is the point. A migration that improvises each cutover is a migration that will eventually improvise badly.
Pre-cutover, the day before
Cutover
Immediately after
For each application in the wave:
If you are on AWS, this is also where the AWS migration checklist items land: instance right-sizing, security groups reviewed rather than copied, IAM roles attached instead of access keys embedded, and CloudWatch alarms created before the workload takes real traffic.
Every migration produces a hundred small decisions made at speed. Write them down as you go, one line each. Six weeks later, when someone asks why the reporting job runs on a separate instance, the log answers it in ten seconds instead of forty minutes of archaeology.
The post migration checklist is where most teams stop paying attention, and it is where the money leaks.
Compare the numbers you recorded before the move. Response times, batch durations, error rates. If anything is worse, fix it now while the migration is fresh in everyone’s head, not in the quarter when the people who did it have moved on.
Cloud migration monitoring is not a dashboard nobody opens. Pick a small number of alerts that a human will act on:
Five alerts people respond to beat fifty they mute.
This is the unglamorous list, and skipping it is why cloud bills climb.
That migration-time access cleanup is not optional. Temporary elevated permissions that survive the migration are one of the most common ways a cloud environment ends up quietly wide open. We wrote about that separately in the cloud migration security checklist.
Cost per environment, month over month. Incidents attributable to the migration. Time to deploy a change, before and after. Percentage of workloads on managed services rather than raw instances. These are the numbers that tell you whether the migration succeeded, and none of them are visible on cutover day.
If you want the 7 steps of cloud migration compressed into something you can put on a slide:
The compressed version is useful for getting agreement. The full checklist above is what you actually work from.
Do not move everything at once because the data center contract expires. That deadline is real, but a compressed migration produces an environment nobody understands, and you pay for it for years in incidents and overspend. Negotiate a short extension and move in waves.
Do not migrate and modernize in the same step, for the reason above.
Do not treat the cloud provider’s migration tooling as a plan. AWS Application Migration Service and Azure Migrate are good at copying servers. Neither one decides which servers should exist.
If you are working through this checklist and want a second set of eyes on the dependency map or the wave plan, that is the conversation we are useful in. InfraNexa runs cloud migrations and then operates the environment afterward, which tends to make us conservative about cutover plans, because we are the ones on the pager at 2am.
It depends on wave count and data volume more than server count. A single application with a small database can move in a weekend. A 200-workload estate with legacy dependencies is usually a six to twelve month program run in waves. Anyone quoting a timeline before seeing your dependency map is guessing.
The cloud assessment checklist is the list of things to look at. The readiness assessment is the scored output: which workloads are ready, which are blocked, and what has to happen first. The checklist is the input, the assessment is the decision.
A template helps you not forget things. It does not do the thinking. The six items in section 4 are the parts of a plan that matter, and any template missing rollback triggers or a named budget owner is incomplete.
Neither, in most cases. Move them together in the same wave with the database replicating live until cutover. Splitting them across a wave boundary means running one of them across the public internet, which costs you latency and creates a security exposure you did not plan for.
