Cloud migration checklist for enterprises: 40 steps before the first workload moves

Most cloud programmes fail on the work that happens before the first workload moves, not on the migration itself. This checklist is ordered the way the dependencies actually run — identity and network before compute, governance before scale, exit terms before signature.

It complements the enterprise cloud computing services guide and the cloud cost management basics.

The short answer

Sequence beats tooling. If identity federation, network topology and the account structure are settled first, the migration becomes repetitive work. If they are not, every workload becomes a project.

Phase 1 — inventory and ownership (steps 1–8)

1. List every application with a named business owner, not just a technical contact.
2. Record the runtime, dependencies, data stores and scheduled jobs for each.
3. Classify data sensitivity and residency requirements per application.
4. Map every integration to systems that are not moving yet.
5. Identify the applications with no owner — this is the long tail that always delays a cutover.
6. Measure current utilisation: CPU, memory, storage growth, peak windows.
7. Note licence constraints that change on shared infrastructure.
8. Agree the definition of “migrated” (running in production, not deployed in test).

Phase 2 — identity and access (steps 9–16)

9. Federate the existing directory with the cloud provider.
10. Define role mapping before onboarding users, not after.
11. Inventory service accounts and their credential storage.
12. Remove local database logins where federation is possible.
13. Decide the break-glass account policy and where its credentials live.
14. Set session duration and conditional access rules.
15. Plan privileged access review cadence.
16. Test the joiner-mover-leaver flow end to end.

Phase 3 — network and connectivity (steps 17–24)

17. Decide the CIDR ranges for each environment and reserve space for growth.
18. Choose the hybrid connectivity model: VPN, dedicated circuit, or both.
19. Document the DNS strategy, including split-horizon requirements.
20. Define egress paths and where inspection happens.
21. Plan for cross-region and cross-zone traffic cost.
22. Set up private endpoints for the data services that support them.
23. Agree the firewall rule ownership model — platform team or application team.
24. Test failover of the connectivity path before any workload depends on it.

Phase 4 — landing zone and governance (steps 25–32)

25. Create the account or subscription structure before the first workload.
26. Enforce tagging at creation with policy, not convention.
27. Set budget alerts per account and per cost centre.
28. Turn on the audit trail with retention long enough for your regulator.
29. Define the image and patch baseline.
30. Decide where secrets live and how they rotate.
31. Configure backup and verify a restore, not just a backup job.
32. Write the exception process; every control needs one or it gets bypassed informally.

Phase 5 — migration and exit (steps 33–40)

33. Rank workloads by dependency depth, not by size.
34. Migrate one thin slice end to end first, including monitoring and support.
35. Freeze the platform interface during migration, not the product roadmap.
36. Move data before compute where possible, and plan the dual-write window.
37. Define rollback criteria in numbers before the first cutover.
38. Measure cost per workload monthly from the beginning — retrofitting allocation is much harder.
39. Document the exit path for every managed service you adopt.
40. Schedule the first disaster recovery drill before the second migration wave.

The steps people skip, and what it costs

Data before compute. Moving the data layer first, while the old system still serves traffic, avoids dual-write bugs that surface in month three. Teams that move compute first spend the next quarter reconciling records.

Rollback criteria in numbers. “If error rate exceeds two percent for fifteen minutes, revert” is a decision. “If it looks bad, revert” is an argument at 2 a.m.

Exit documentation. Managed services are cheap to adopt and expensive to leave; the exit path is a design artefact, not a procurement detail.

A realistic timeline

Phase	Duration	Why it takes that long
Inventory and ownership	4–8 weeks	Unowned applications surface late
Identity and access	4–10 weeks	Federation and service accounts
Network and connectivity	6–12 weeks	Circuits and DNS propagation
Landing zone and governance	4–8 weeks	Policy and audit requirements
First migration slice	4–6 weeks	Monitoring and support readiness

Identity and network dominate the schedule. Compute is the easy part.

Who should run the programme

A migration needs one accountable owner and three part-time roles: an architecture lead who owns the landing zone, an identity lead who owns federation and service accounts, and a delivery lead who owns the cutover schedule. Assigning the programme to a committee is the most reliable way to reach month nine with nothing in production.

The platform team should own the landing zone, network topology and guardrails. Application teams own their workloads and their data moves. The boundary is worth writing down, because most programme friction is a disagreement about who owns DNS.

How to tell the programme is off track

• Wave one is still in progress after two quarters.
• Identity work is scheduled after the first migration.
• Cost allocation is deferred “until workloads are stable”.
• Every workload needs a bespoke network change.
• The rollback plan exists only as a conversation.

Any two of those together usually means the programme will be replanned rather than completed, and the replan costs more than the original schedule.

Frequently asked questions

How many workloads should the first wave include?

One to three, chosen for low dependency depth rather than business importance. The goal of wave one is to prove the platform, not to show progress.

Do we need a landing zone before the first workload?

Yes. Retrofitting account structure and tagging after workloads exist costs an order of magnitude more, and the migration pauses while it happens.

When should we involve finance?

At the inventory phase. Cost allocation depends on the tagging and account decisions made early, and a finance team joining in month six can only report on what was built.

Is lift-and-shift acceptable?

As a first move for stable applications, yes — it accelerates the platform work and defers optimisation. As a strategy for everything, no: it carries the old cost structure into the new environment.

Check also

• Enterprise cloud computing services — which service tier removes which work
• Cloud cost management basics — the four controls that reduce the bill
• CASB vs SSE vs SASE — the security layer that follows the workloads

Maintenance note

Provider limits, service availability and pricing change frequently. This checklist is reviewed quarterly against provider documentation, and the ordering reflects delivery experience rather than any vendor’s reference architecture.