Azure Migration Checklist: A Step-by-Step Guide

The moment an Azure migration goes wrong is rarely the cutover weekend everyone plans anxiously around. It’s months earlier, when the landing zone step gets compressed or skipped entirely to hit a deadline — and the organization spends the following year discovering, one workload at a time, everything that foundational step was supposed to prevent.

Why Sequence Matters More Than Speed

Microsoft’s Cloud Adoption Framework exists because migrating infrastructure to Azure isn’t fundamentally a lift-and-shift exercise — it’s an opportunity to land on a properly governed foundation, and that foundation has to exist before workloads arrive, not get retrofitted underneath them afterward. Retrofitting security baselines, network segmentation, and governance onto an environment that’s already hosting production workloads is measurably harder and riskier than building it first.

Step 1: Migration Assessment

Before any resource moves, a full inventory of on-premise workloads — using Azure Migrate for automated discovery — establishes compatibility, sizing, and a real cost comparison against current on-premise spend. This is also the step that surfaces the workloads nobody remembered still existed, which is common enough to expect it rather than be surprised by it.

Step 2: Azure Landing Zone Design

This is the step that determines whether the rest of the migration goes smoothly or turns into an ongoing refactoring project. A landing zone establishes management group hierarchy, subscription structure, hub-spoke networking, identity foundations, and security baselines — Azure Policy and Microsoft Defender for Cloud configured from day one, not added after an incident makes it urgent. Every workload that migrates afterward inherits this foundation automatically, rather than needing individual retrofitting.

Step 3: Phased Migration Execution

Migrating in waves — non-critical workloads first, production later — rather than a single cutover event, with parallel run periods and validation checks at each stage. Each wave should include a planned cutover window, not an open-ended “move it and see.” This is also where the actual downtime-minimisation techniques matter: Azure Site Recovery for continuous replication ahead of cutover, reducing the actual cutover window itself to 15-30 minutes for most Windows workloads, and Azure Database Migration Service handling the database-specific migration path with its own replication-based cutover.

Step 4: Optimisation and Decommission

Migration doesn’t end at cutover. Post-migration right-sizing (matching Azure resource sizing to actual observed usage rather than a like-for-like copy of on-premise specs), implementing Reserved Instances for workloads with predictable, stable usage, and — only once the new environment has proven stable — safely decommissioning the on-premise hardware it replaced.

What Skipping the Landing Zone Actually Costs

There’s no case study substitute for this — it’s a pattern, not a single incident: organisations that migrate quickly by skipping proper landing zone design consistently end up spending more time retrofitting security and governance after the fact than the landing zone step would have taken up front. The false economy is specifically in the sequencing, not the total amount of work.

What Migration Done Properly Looks Like

A professional services firm running 15 Windows servers on seven-year-old hardware was facing a $180,000 hardware refresh within 12 months, running at just 40% average CPU utilisation, with no disaster recovery capability and Exchange still hosted on-premise. Migrating all 15 workloads to Azure over 12 weeks — Exchange moved to Exchange Online, Azure Backup providing disaster recovery for the first time, and right-sized virtual machines achieving 80% utilisation — avoided the $180K hardware refresh entirely, landed on an ongoing infrastructure cost of $42K a year against a comparable $28K a year in prior on-premise operating cost plus the looming refresh, and delivered genuine disaster recovery capability the organisation had never had.

Getting the Sequence Right

If on-premise hardware is approaching end-of-life, or a previous migration attempt stalled partway through, the landing zone step is worth treating as non-negotiable rather than a nice-to-have that can be compressed under deadline pressure. Azure migration services follow the Cloud Adoption Framework specifically because the sequence is what determines whether the migration actually lands well.