Azure Migration Checklist: Pre-Migration Steps That Prevent Failed Cutovers

• Last updated: 30 July 2026
• Azure
• Written by Editorial Team

Failed migrations do not fail on migration night. They fail three weeks earlier, quietly, when nobody mapped the dependency between the ERP application and a forgotten license server, or when the rollback plan turned out to be a sentence in a slide deck instead of a tested procedure. By the time the cutover window opens, the outcome is already decided.

That is the good news, even if it does not sound like it. If migrations are won or lost in preparation, then a disciplined pre-migration checklist is the highest-leverage document in the entire project. This is the checklist we run before moving workloads to Azure: nine phases, each with the specific checks that separate a boring cutover (the goal) from a long night of speakerphone triage.

Work through it in order. Every phase gates the next.

Why Azure Migrations Fail, in One Paragraph

Post-mortems on troubled migrations converge on the same handful of causes: incomplete inventory (a server nobody knew about), unmapped dependencies (an application moved without its database or its license service), no tested rollback (so a fixable glitch became an outage), sizing copied from on-premises specs (so the bill shocked finance in month one), and DNS or identity details discovered at 2 a.m. instead of 2 p.m. Notice what is not on the list: Azure itself. The platform rarely fails a migration. Preparation does.

Phase 1: Discovery and Inventory

You cannot migrate what you cannot see, and every environment contains servers that predate everyone currently employed to manage them. Deploy Azure Migrate discovery (agentless against VMware and Hyper-V, appliance-based for physical servers) and let it run for at least two to four weeks so utilization data captures real business cycles, including month-end.

• Confirm every server, application, and database appears in the inventory, then reconcile against your CMDB, billing records, and backup catalogs. The discrepancies are the finds.
• Capture OS versions and support status. End-of-life systems change the migration math and the urgency.
• Record performance baselines (CPU, memory, disk IOPS, network) so right-sizing has data instead of folklore.
• Identify the owner of every application. If nobody claims it, flag it as a retire candidate rather than migrating an orphan.
• Note anything physical that cannot follow: USB license dongles, fax boards, direct-attached scanners, plant-floor connections.

Phase 2: Dependency Mapping

The most expensive sentence in any migration post-mortem is “we didn’t know those two systems talked to each other.” Azure Migrate’s dependency analysis shows the actual network conversations between servers, which is not the same thing as what the architecture diagram from 2019 claims.

• Map application-to-database, application-to-application, and application-to-service dependencies, including authentication (domain controllers), name resolution (DNS), file shares, and print services.
• Hunt for the quiet dependencies that break cutovers: license servers, SMTP relays, scheduled jobs on other machines, hardcoded IP addresses, and integrations with vendor systems over site-to-site VPNs.
• Group workloads into move groups that migrate together, so no wave splits a chatty dependency across a WAN link.
• For each move group, document latency sensitivity. An application that tolerates 2 ms to its database may not tolerate 40 ms during a phased migration.

Phase 3: Assign a Strategy to Every Workload

Before anything replicates, every workload needs a decision: rehost to Azure VMs, replatform to a managed service, refactor, replace with SaaS, retire, or retain on-premises. The full decision framework is covered in our guide to Azure migration strategy, so here is only the checklist view:

• Every inventoried workload has exactly one assigned strategy and a one-line justification written next to it.
• Retire and replace candidates are confirmed with their owners and scheduled for decommission, shrinking the migration before it starts.
• Vendor support statements are on file for anything moving: confirm each application is supported on Azure and on the target OS version, in writing, before cutover rather than during a support call after it.
• Databases have a target decision (SQL Server on a VM vs Azure SQL Managed Instance) validated with a compatibility assessment, not an assumption.

Phase 4: Landing Zone and Foundation Readiness

Migrating into an ungoverned subscription is how organizations end up rebuilding their environment twice. The destination must exist, and it must be governed, before the first workload arrives. This is the Azure landing zone, and the pre-migration checks are concrete:

• Management group hierarchy and subscriptions exist, with Azure Policy enforcing allowed regions, required tags, and security baselines.
• Hybrid identity is live: Entra Connect syncing, conditional access tested, and break-glass accounts documented.
• Network is provisioned end to end: hub and spoke VNets, ExpressRoute or VPN connectivity tested at expected throughput, IP ranges that do not collide with on-premises, and DNS resolution working in both directions.
• Centralized logging and monitoring are collecting from day one, so the first migrated workload is observable the moment it boots.
• Naming and tagging standards are published, because retro-tagging three hundred resources is a punishment nobody deserves.

Phase 5: Licensing and the Cost Model

The migration that succeeds technically and fails financially is still a failed migration. Cost surprises are almost always self-inflicted, and they are preventable at this phase:

• Size target VMs from utilization data, not from on-premises specs. Matching a chronically idle 16-core server with a 16-core VM is the classic month-one bill shock.
• Inventory Windows Server and SQL Server licenses with Software Assurance and apply Azure Hybrid Benefit wherever eligible; it is one of the largest single levers on the Azure bill.
• Model reservations or savings plans for steady-state workloads, and leave burst-prone workloads on pay-as-you-go until real usage patterns emerge.
• Budget the transition period honestly: replication traffic, temporary parallel running, and egress from the old environment all cost money for a few weeks.
• Set Azure budgets and cost alerts before cutover, scoped per subscription, so drift gets caught in days rather than at invoice time.

Phase 6: Security and Compliance Before Data Moves

• Classify the data in scope. Anything regulated (patient records, cardholder data, controlled information) dictates region choices, encryption requirements, and who may access the migration tooling itself.
• Verify Microsoft Defender for Cloud is enabled on target subscriptions and that its recommendations are reviewed, not just collected.
• Confirm encryption in transit for the replication path and encryption at rest on target disks and storage accounts.
• Apply least-privilege RBAC to the migration project itself. Migration tooling holds powerful permissions and deserves the same scrutiny as any privileged system.
• If compliance frameworks apply, map each required control to its Azure implementation now, and brief your auditor before the move rather than after. Auditors dislike surprises even more than IT teams do.

Phase 7: Backup, Rollback, and the Way Home

A rollback plan that has never been executed is a hypothesis. Before any production cutover:

• Take verified, restorable backups of every workload in the wave, and actually restore one to prove the backups are real.
• Write the rollback procedure per move group: what gets reverted, in what order, who decides, and how long it takes. Time it during rehearsal.
• Define the rollback trigger in advance: the specific failures and the specific time (for example, unresolved critical issues at hour four of a six-hour window) that flip the decision. Deciding this at 3 a.m. under pressure produces bad answers.
• Keep the source environment intact and bootable for an agreed period after cutover. Decommissioning the old servers is a milestone for week four, not migration night.

Phase 8: Pilot Wave and Test Failovers

• Choose a pilot wave of genuinely low-risk workloads and run the entire process end to end: replication, test failover, validation, cutover, and post-checks. The pilot’s job is to break the process while breaking it is cheap.
• Use test failovers into an isolated network for every subsequent wave. Application owners sign off on function, not just on “the VM booted.”
• Script the validation: login tests, transaction tests, integration tests, print tests, report tests. A checklist per application, executed by a named person, with results recorded.
• Measure cutover duration during rehearsal and compare it to your window. Hope is not a scheduling method.

Phase 9: The Cutover Runbook

The runbook is the difference between a cutover and an improvisation. Ours follow a T-minus structure:

• Every runbook step has a named owner, a start condition, an expected duration, and a verification. “The team migrates the database” is not a runbook entry; “DBA initiates final DMS cutover at 22:00, expected 40 minutes, verified by row-count comparison script” is.
• Lower DNS TTLs at least a day ahead so the switch propagates in minutes instead of hours.
• Publish the communication plan: who is told what, when, through which channel, including the version sent if things go wrong. Draft that one in advance too.
• Schedule the go/no-go meeting with the people empowered to say no, and give them real criteria to judge against.
• Staff hypercare for the first business days after cutover, when users find the issues that testing did not.

The One-Page Version

For the project wall, the whole checklist compresses to nine gates:

#	Gate	You Are Ready When
1	Discovery	Inventory reconciled against CMDB, billing, and backups; owners named
2	Dependencies	Move groups defined from observed traffic, not old diagrams
3	Strategy	Every workload has one assigned R and a written justification
4	Landing zone	Identity, network, policy, and logging live and tested
5	Cost model	Utilization-based sizing plus Hybrid Benefit modeled; budgets and alerts set
6	Security	Data classified, encryption verified, RBAC scoped, auditor briefed
7	Rollback	Backups restore-tested; rollback timed and trigger criteria written
8	Pilot	Full process proven end to end; validation scripts signed off per app
9	Runbook	Minute-level plan with owners, durations, go/no-go, and hypercare staffed

How Apps4Rent Runs This Checklist for You

Apps4Rent is a Microsoft Solutions Partner and Tier-1 Cloud Solution Provider, SOC 2 Type II certified, and has moved workloads to Microsoft’s cloud for over 10,000 businesses since 2003. This checklist is not theory to us; it is the working structure of our Azure migration services. Our team runs discovery and dependency analysis, builds the landing zone, models licensing with Hybrid Benefit, writes and rehearses the runbooks, staffs the cutover and hypercare around the clock, and then keeps the environment patched, monitored, and cost-optimized after go-live through our Azure managed services. As a CSP, we also provision subscriptions and consolidate billing, so one partner owns the checklist from phase 1 through day 2.

Frequently Asked Questions

1. What should an Azure migration checklist include?

   A complete Azure migration checklist covers nine areas: full discovery and inventory, dependency mapping, a migration strategy assigned per workload, landing zone readiness, licensing and cost modeling, security and compliance verification, tested backup and rollback procedures, a pilot wave with test failovers, and a detailed cutover runbook with named owners and go/no-go criteria.

2. How long should pre-migration planning take?

   For most mid-size environments, allow four to eight weeks before the first production cutover. Discovery alone should run two to four weeks so utilization data captures real business cycles, and the remaining time covers dependency analysis, landing zone preparation, licensing decisions, and pilot testing. Compressing this phase is the most common way projects create the failures they later spend months fixing.

3. What is the most commonly missed step before an Azure migration?

   Dependency mapping, and specifically the quiet dependencies: license servers, SMTP relays, scheduled jobs running on other machines, hardcoded IP addresses, and vendor integrations. Applications are rarely missed in inventory, but the services they silently rely on frequently are, and those are what break during cutover windows.

4. How do I plan a rollback for an Azure migration?

   Take restore-tested backups of every workload in the wave, write a per-move-group rollback procedure with owners and timing, define the trigger criteria in advance that would flip the decision, and keep the source environment intact and bootable for an agreed period after cutover. A rollback plan that has never been rehearsed should be treated as untested.

5. What tools does Microsoft provide for migration assessment?

   Azure Migrate is the central hub: it provides agentless discovery for VMware and Hyper-V environments, utilization-based right-sizing assessments, dependency analysis, and orchestrated replication and test failovers. For databases, Azure Database Migration Service and its assessment tooling identify compatibility issues before the move. Together they supply the data that phases one, two, five, and eight of this checklist depend on.

6. Should I migrate everything to Azure at once?

   No. Migrate in dependency-complete waves, starting with a deliberately low-risk pilot wave that proves the entire process end to end. Wave-based migration limits the blast radius of any issue, lets each wave’s lessons improve the next, and keeps rollback plans small enough to actually execute.