Cloud migration checklist for 2026: every phase, from assessment to decommission

A cloud migration checklist is a phase-by-phase list of tasks for moving applications, data and infrastructure to a cloud provider safely. It covers assessing every workload, choosing a migration strategy for each, building the target environment, migrating in tested waves with rollback plans, then optimising costs and shutting down the old environment.

Most cloud migration guides are narratives. This one is a checklist you can tick, built on what the three largest cloud providers publish: the AWS Well-Architected Migration Lens ("The three phases of an AWS Migration consist of assess, mobilize, and migrate and modernize"), Microsoft's Cloud Adoption Framework and Google Cloud's migration guide (assess, plan, deploy, optimise). The phases below combine them. It's written for IT leads and founders moving business systems, not for one-off website moves; for those, use our website migration checklist.

What are the 7 Rs, and which should each workload use?

AWS Prescriptive Guidance says: "There are seven migration strategies for moving applications to the cloud, known as the 7 Rs". Decide one per workload during assessment.

Two AWS points save money and risk. First, it suggests retiring applications whose average CPU and memory usage is "below 5 percent", which it calls zombie applications, and reviewing idle ones between 5 and 20 percent over 90 days. Second, "Refactor is not recommended for large migrations"; AWS recommends rehosting, relocating or replatforming first and modernising after the move.

Phase 1: what should you assess?

Google Cloud describes this phase as one where "you perform a thorough assessment and discovery of your existing environment". In practice:

Inventory and dependencies

• List every application, server, database, storage volume, scheduled job and integration.
• Map dependencies: which systems talk to which, on which ports, how often. Hidden dependencies cause most cutover surprises.
• Identify owners and business criticality for each application.
• Flag licensing constraints (databases, operating systems, vendor software tied to hardware).

Baselines

• Record current costs: hardware, data centre or colocation, licences, support contracts and staff time.
• Record performance: CPU, memory, storage IOPS, network throughput and response times at peak.
• Record availability and recovery targets (RTO and RPO) the business actually needs.

Strategy and skills

• Assign one of the 7 Rs to each workload.
• Mark retire candidates using utilisation data.
• Assess team skills in the target cloud and plan training or outside help.
• Build the business case: cost, risk, resilience and what the move enables.

Phase 2: how do you plan and mobilise?

Landing zone

• Set up the account or subscription structure, billing, tagging standards and guardrails.
• Configure identity: single sign-on, roles, least-privilege access and break-glass accounts.
• Design networking: address ranges, VPN or private connectivity to on-premises, DNS, firewalls.
• Turn on logging, monitoring, backup policies and security baselines from day one.

Data transfer

• Size the data and choose a method: online replication, database migration services or physical transfer devices for very large volumes.
• Plan for change during transfer: initial copy plus ongoing sync until cutover.

Waves and downtime

• Group workloads into waves by dependency and risk; start with low-risk ones.
• Choose the downtime method per workload: cold cutover in a maintenance window, or replication with a short switch.
• Follow Microsoft's sequencing: "Migrate development, staging, and QA environments before production to validate readiness."
• Agree communications: who is told what, and when.

Phase 3: how do you migrate safely?

Microsoft's guidance is blunt: "Always establish rollback criteria and procedures before initiating any migration or deployment."

Pilot

• Migrate one representative, low-risk workload end to end.
• Measure the real time each step takes, and update the runbook.

Cutover runbook (per wave)

• Freeze changes on the source.
• Final data sync and integrity checks (row counts, checksums, sample records).
• Switch DNS, connection strings or load balancers.
• Smoke tests: logins, key transactions, integrations, scheduled jobs.
• Business sign-off from the application owner.

Rollback triggers (agree before the window opens)

Keep the source environment intact and in sync, where possible, until each wave has run cleanly for an agreed period.

Phase 4: how do you optimise and decommission?

Moving to the cloud doesn't lower costs on its own. AWS's Migration Acceleration Program page claims legacy migrations "achieve an average of 31% infrastructure savings"; that's AWS's own marketing figure, and savings depend on what you do after the move. Flexera's 2026 State of the Cloud survey of "more than 750 cloud decision-makers and users" reported an "increase in wasted cloud spend (29%) for the first time in five years", and said managing cloud spend "remains a top challenge (85%)".

FinOps

• Tag every resource by owner, environment and cost centre.
• Set budgets and alerts per account or project.
• Compare monthly costs with your Phase 1 baseline.

Rightsizing

• Resize instances based on real utilisation after two to four weeks of data.
• Schedule non-production environments to shut down out of hours.
• Commit to reservations or savings plans only for steady workloads you've measured.
• Move infrequently accessed data to cheaper storage tiers.

Decommission

• Set a date to switch off the source environment, and keep it.
• Take final backups and archive what you must retain.
• Cancel hardware support, colocation and licence contracts on time.
• Securely wipe and dispose of hardware.

How do you handle security, compliance and data residency?

Decide where data may live before you choose regions. This is a planning summary, not legal advice; confirm with your own counsel.

For every market:

• Encrypt data in transit and at rest; manage keys deliberately.
• Turn on audit logging and keep logs for the period your policies require.
• Review the shared responsibility model: the provider secures the cloud, you secure what you put in it.
• Run a security review of the landing zone before production workloads arrive.

What are the most common cloud migration mistakes?

• Skipping dependency mapping, then discovering a forgotten integration at cutover.
• Refactoring everything during the move instead of migrating first and modernising after.
• Treating rehosted servers as finished, so oversized instances run at full price for years.
• No rollback plan, or one nobody has tested.
• Never switching off the old environment.
• Leaving cost ownership unassigned, so nobody watches the bill.

Which tools help at each phase?

Each provider offers its own discovery and migration tooling, and most migrations also use third-party tools for monitoring and backup. Use the provider's tools where they fit; they're built for its landing zones.

Tool names and features change often, so check each provider's current documentation before you plan around one.

How do you choose between AWS, Azure and Google Cloud?

All three can run almost any business workload. The deciding factors are usually practical, not technical:

• Existing licences and skills. Teams on Microsoft 365, Windows Server and SQL Server often find Azure simplest; teams with AWS experience move faster on AWS.
• Where your data must live. Check that the provider has regions in the countries your contracts and regulators require.
• Managed services you'll actually use. Compare the specific databases, analytics and AI services your roadmap needs, not the full catalogue.
• Commercial terms. Migration programmes, credits and committed-spend discounts differ by provider and change often; get them in writing.
• Support. Decide which support plan you need before production workloads arrive.

If you already run on one provider, a multi-cloud strategy adds cost and complexity; adopt it for a clear reason, such as a specific service or a regulatory need, not by default.

What's on the printable cloud migration checklist?

How can Elgrith help?

Elgrith has delivered 1,000+ projects for 250+ clients since 2015, from our New Delhi headquarters and client centers in New York, London and Shanghai. Our cloud migration team runs assessments, landing zones and migration waves, and our DevOps consulting team sets up CI/CD, monitoring and cost controls afterwards. Moving an ERP as part of the change? See ERP development. We don't claim cloud partner tiers; we give you a fixed written quote after a free call, and you keep full ownership of your accounts. Book a call or start a project.