Cloud Migration Checklist

This cloud migration checklist has 45 steps in seven phases: discovery and inventory, strategy per workload, landing zone, security and compliance, migration waves, validation, and optimization and decommission. It applies whether you are moving three servers or three hundred, to Azure, AWS or Google Cloud. Work through the phases in order, because each one produces something the next depends on: the inventory feeds the strategy, the strategy sizes the landing zone, the landing zone receives the waves. Each phase ends with a named owner signing off on specific evidence, and the last section lists the steps teams most often skip.

• The checklist by phase
• Owner and sign-off per phase
• Common misses
• Where PS3G fits
• Frequently asked questions

The cloud migration checklist by phase

Phase 1: Discovery and inventory

You cannot plan what you have not counted. Discovery tooling finds the servers; interviews find the owners and the surprises.

1. Run automated discovery (the Azure Migrate appliance, AWS Application Discovery Service or Google Cloud Migration Center) for long enough to capture a busy period such as month-end, not just a quiet week.
2. Build the inventory: every server, virtual machine, database, application, file share, scheduled job, integration and SaaS connection, each with a named owner.
3. Map dependencies with agentless or agent-based dependency analysis, then confirm the map with application owners and note hard-coded IP addresses and hostnames.
4. Record licensing for Windows Server, SQL Server, Oracle, VMware and third-party products, including Software Assurance and license mobility rights.
5. Classify data: which systems hold regulated or sensitive data (health records, cardholder data, personal data) and which retention rules apply.
6. Capture performance baselines (response times, batch durations, backup windows) so “slower than before” can be measured later rather than argued about.
7. List constraints: vendor support statements for cloud hosting, data-residency requirements, customer commitments, hardware warranty and lease end dates.

Phase 2: Strategy per workload

A cloud migration plan is a list of per-workload decisions, not a single verdict for the whole estate.

8. Assign each workload one of the six Rs (rehost, replatform, refactor, repurchase, retire, retain) and record the reason. Our guide to the 6 Rs of cloud migration strategy walks through the choice.
9. Choose the target platform (Azure, AWS or Google Cloud) from existing licenses, team skills, required managed services and modeled run cost.
10. Build the run-cost model in the vendor’s pricing calculator, including storage, backup, data egress, licensing, logging and support, not compute alone.
11. Decide the target service per workload: virtual machine, App Service or Elastic Beanstalk, containers, or a managed database tier.
12. Write the business case: one-time migration cost, ongoing run cost, avoided costs (hardware, licenses, data center) and the main risks.
13. Get the strategy signed off by the business owner of each system and by finance before the landing zone is built.

Phase 3: Landing zone and foundations

The landing zone is the part of the migration nobody sees and everybody depends on. Build it before the first workload moves and build it as code.

14. Design the subscription or account structure: management groups or organizational units, with production separated from non-production.
15. Set up identity: Microsoft Entra ID or AWS IAM Identity Center, single sign-on, multi-factor authentication enforced, break-glass accounts and least-privilege roles.
16. Build the network: hub-and-spoke or transit gateway, an address space that does not overlap the on-premises range, a VPN or dedicated circuit, and DNS resolution both ways.
17. Define the tagging standard (owner, cost center, environment, application) and enforce it with policy so untagged resources cannot be created.
18. Enable central logging and monitoring: a log workspace, activity and audit logs, and alert routes to people who can act.
19. Configure backup policies and a disaster-recovery target (Azure Backup and Site Recovery, AWS Backup) with retention per data class.
20. Write the landing zone in Terraform or Bicep, keep it in a repository with pull-request review, and prove it by deploying to a sandbox first.
21. Set budgets and cost alerts per subscription or account before anything lands in it.

Phase 4: Security and compliance

Security controls cost least to apply to an empty environment. Do this phase before the waves, not after an audit finding.

22. Apply guardrails as policy (Azure Policy, AWS Config rules and service control policies): allowed regions, required encryption, no public storage, required tags.
23. Enable threat detection (Microsoft Defender for Cloud, AWS Security Hub and GuardDuty) and record the baseline secure score.
24. Set up key and secret management (Azure Key Vault, AWS KMS and Secrets Manager), plan rotation, and remove embedded passwords found during discovery.
25. Restrict administrative access: no public RDP or SSH, a bastion host or private connection, and just-in-time access where the platform supports it.
26. Confirm the compliance paperwork: a business associate agreement with the provider where health data is involved, data-processing terms, and the provider’s audit reports mapped to your framework. This is general information, not legal advice.
27. Update the incident-response and business-continuity plans for the cloud environment, including who is called and how access is granted in an emergency.

Phase 5: Migration waves

Waves limit the blast radius. The first one should be small enough that a failure is an inconvenience and a success is a template.

28. Group workloads into waves by dependency and risk; make wave one a low-risk, self-contained system such as a test environment or an internal tool.
29. Write a runbook per wave: steps, owners, timings, go/no-go criteria, communication plan and rollback procedure.
30. Lower DNS time-to-live values on affected records several days before cutover so the switch propagates quickly.
31. Start replication (Azure Migrate, AWS Application Migration Service, Google Migrate to Virtual Machines) and confirm the initial sync completes for every server in the wave.
32. Migrate databases with the platform’s database migration service: schema assessment first, a pilot run, then an online sync or an agreed offline window.
33. Transfer bulk data with AzCopy, AWS DataSync, Storage Transfer Service or an offline appliance, and verify checksums at the destination.
34. Run a test cutover in an isolated network and have application owners test against it before the real one.
35. Execute the production cutover in the agreed window: switch DNS, update firewall rules, integrations and third-party allowlists, and report status at each checkpoint.

Phase 6: Validation and sign-off

A wave is not done when the servers boot. It is done when the owner says so, with evidence.

36. Functional acceptance by application owners against the test list agreed before the wave.
37. Performance compared with the discovery baseline, with sizing or latency fixed before sign-off rather than logged for later.
38. Data reconciled: row counts, checksums and last-transaction checks, signed off by the data owner.
39. A backup restored successfully, monitoring and alerts confirmed to fire, and the security configuration checked against the landing-zone standard.
40. Hypercare for an agreed period with a named engineer on call, then formal sign-off and closure of the wave.

Phase 7: Optimize and decommission

The savings arrive in this phase, and so does the risk of paying for two environments forever.

41. Right-size from real usage, apply reservations or savings plans to the steady-state footprint, and set shutdown schedules for non-production.
42. Review storage tiers, snapshots, orphaned disks and public IP addresses, and logging ingestion volumes; tune each one.
43. Decommission the source servers after the agreed retention period: wipe disks, cancel hardware support and licenses, and update the asset register.
44. Bring documentation, runbooks, the disaster-recovery plan and architecture diagrams up to the as-built state, and train the operations staff.
45. Set the operating rhythm: monthly cost review, quarterly reservation review, patching cadence and access reviews, run by your team or a managed-services provider.

Owner and sign-off per phase

Every phase needs one person who owns it and one person who signs it off, and they should not be the same person. The table is a starting point; adjust the titles to your organization.

Phase	Owner	Sign-off from	Evidence
Discovery and inventory	Infrastructure lead	IT director	Inventory with owners, dependency map, baselines
Strategy per workload	Cloud architect	Business owners and finance	Per-workload decisions, run-cost model, business case
Landing zone	Platform or DevOps lead	Security lead	Code repository, sandbox deployment, policy report
Security and compliance	Security lead	Compliance officer or executive sponsor	Guardrail policies, secure score baseline, signed agreements
Migration waves	Migration lead	Application owners	Runbooks, test-cutover results, cutover log
Validation	Application owners	Migration lead and data owner	Acceptance results, reconciliation report, restore test
Optimize and decommission	Operations lead	Finance and IT director	Cost report, decommission records, updated runbooks

Common misses

These are the cloud migration steps that cause most of the post-cutover incidents we see. None of them is hard; all of them are easy to forget.

• Third-party allowlists. Partners, payment gateways and banks that allow traffic only from your old public IP addresses. Collect the list in discovery and notify them before the wave.
• Service accounts and scheduled jobs. Tasks that run under an account nobody remembers, on a server nobody listed. Dependency mapping catches most; the rest surface at month-end.
• Licensing assumptions. Bringing SQL Server licenses without the required Software Assurance, or running Windows on shared hardware where the license terms do not allow it. Check the current licensing terms before you plan on them.
• Egress and inter-region traffic. A chatty application split across on-premises and cloud during a long transition can generate data-transfer charges that nobody modeled. Keep tightly coupled systems in the same wave.
• Backups that exist but have never been restored. Configure backup in the landing zone and restore one before sign-off, every wave.
• DNS TTLs left at a day. Lower them early or the cutover takes a day to propagate.
• The decommission that never happens. Old servers kept “just in case” for a year, still licensed, still backed up and still a security exposure. Put the retention period and the decommission date in the runbook.
• Nobody owning cost after go-live. The bill grows quietly without a monthly review. Our guide to cloud cost optimization covers the routine.
• Treating every workload as a lift-and-shift. Some systems should be modernized on the way or retired instead; our comparison of legacy system modernization approaches helps with that call.

Where PS3G fits

PS3G runs this checklist as a service. Our cloud migration services cover discovery with the vendor tooling, a per-workload strategy with a run-cost model, a landing zone written in Terraform or Bicep, migration in waves with test cutovers and rollback plans, validation evidence per wave, and the optimization and decommission work afterwards. We work on Azure, AWS and Google Cloud for organizations of every size, from a founder with a few servers to an IT department with a data center to empty, and we can hand the environment back to your team or run it under managed services.

Related reading

• Cloud Migration Strategy: The 6 Rs Explained with Examples
• Cloud Cost Optimization: 20 Ways to Cut Azure and AWS Bills
• Legacy System Modernization: 6 Approaches Compared (and How to Pick)
• Cloud migration services from PS3G

Frequently asked questions

How long should discovery run before a cloud migration?

Long enough to capture the busiest period your systems see, which for most organizations means a full month including a month-end close or a seasonal peak. Sizing from a quiet fortnight produces undersized targets and a bad first impression. Interviews with application owners run in parallel, so discovery time is also planning time.

What should we migrate first?

Something small, self-contained and low-risk: a test environment, an internal tool, a file share with a known owner. The first wave exists to prove the landing zone, the runbook and the cutover process, not to deliver savings. Once it is signed off, the same runbook scales to the business-critical waves with far fewer surprises.

Do we need a landing zone for a small migration?

Yes, scaled down. A small environment still needs separate production and non-production, enforced multi-factor authentication, a tagging standard, central logging, backup policies and a budget alert. Written as code, a small landing zone is a few files and an afternoon of review, and it stops the environment from becoming the unmanaged sprawl that makes a later cleanup expensive.

How do we know a migration wave is finished?

When the application owner has accepted it against the agreed test list, performance matches the baseline, data is reconciled, a backup has been restored, alerts have been seen to fire, and hypercare has ended without open incidents. A wave that has “mostly” met those conditions is not finished; the open items go on the runbook with owners and dates.

What do we do with the old servers after migration?

Keep them powered off but intact for the agreed retention period, in case a rollback or an audit needs them, then wipe the disks, cancel support contracts and licenses, and record the decommission in your asset register. Set the decommission date in the runbook at the start, because servers kept “just in case” tend to stay licensed and exposed for years.