Cloud Migration Checklist: The 7 Rs, Step-by-Step Plan and Cost Traps

Most cloud migrations don’t fail on the technology. They fail on surprises: an app nobody knew depended on a 15-year-old database, a cutover weekend that ran into Monday, or a first cloud bill that made the finance team call an emergency meeting.

A good cloud migration checklist turns those surprises into line items you handle in advance. This guide walks through the migration strategies known as the 6 or 7 Rs, a phase-by-phase checklist you can adapt, and the cost traps that catch even experienced teams.

Why migrations go over time and budget

The usual causes are predictable:

• Incomplete inventory. Teams migrate what they know about and discover the rest when it breaks.
• Hidden dependencies. Apps talk to each other in ways nobody documented.
• One strategy for everything. Lifting and shifting every workload, or rebuilding every workload, both create problems.
• No cost model. On-premises designs carried into the cloud often ignore data transfer, storage tiers and idle capacity.
• Running 2 environments too long. Paying for the data center and the cloud at the same time eats savings.

The 6 Rs and 7 Rs of cloud migration

Many older guides list 6 migration strategies. AWS’s current Prescriptive Guidance lists 7, adding relocate. Microsoft’s Cloud Adoption Framework uses a similar set of “Rs” and assigns one to each workload based on its business driver.

AWS notes that refactoring is the most complex and costly strategy. For large migrations, it recommends rehosting, relocating or replatforming first and modernizing after the move.

AWS also gives a useful rule of thumb for retiring apps. It describes “zombie” applications as those averaging below 5% CPU and memory use, and “idle” ones as between 5% and 20% over 90 days. Use your discovery data to find them, because every app you retire is one you don’t have to migrate or pay for.

Key takeaway: Choose a strategy per workload, not per company. Retire what you can, rehost or replatform most of the rest, and save refactoring for the few apps where it clearly pays off.

Phase 1: assess and discover

• Define the business goals: cost, resilience, speed, data center exit date or compliance.
• Inventory every server, database, app, file share and scheduled job, using a discovery tool rather than spreadsheets alone.
• Map dependencies between apps, including external services and integrations.
• Capture baseline performance metrics such as CPU, memory, storage IOPS and peak load.
• Record each workload’s SLA, recovery point objective (RPO) and recovery time objective (RTO).
• Flag unsupported or end-of-support components as blockers or post-move fixes.
• Classify data by sensitivity and note residency or regulatory rules.
• Confirm software license terms for cloud use.
• Assign each workload a strategy from the 7 Rs.

Microsoft’s Cloud Adoption Framework stresses checking automated discovery against what workload owners know, because tools can miss undocumented dependencies.

Phase 2: plan and design

• Build a landing zone: account or subscription structure, networking, identity and guardrails.
• Set up identity with single sign-on and MFA, and apply least privilege. Our guide to zero trust security explains the model.
• Define tagging standards so every resource has an owner, environment and cost center.
• Configure logging, monitoring and alerting before workloads arrive.
• Design backup and disaster recovery for each tier.
• Model costs at several usage levels, including data transfer.
• Group workloads into waves, starting with simpler, non-production systems.
• Choose a cutover method per workload: planned downtime or near-zero downtime.
• Write a rollback plan for every wave.
• Communicate timelines to users and stakeholders.

Phase 3: migrate in waves

• Run a pilot wave with low-risk workloads to test tools and runbooks.
• Replicate data and test synchronization before cutover.
• Freeze changes on systems in the current wave.
• Run functional, performance and security tests in the target environment.
• Cut over during an agreed window with the rollback plan ready.
• Update DNS, firewall rules, certificates and integration endpoints.
• Hold a short retrospective after each wave and update the runbook.

Common cutover mistakes

• Skipping the rehearsal. Run a full dress rehearsal of the cutover for important workloads, including the rollback.
• Forgetting DNS time-to-live. Lower TTL values days before cutover so traffic switches quickly.
• Ignoring hard-coded addresses. Old IP addresses and hostnames buried in configs and scripts break integrations.
• No clear go or no-go call. Agree in advance who decides, based on which test results.
• Declaring victory too early. Keep the team on watch for the first business day after each wave, when real users arrive.

Who should be in the room

A migration touches more people than the infrastructure team. Name an owner for each workload who can sign off on testing, a security lead who approves the landing zone and access model, a finance contact who reviews cost forecasts, and a communications lead who tells users what’s changing and when. Small companies may have 1 person wearing several hats, which is fine as long as every role has a name next to it.

Treat infrastructure as code from the first wave. Teams with a good internal platform migrate faster and more consistently; see our piece on platform engineering.

Phase 4: validate, optimize and decommission

• Compare performance against the baselines from Phase 1.
• Confirm backups run and test a restore.
• Rightsize instances based on real usage after a few weeks.
• Buy commitments or savings plans only for steady, proven workloads.
• Shut down and decommission the old servers on a fixed date.
• Close out data center contracts and hardware support.
• Hand ongoing cost ownership to a FinOps practice.

Cloud cost traps to avoid

AWS’s Well-Architected cost optimization guidance specifically warns that data transfer fees are often neglected in designs carried over from on-premises, and it recommends modeling them per component.

Leaving a cloud later can also cost money. AWS offers free data transfer out to the internet for customers moving all their data off AWS, but you must request it through AWS Support before starting and it excludes some specialized services. Check current terms with any provider you’re considering.

For a deeper look at controlling cloud bills after you move, read our guide to FinOps and cloud cost optimization.

Where to start

1. Pick a business goal and a date. “Exit the data center by Q3” focuses decisions better than “move to the cloud.”
2. Run discovery for 2 to 4 weeks. Let tools collect real utilization and dependency data.
3. Retire first. Remove zombie and idle apps before you plan anything else.
4. Build the landing zone and guardrails. Security, identity, tagging and logging come before workloads.
5. Migrate a pilot wave. Learn on low-risk systems.
6. Scale in waves and optimize as you go. Rightsize, decommission and review costs after every wave.

Energy use is another reason to retire idle systems; our article on AI data center energy covers the wider picture.

Conclusion

A cloud migration checklist won’t remove every surprise, but it moves most of them to the planning stage where they’re cheap to fix. Inventory everything, choose a strategy per workload, migrate in small waves with rollback plans, and treat cost as a design requirement from day 1.

Sources

• AWS Prescriptive Guidance: About the migration strategies (7 Rs) — definitions of the 7 Rs, zombie and idle app thresholds, and refactor guidance for large migrations
• Microsoft Cloud Adoption Framework: Assess your workloads for cloud migration — baselines, dependency mapping, SLAs, RPO and RTO
• Microsoft Cloud Adoption Framework: Select your cloud migration strategies — choosing a strategy per workload
• AWS Well-Architected Cost Optimization Pillar: Plan for data transfer — data transfer modeling and cost controls
• AWS News Blog: Free data transfer out to internet when moving out of AWS — exit data transfer terms