Azure migration checklist: 12 steps from assessment to go-live

Phase 1: Plan

1. Agree why you're migrating

Write down the drivers, for example end of support, a hardware refresh, a co-location exit, VMware costs or resilience. They decide your priorities and deadline. A fixed exit date changes the plan far more than a cost-saving goal does.

2. Discover everything

Deploy Azure Migrate to inventory servers and collect 2–4 weeks of performance data. Supplement it with interviews, because tools don't know which server runs the month-end report that only finance remembers.

• All servers, VMs and appliances listed
• Application owners identified
• Performance data collected (CPU, memory, disk, network)

3. Map dependencies

Use Azure Migrate's dependency analysis to see which servers talk to each other. Applications that depend on each other should move in the same wave, or you'll create latency problems across your network link.

4. Build the business case and plan

For each workload, decide whether to rehost, replatform, replace or retire. Estimate the one-off migration cost and the monthly Azure cost (see our cost guide), and check funding eligibility.

Phase 2: Build and migrate

5. Build the landing zone

Before any workload moves:

• Management groups and subscriptions
• Microsoft Entra ID roles and Privileged Identity Management
• Hub-and-spoke or Virtual WAN networking, plus VPN/ExpressRoute to your sites
• Azure Policy for security and tagging standards
• Azure Backup and Site Recovery policies
• Log Analytics and Microsoft Defender for Cloud
• Cost Management budgets and alerts

6. Plan the waves

Start with low-risk, low-dependency workloads to prove the process. Save business-critical systems for once you've done it a few times.

7. Replicate and test

Replicate each wave to Azure in the background, then run a test migration into an isolated network. Application owners check that everything works before the real cut-over.

8. Cut over

Agree a window (usually out of hours), communicate with users, perform the final sync, switch DNS and connections, and test again. Keep the source servers available for rollback.

9. Stabilise

Monitor performance and user feedback for 2–4 weeks. Fix anything that's slower than expected, usually by adjusting VM or disk sizes.

Phase 3: Optimise

10. Right-size

Compare actual Azure usage with what you provisioned and downsize where possible. Azure Advisor gives recommendations automatically.

11. Apply savings

Apply Azure Hybrid Benefit, buy reservations or a savings plan for steady workloads, and schedule non-production VMs to shut down out of hours.

12. Decommission and document

Securely wipe and dispose of old hardware, cancel unused support contracts and licences, and hand over runbooks and architecture documentation.

Get help applying it

Every step above is part of our standard Azure migration approach. If you'd like help applying it to your environment, start with a free assessment.

Frequently asked questions

What is the first step in an Azure migration?

Discovery. Build a complete inventory of servers, applications, databases and their dependencies, usually with the free Azure Migrate appliance, before making any design or cost decisions.

What is an Azure landing zone?

A landing zone is the pre-configured Azure foundation that workloads move into. It covers identity, networking, security policy, management groups, logging, backup and cost controls, all built to Microsoft's Cloud Adoption Framework.

How many migration waves should we plan?

It depends on size and dependencies. Small estates (under 10 servers) often move in a single wave. 11–50 servers typically need 2–4 waves, and larger estates need more. Group servers that depend on each other into the same wave.

When should we decommission on-premises servers?

After a stabilisation period, typically 2–4 weeks after each wave's cut-over, once users have signed off and backups in Azure are proven.