TL;DR: A cloud migration checklist works as a sequencing tool: assess what you have, choose a strategy per workload, build the landing zone, move in waves, cut over with a tested rollback, decommission the source, then operate what you moved. Cloud2Gether is built around that last phase, which is the one most plans underestimate.
Key Takeaways:
- The order matters more than the list. Every item here is obvious in isolation. Migrations go wrong because the expensive decisions — identity, account structure, network layout — get made after workloads are already running on them.
- “Migrate” is seven different decisions. AWS names seven strategies, and the useful work is deciding which one applies to each application rather than picking one for the whole estate.
- Some workloads should not move at all. Retiring an application is a migration outcome, and the cheapest one. Discovery data usually shows more candidates than anyone expects.
- A rollback you have not tested is a hope. The cutover plan is only finished when someone has rehearsed the reversal in a non-production environment and knows how long it takes.
- The bill arrives after the move. Cost and configuration management is where a migration either delivers the business case or quietly does not, and it is the phase with the least planning attached to it.
What the checklist is actually for
Every major provider publishes a migration path, and they agree on the shape. Google Cloud describes four phases — assess, plan, deploy and optimize. Microsoft’s Cloud Adoption Framework runs plan, prepare workloads, execute, optimize, and decommission the source. The wording differs; the dependency order does not.
That order is the actual content of any cloud migration checklist. The individual tasks are unremarkable, and a competent team will think of most of them unprompted. What a checklist buys is the discipline to finish a phase before starting the next one, because the failures that hurt are sequencing failures: an identity model chosen after forty applications already authenticate against the old one, a network design settled by whichever workload happened to land first.
Phase 1: Assess what you actually have
Discovery produces two things: an inventory of what exists, and a dependency map of what talks to what. The second is the one that gets skipped, and the one that causes cutover weekends to overrun.
Microsoft’s framework splits dependencies into direct ones that need low latency and must move together, indirect ones that tolerate separation, and business dependencies where a reporting system needs to follow the system it reports on. The practical rule it offers is worth keeping: when you are unsure whether a dependency is critical, group the components together and migrate them as a unit. Splitting later is easier than recovering from an unplanned split.
Assessment is also when you find the workloads that should not move. AWS defines criteria for retirement directly from utilisation data: applications averaging below 5 percent CPU and memory are “zombie” candidates, those between 5 and 20 percent over 90 days are “idle”, and anything with no inbound connection for 90 days deserves a conversation before it gets a landing spot. Every application retired here is one you never have to migrate, test, cut over or pay for again.
Phase 2: Choose a strategy per workload
AWS’s seven migration strategies — the 7 Rs — exist because “move to the cloud” is not one decision. Applied per workload, they turn an amorphous programme into a set of scoped jobs.
| Strategy | What it means | Fits when |
|---|---|---|
| Retire | Decommission instead of moving | Utilisation is near zero, or no business owner appears |
| Retain | Leave it where it is, for now | Data residency, specialised hardware, or a pending SaaS replacement |
| Rehost | Move unchanged — “lift and shift” | Volume matters more than optimisation; modernise afterwards |
| Relocate | Move at platform level, architecture untouched | A hypervisor or managed platform has a cloud equivalent |
| Repurchase | Replace with a different product | A SaaS equivalent removes the maintenance burden entirely |
| Replatform | Move with targeted optimisation | A managed database or a newer OS pays for itself immediately |
| Refactor | Re-architect for cloud-native services | The application already blocks delivery, and the business case is explicit |
AWS is direct about the trade-off in large migrations: it recommends rehosting, relocating or replatforming, then modernising afterwards, because refactoring during a migration is the most complex option and hard to manage across many applications at once. Deciding to modernise later is a legitimate strategy, as long as it is written down as a decision rather than left as an intention.
Phase 3: Build the landing zone before anything moves
The landing zone is the account structure, identity model, network layout, logging and guardrails that everything else lands on. Microsoft treats an Azure landing zone as a prerequisite of the migration plan rather than a step inside it, which is the right relationship: these are the decisions that are painful to revisit once workloads depend on them.
This is well-covered ground, and the failure modes repeat across organisations of every size. We wrote about why a landing zone belongs on day one and about the specific mistakes that show up later — flat account structures, IAM that grows by exception, and budget alerts nobody configured. A migration is the moment those choices get locked in for years.
Phase 4: Sequence the moves into waves
Wave planning is where the dependency map earns its keep. The sensible progression is non-production first, then low-risk production, then the systems people would notice within minutes. Microsoft’s guidance adds a refinement worth copying: put one or two genuinely complex workloads in an early wave, so the problems specific to your estate surface while the stakes are still low.
Data movement needs its own decision per wave, and the constraint is usually bandwidth rather than preference. The Cloud Adoption Framework lays out the options plainly: a dedicated connection such as ExpressRoute where one exists, a VPN where it does not, a physical transfer appliance like Azure Data Box when the volume is large enough that shipping a disk beats saturating the link, and the public internet only for data that does not warrant better. Every provider offers the same four shapes under different names.
Phase 5: Cut over with a rollback you have tested
Each workload needs a cutover method chosen against its tolerance for downtime. A planned outage is simpler and faster, and it is the right answer for anything that can absorb one. Continuous replication with a near-zero-downtime cutover costs more in setup and testing, and it is what customer-facing systems with strict SLAs require.
The rollback plan is the part that gets written and never rehearsed. Microsoft’s framework is specific about what a finished one contains: an agreed definition of what counts as a failed deployment, thresholds that trigger the decision, automated steps where the pipeline can do the work, and — the part that matters — a simulated failure in a staging environment to prove the reversal actually restores a known-good state. A rollback procedure whose first real execution is during an incident is a plan on paper.
Phase 6: Decommission the source
Until the old environment is switched off, the organisation is paying for both. Microsoft’s five-step model ends with decommissioning the source for exactly this reason, and it is the step most likely to be deferred into a quarter nobody schedules.
Decommissioning is also a governance act, not just a cost one. A source system left running is a system still receiving traffic from something you did not find in discovery, still holding data under a retention policy, and still presenting an attack surface that no longer has an owner. Set the shutdown date during planning, with a verification step that confirms nothing is still calling it.
Phase 7: Operate what you moved
The migration ends and the operating problem begins. Flexera’s 2026 State of the Cloud Report, a global survey of more than 750 cloud decision-makers published in March 2026, found managing cloud spend named a top challenge by 85 percent of organisations, with 73 percent operating hybrid environments. Both numbers describe the phase after the move, not the move itself.
Two practices close the loop. Cost management, structured the way the FinOps Foundation frames it as Inform, Optimize and Operate, turns the business case into something measured rather than assumed — the problem we examined in managing multi-cloud complexity and costs. Configuration management is the other half: a migrated estate accumulates console edits from day one, which is the drift problem in its earliest and most treatable form. At Cloud2Gether, we observe that teams arrive at unified visibility after the migration, having spent the first months without it.
The checklist, in one place
| Phase | Done when |
|---|---|
| Assess | Inventory complete, dependencies grouped, retirement candidates agreed with owners |
| Decide | Every workload has one of the 7 Rs assigned, with the reason recorded |
| Prepare | Landing zone live: accounts, identity, network, logging, budget alerts |
| Sequence | Waves defined, non-production first, data path chosen per wave |
| Cut over | Method matched to downtime tolerance, rollback rehearsed in staging |
| Decommission | Source shut down on a scheduled date, verified as receiving no traffic |
| Operate | Cost ownership assigned, configuration drift monitored, business case measured |
The phases are cheap to read and expensive to skip. If a migration is already underway and one of these has no owner, that is the one to fix first — the later phases inherit whatever the earlier ones left undone.
See how Cloud2Gether handles the operate phase
Frequently asked questions
What is a cloud migration checklist?
It is a sequencing tool, not a to-do list. Its job is to make sure the decisions that are expensive to reverse — account structure, identity, network layout, which workloads move at all — are made before anything is copied, and that each later phase can only start once the one it depends on is finished.
What are the 7 Rs of cloud migration?
Retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. They are AWS’s seven strategies for moving an application, and the point of naming them is that the choice is made per workload rather than once for the whole estate.
Should you migrate everything at once?
No. Migrating in waves, starting with simpler and lower-risk workloads, lets a team refine the process before it reaches anything critical. Non-production environments are the usual first wave because they exercise the whole process without putting users at risk.
What has to be ready before the first workload moves?
The target environment: account or subscription structure, identity and access, network layout, logging, and budget alerts. These are the choices that are painful to change once workloads depend on them, which is why a landing zone is treated as a prerequisite rather than a later clean-up.
When is a cloud migration finished?
When the source environment is switched off and the new estate is under routine cost and configuration management. Until the old systems are decommissioned you are paying for both, and until someone owns the cost and drift questions the savings the business case assumed will not appear on their own.
Continue Your Cloud Governance Journey
A migration is the moment the shape of your estate gets decided. These go deeper on what comes next:
➡️ How to Avoid Cloud Vendor Lock-In in Multi-Cloud Strategies
