What should be on a cloud migration checklist?
A cloud migration checklist lists every task you must finish before, during, and after moving workloads to the cloud so nothing critical is discovered in production. A good one runs across three phases — assess, plan, and execute — and forces you to answer hard questions about dependencies, data residency, cost, and rollback before a single server moves. Skip the checklist and migration becomes a lift-and-pray exercise; work through it and you turn a risky event into a predictable, repeatable engineering project.
Below is the 12-step migration readiness checklist we run on every engagement. It applies whether you are moving from an on-premise data centre, another cloud, or a tangle of self-managed VMs — and it maps cleanly onto AWS, though the principles hold for any provider.
What is a pre-migration assessment?
A pre-migration assessment is the discovery phase that establishes what you have, what it costs, and what will break if you move it. Most failed migrations fail here — teams jump to provisioning infrastructure before they understand their own estate. Get these first four steps right and the rest of the project de-risks itself.
1. Build a complete application and dependency inventory
List every application, service, database, cron job, and integration — including the ones nobody documented. For each, capture the runtime, version, upstream and downstream dependencies, and who owns it. The goal is to eliminate the "we forgot that shared database talks to the billing service" surprise that stalls a cutover at 2am.
2. Map data flows, compliance, and data-residency requirements
Trace where data lives, where it moves, and which regulations govern it — GDPR in the EU, DPDP in India, and sector rules in the UAE all constrain where workloads can legally run. Decide your target region before design, not after. Classify data by sensitivity so you know what needs encryption at rest, private networking, or a dedicated account boundary.
3. Establish a cost and TCO baseline
Measure what you spend today — hardware, licences, power, data-centre space, and the engineering hours spent keeping it running. Without a baseline you cannot prove the migration paid off, and you cannot spot the workloads that will get more expensive in the cloud if lifted naively. Our breakdown of AWS migration costs in 2026 covers the line items teams routinely forget, from data-transfer egress to the parallel-running period when you pay for both environments.
4. Define success metrics and business drivers
Write down why you are migrating and how you will measure it: lower run-cost, faster release cadence, better uptime, exit from an ageing data-centre lease, or elastic scale for a seasonal product. Attach a number to each. "Move to the cloud" is not a goal; "cut infrastructure spend 30% and deploy daily instead of monthly" is.
Which migration strategy should you choose? The 6 R's
There is no single right way to migrate — you pick a strategy per workload. The industry shorthand is the "6 R's". Rushing everything into a full rewrite wastes months; lifting everything as-is leaves you paying cloud prices for data-centre architecture. Match each application to the right R:
| Strategy | What it means | Best when | Effort |
|---|---|---|---|
| Rehost (lift-and-shift) | Move as-is onto cloud VMs | Speed matters; app is stable and low-risk | Low |
| Replatform | Small optimisations — managed database, load balancer, autoscaling | You want quick wins without a rewrite | Medium |
| Repurchase | Drop the app, move to SaaS | Commodity workloads like email or CRM | Low–Medium |
| Refactor (re-architect) | Rebuild cloud-native — containers, serverless, managed services | High-value apps that need scale or velocity | High |
| Retire | Decommission entirely | Nobody uses it; it just wasn't switched off | Low |
| Retain | Keep on-premise for now | Latency, licensing, or compliance blocks the move | None |
A typical estate ends up mostly rehost and replatform, with a handful of high-value systems refactored and a surprising number retired. If your source is a physical or virtual data centre, our on-premise to AWS migration strategy walks through how to sequence these choices without a big-bang cutover.
How do you build a cloud migration plan?
The cloud migration plan turns your assessment into an executable sequence. This is where you design the destination and the order of moves.
5. Choose a migration strategy per workload
Apply the 6 R's across your inventory and record the decision against each application. This becomes the master list that drives scheduling, budgeting, and staffing for the rest of the project.
6. Design the target landing zone
A landing zone is the pre-built, secure foundation your workloads land in: account structure, network topology, IAM roles, logging, and guardrails — set up once, before any app arrives. Building this correctly up front is the single biggest predictor of a clean migration. Anchor the design in the AWS Well-Architected Framework, which gives you a proven checklist across security, reliability, performance, cost, and operational excellence.
7. Set your security and governance baseline
Define encryption standards, identity and access policies, network segmentation, secrets management, and audit logging as code — not as manual clicks. Enforce least-privilege from day one. Retro-fitting security after workloads are live is expensive and never quite complete.
8. Sequence workloads into migration waves
Group applications into waves ordered by risk and dependency. Start with low-risk, low-dependency systems to build muscle and confidence; save the tightly coupled, business-critical systems for later waves when your tooling and runbooks are proven. Never migrate a dependency after the thing that depends on it.
What are the AWS migration steps once you're ready to move?
With the plan set, execution is disciplined and boring — exactly what you want. These four steps convert design into a running, validated cloud estate.
9. Run a pilot migration
Migrate one low-risk workload end-to-end before committing the rest. The pilot validates your landing zone, your tooling, your runbook, and your rollback — and it surfaces the gaps no amount of planning would have. Treat it as a dress rehearsal, capture every lesson, and only then scale to full waves.
10. Plan data migration and cutover with rollback
Data is the hardest part. Decide between offline copy, continuous replication, or a hybrid, and schedule the cutover window. Every cutover step needs a matching rollback step and a clear go/no-go decision point. Define, in advance, exactly what "healthy" looks like after cutover and who calls the abort.
11. Test performance, DR, security, and functionality
Validate against the success metrics from step 4, not against a vague sense that "it works". Run load tests against production-like traffic, execute a real disaster-recovery failover, scan for misconfigurations, and have application owners sign off on functional behaviour. Do this before you send users to the new environment.
12. Optimise and decommission legacy
Migration is not done at cutover. Right-size instances, apply autoscaling, add savings plans or reserved capacity, and switch off the old environment so you stop paying twice. Feed real usage data back into your cost baseline to prove the business case — and to catch the workloads that need a second optimisation pass.
How long before you're actually ready to migrate?
For most mid-sized estates, the assess-and-plan phases take four to eight weeks of focused work; execution then runs in waves over the following months. The temptation is to compress discovery to "get moving" — resist it. Every hour spent on the pre-migration assessment saves days of firefighting later. Choosing a provider before you start? Our comparison of AWS vs Azure vs Google Cloud in 2026 lays out the trade-offs so the destination decision is made on evidence, not habit.
How ILMTEC helps
ILMTEC runs cloud migrations as structured six-week delivery cycles rather than open-ended projects. We start with the pre-migration assessment above — full dependency inventory, data-residency mapping for EU, UAE, and India workloads, and a cost baseline — then design a Well-Architected landing zone and move workloads in tested waves with rollback at every step. If you want an expert partner to run this checklist end-to-end, our AWS cloud migration service takes you from assessment to optimised, production-ready infrastructure without the guesswork.
