Azure Migration Plan: 16-Week Template With Waves and Cutover

8 min read ยท 2026-10-25

An Azure migration plan lists the workloads you will move, the method for each one, the order in which they move and the dates, owners and rollback steps for every cutover. It turns a goal like "get out of the data center" into waves your team can schedule and your business can approve.

The template below covers 16 weeks for a first set of workloads, in six phases: discovery and assessment, landing zone, wave planning, a pilot migration, the main waves and decommissioning. It follows the broad flow Microsoft describes in the Cloud Adoption Framework (plan, prepare, execute, optimize, decommission) and adds what teams usually find out too late: dependency mapping, business sign-off on downtime windows, a cutover runbook and a rollback plan for every wave.

The roadmap at a glance

Goal: The first wave of workloads runs in Azure in production, users have signed off, and the matching on-premises servers are switched off. Duration: 16 weeks

  1. Discovery and assessment (Weeks 1-3)

    Know exactly what you have, how it connects and what it should become in Azure.

    • Build an inventory of servers, databases, applications and their owners, using Azure Migrate discovery plus your CMDB.
    • Map dependencies between applications, databases and outside systems, and confirm them with each application owner.
    • Choose a migration strategy per workload: rehost, replatform, refactor, replace, retain or retire.
    • Size target resources from real usage data rather than current server specs.
    • Record compliance, data residency and licensing constraints for each workload.

    Milestone: An approved workload inventory with an owner, a strategy and a target size for every application in scope.

  2. Landing zone and foundations (Weeks 3-6)

    Prepare a secure, governed Azure environment before any workload moves.

    • Set up management groups, subscriptions and naming and tagging rules.
    • Build networking: hub and spoke design, IP plan, VPN or ExpressRoute connection to the data center, DNS.
    • Configure identity with Microsoft Entra ID, role-based access and privileged access rules.
    • Apply Azure Policy, logging, monitoring and backup defaults.
    • Have security and network teams review and sign off the landing zone.

    Milestone: Landing zone signed off by security and networking, with a test virtual machine reachable from the corporate network.

  3. Wave planning (Weeks 5-7)

    Group workloads into waves and agree downtime windows with the business.

    • Group tightly connected applications into the same wave so they move together.
    • Order waves from low risk to high risk, starting with internal tools and test environments.
    • Pick the method per workload: downtime migration or near-zero downtime with replication.
    • Agree cutover windows and freeze periods with each business owner.
    • Write a test plan per application with the users who will sign off.

    Milestone: A wave plan with dates, owners and agreed cutover windows, approved at the steering meeting.

  4. Pilot migration (Weeks 7-9)

    Prove the process on two or three low-risk workloads before scaling.

    • Migrate two or three low-risk workloads end to end, including testing and cutover.
    • Time each step of the cutover runbook and note what took longer than planned.
    • Test the rollback plan on at least one workload.
    • Update the runbook, the estimates and the wave plan from what you learned.

    Milestone: Pilot workloads running in Azure, signed off by their owners, with an updated runbook and timings.

  5. Migration waves (Weeks 9-14)

    Move the remaining in-scope workloads wave by wave with controlled cutovers.

    • Start replication or data copy for each wave ahead of its cutover weekend.
    • Run each cutover from the runbook, with a go or no-go call before the point of no return.
    • Have business users test and sign off within an agreed window after each cutover.
    • Hold a short review after every wave and adjust the next one.
    • Keep a hypercare rota for the first days after each cutover.

    Milestone: All in-scope workloads live in Azure, each with user sign-off and no open critical incidents.

  6. Optimize and decommission (Weeks 14-16)

    Right-size the new environment and switch off what is no longer needed.

    • Review actual usage and right-size virtual machines and databases.
    • Set up cost alerts and budgets in Azure Cost Management and review Azure Advisor recommendations.
    • Confirm backups and disaster recovery work in Azure with a restore test.
    • Back up and archive source servers, then shut them down after an agreed waiting period.
    • Update the CMDB, support documentation and on-call runbooks.

    Milestone: Source servers for the first wave switched off, CMDB updated and a cost baseline agreed with finance.

Example: a filled-in wave plan

Picture a manufacturing company moving 60 servers out of a data center whose hardware support contract ends next year. The infrastructure manager leads the program with a cloud architect, two engineers, a database administrator and the application owners.

The ERP goes last on purpose. By then, the team has run several cutovers, timed every step and tested a rollback.

  • Wave 0, pilot (weeks 7-9), owner cloud architect: intranet site and a file transfer server, rehosted. Milestone: both signed off by IT service desk lead.
  • Wave 1 (weeks 9-10), owner infrastructure engineer: test and development servers, rehosted. Milestone: developers working on Azure environments.
  • Wave 2 (weeks 10-12), owner database administrator: reporting databases moved to a managed database service, replatformed. Milestone: finance runs month-end reports from Azure.
  • Wave 3 (weeks 12-14), owner infrastructure manager: ERP application and database, near-zero downtime with replication, cutover on a long weekend. Milestone: production orders processed in Azure on Monday morning.
  • Retire list, owner application owners: eight servers nobody claimed during discovery, shut down after a notice period instead of being migrated.

Who owns what

A migration touches infrastructure, security, applications and the business, so ownership gaps show up quickly. Write a RACI for the program and a named owner for each wave.

The application owner role matters most. Technical teams can move a server, but only the person who owns the application can say it works.

  • Executive sponsor (CIO or IT director): budget, priorities and decisions when business owners disagree on dates.
  • Migration lead or program manager: plan, wave schedule, RAID log and steering meetings.
  • Cloud architect: landing zone design, target architecture and strategy per workload.
  • Infrastructure and database engineers: replication, cutover steps and rollback.
  • Security lead: landing zone review, access rules and security sign-off before each wave.
  • Application owners: dependency checks, test plans, cutover windows and user sign-off.

What goes in a cutover runbook

Each cutover needs a runbook: a step-by-step list of who does what, in what order and at what time. Without it, a cutover depends on the memory of one engineer at two in the morning.

Rehearse the runbook during the pilot and time each step. Real timings let you tell business owners how long the downtime window needs to be, instead of guessing.

  • Before: final replication check, change ticket approved, users notified, backups confirmed.
  • Go or no-go call: a named person decides, based on agreed criteria, before the point of no return.
  • Cutover steps: stop the application, final data sync, switch DNS or connection strings, start in Azure.
  • Validation: smoke tests by engineers, then business tests by named users.
  • Rollback: the exact steps to return to the source, and the deadline after which rollback is no longer possible.
  • Communication: who sends the all-clear or the rollback notice, and to which list.

Risks and dependencies

The most common reason a wave slips is a dependency nobody listed: a batch job that reads a file share, a hard-coded IP address, a licence tied to hardware. Discovery tools find many of these, but application owners find the rest. Ask them directly.

Track each risk in a RAID log with an owner and a fallback, and review it at every wave review.

  • Hidden dependency found during cutover: owner application owner. Fallback: roll back and move the dependent system into the same wave.
  • Network bandwidth too low for data copy: owner network engineer. Fallback: start replication earlier or use an offline transfer option such as Azure Data Box.
  • Licensing does not allow the move as is: owner IT procurement. Fallback: confirm terms with the vendor during discovery and switch strategy if needed.
  • Business owner cannot staff testing on cutover weekend: owner migration lead. Fallback: agree test users and backups when the window is booked.
  • Costs higher than planned after migration: owner cloud architect. Fallback: right-size in the optimize phase and set budget alerts from day one.

How to present the plan to leadership

Leadership wants three things: what moves when, how much business risk each cutover carries and what the company gets at the end. One slide can carry all three. Show the waves on a timeline, with each wave labeled by its main applications and its downtime window, and the decommission date at the end.

Add a short line for each of the top risks and its fallback, and the decisions you need, such as approval for a weekend freeze. Leave out server lists, IP ranges and tool screenshots, and keep them in the appendix.

Report progress after each wave in the same format: workloads moved, workloads signed off, incidents and the next window. A steady, predictable report builds trust faster than a perfect plan.

Metrics to track

Measure the program, not just the technology. A server that runs in Azure but has not been signed off by its owner is not migrated yet.

Pull these numbers from the wave tracker, your service desk tool and Azure Cost Management, and report them every week during the waves.

  • Workloads migrated and signed off: count against plan, per wave.
  • Cutover downtime: actual against the agreed window, per workload.
  • Rollbacks and critical incidents: count per wave, with the cause of each.
  • Source servers decommissioned: count against plan, since savings only start when old servers are off.
  • Monthly Azure spend against forecast: from Azure Cost Management, reviewed with finance.

Common mistakes to avoid

  • Moving servers before the landing zone is signed off creates security gaps you must fix later, so finish networking, identity and policy first.
  • Skipping dependency checks with application owners causes failed cutovers, so confirm every dependency with the owner before the wave is booked.
  • Copying current server sizes into Azure wastes money, so size targets from real usage data and right-size after migration.
  • Planning cutovers without a tested rollback leaves you stuck when something breaks, so test rollback during the pilot and set a rollback deadline in each runbook.
  • Calling a workload done when it runs in Azure hides open issues, so count it as migrated only after its owner signs off.
  • Leaving old servers running after cutover delays any savings, so set a decommission date for each server in the wave plan.

Frequently asked questions

What are the phases of an Azure migration?

A common structure is assess, prepare the landing zone, plan waves, pilot, migrate in waves, then optimize and decommission. Microsoft's Cloud Adoption Framework describes a similar flow of planning, preparing workloads, executing, optimizing and decommissioning the source. Each phase should end with a signed-off milestone.

How long does an Azure migration take?

It depends on the number of workloads, how connected they are and how much you change during the move. A first wave of simple workloads can be planned in a few months, while large estates run as a program over a year or more. Use the pilot timings to estimate the rest.

What is an Azure landing zone?

It is the prepared Azure environment that workloads move into: subscriptions, networking, identity, policies, logging and security controls. Building it first means every workload lands in a governed setup instead of being fixed later.

Which migration strategy should I use for each workload?

Rehost moves a server as it is and is the fastest. Replatform makes small changes, such as moving a database to a managed service. Refactor or rebuild changes the application itself and takes longer. Choose per workload based on business value, risk and the time you have.

Generate this roadmap with AI