To plan an Azure migration, work top-down: set business goals and a business case, run discovery and assessment, choose a strategy per workload using the 6 Rs, design a landing zone with governance, sequence the move into waves, and define success criteria. A sound cloud migration strategy decides *why* and *in what order* before touching tooling.
Key Takeaways
-
A good plan starts with goals and a business case, not with tools - the "why" determines every later decision.
-
Discovery and assessment produce the facts a plan needs: inventory, dependencies, right-sizing, and cost projections.
-
Each workload gets its own strategy (the 6 Rs); the estate is migrated as a portfolio, not all at once.
-
A landing zone and governance model should exist before the first production workload moves.
-
Migration runs in waves, starting with a low-risk pilot, with success criteria and a rollback plan defined up front.
-
Microsoft's Cloud Adoption Framework and Well-Architected Framework are the standard references for structuring the work.
How do you plan an Azure migration?
Planning an Azure migration is a sequence of decisions, each producing an artifact the next step depends on. The work flows from intent to execution: define goals and the business case, discover and assess the estate, choose an approach for each workload, build the target environment and governance, sequence the move into waves, and agree how success will be measured. This mirrors the early phases of Microsoft's Cloud Adoption Framework (CAF), which Microsoft positions as its end-to-end methodology for planning and governing cloud adoption, though Microsoft revises the specifics over time.
It also mirrors how Centric structures the front half of an engagement. The Azure migration and modernization practice runs an explicit *Assess and Plan* phase - evaluating infrastructure, applications, and data platforms and defining the strategy - before any *Migrate and Modernize* work begins. The six steps below are that phase in practical detail, and they line up with the broader stages of an Azure migration from first assessment through post-migration optimization.
Step 1 - Set goals and build the business case
Start with the outcomes the migration must deliver. Common drivers include exiting a data center or escaping end-of-support hardware, reducing infrastructure and operational cost, improving performance and scalability, strengthening security and compliance, and building a modern base for data and AI. Write these down as ranked objectives, because they decide trade-offs later - a cost-driven program makes different choices than a speed-to-market one.
The business case turns those objectives into a defensible argument: the cost of the current state, the projected target state (including Azure consumption, which is billed by Microsoft and varies by service and usage), the one-time migration investment, and the expected benefits and timeline. Be honest that a naive lift-and-shift can cost more than on-premises if instances are not right-sized; the assessment in Step 2 is what keeps the business case grounded in real numbers rather than optimism.
Step 2 - Run discovery and assessment
You cannot plan what you cannot see. Discovery inventories servers, virtual machines, applications, databases, and their interdependencies; assessment evaluates each for cloud readiness, right-sizing, and cost. Microsoft's Azure Migrate is the first-party hub for discovery and assessment, including dependency analysis that maps which components talk to each other - critical for grouping workloads correctly.
The output is the factual backbone of the plan: a validated inventory, a dependency map, right-sizing recommendations, a total-cost-of-ownership projection, and a recommended strategy per workload. Because this step is the foundation everything else rests on, it deserves its own discipline - our guide to running an Azure migration assessment covers exactly what to inventory and evaluate, and what the deliverables should look like.
Planning a move and want the facts before you commit? A structured assessment turns guesswork into a costed, sequenced plan. Talk to Centric about an Azure migration and modernization assessment to ground your business case in real inventory and dependency data.
Step 3 - Choose a strategy per workload (the 6 Rs)
With assessment data in hand, assign each workload a migration strategy. Microsoft and the wider industry describe these as the "6 Rs": rehost (lift and shift), replatform, refactor, rearchitect, rebuild, and replace. The right answer is rarely one strategy for everything - it is a portfolio decision driven by each workload's business value, technical health, and constraints.
A stable, low-change application facing a deadline may be a clean rehost; a strategic system constrained by its architecture may justify refactor or rearchitect; a commodity capability may be cheaper to replace with SaaS. Getting this mapping right is the difference between relocating problems and capturing cloud value, so it is worth deciding deliberately - our deep dive on lift-and-shift vs. refactor vs. rebuild lays out a decision framework for matching workload characteristics to the right R.
Step 4 - Design the landing zone and governance
A landing zone is the pre-built target environment in Azure - subscription and management-group structure, networking, identity and access (RBAC), policy, security baseline, and monitoring - that workloads land into. Microsoft's Cloud Adoption Framework treats the landing zone as a prerequisite, not an afterthought: it is what makes migrations repeatable, secure, and governable at scale rather than a series of one-off deployments.
Governance decisions made here - naming and tagging standards, cost-management guardrails, policy-as-code, and security and compliance alignment - prevent the sprawl and cost drift that undermine many migrations. This is where a broader platform view helps; Centric positions Azure migration within its wider Microsoft cloud solutions practice precisely so the landing zone is designed for the long term, not just the move. Microsoft's Well-Architected Framework, organized around reliability, security, cost, operations, and performance, is the standard reference for these design choices.
Step 5 - Sequence migration waves
Migrating everything at once is how programs fail. Instead, group workloads into waves based on the dependency map and risk profile, and start with a low-risk pilot that proves the landing zone, tooling, and runbook end to end. Each subsequent wave is scheduled with its dependencies intact - applications that talk to each other move together or in a coordinated sequence.
Sequencing is also where risk management lives. Mission-critical, tightly coupled, or compliance-sensitive workloads usually move later, once the team has proven the process on safer ones. Because these workloads carry the most exposure, they warrant extra planning - our analysis of migration risk for mission-critical workloads covers the controls (replication, phased cutover, validation) that protect continuity during the move.
Step 6 - Define success criteria and a rollback plan
A plan is not finished until you have agreed how to judge it. Define success criteria per wave and for the program: performance and availability targets, validated data integrity for migrated databases, security and compliance checks, cost against the business case, and user-acceptance sign-off. These map directly to the objectives ranked in Step 1.
Equally important is the rollback or fallback plan for each cutover - the conditions that would trigger it and the steps to execute it - so a problem during a cutover window is a controlled event, not a crisis. Pairing clear success criteria with a tested rollback is what lets teams cut over with confidence.
How long does planning take?
It depends on the size of the environment, the complexity of the workloads, and the chosen approach. Centric's published guidance is that a full migration runs from a few weeks to several months - simpler lift-and-shift moves complete faster, while modernization-heavy programs take longer - and that a detailed roadmap with milestones is produced as part of planning. The planning phase itself is a fraction of that, but compressing it is usually a false economy: time saved skipping assessment is repaid with interest during cutover.
How does Centric run Assess and Plan?
Centric runs planning as a structured phase rather than a document drop. As a Microsoft partner, Centric evaluates infrastructure, applications, and data platforms; defines a strategy per workload; and produces a sequenced roadmap with milestones before any production workload moves - using Microsoft tooling such as Azure Migrate for discovery and assessment and aligning to the Cloud Adoption and Well-Architected Frameworks. The same rigor carries into delivery, governed by Centric's migration methodology, so the plan you approve is the plan that gets executed and validated.
The result is a migration that is decided before it is started: clear goals, evidence-based strategy per workload, a governed landing zone, a sequenced wave plan, and explicit success criteria.
Ready to turn a migration ambition into a costed, sequenced plan? Centric's Azure migration and modernization team can run the Assess and Plan phase end to end - from discovery to landing-zone design to a milestone roadmap.
Frequently Asked Questions
How do you plan an Azure migration?
Set business goals and a business case, run discovery and assessment, choose a strategy per workload using the 6 Rs, design a landing zone with governance, sequence the move into waves starting with a pilot, and define success criteria and a rollback plan. This sequence aligns with Microsoft's Cloud Adoption Framework.
What should a cloud migration strategy include?
Ranked business objectives, a costed business case, an evidence-based inventory and dependency map, a per-workload approach, a governed target environment (landing zone), a wave-based sequence, and measurable success criteria with a rollback plan.
What is an Azure landing zone?
The pre-built target environment in Azure - subscriptions, networking, identity and access, policy, security baseline, and monitoring - that workloads land into. Microsoft's Cloud Adoption Framework treats it as a prerequisite for migrating securely and repeatably at scale.
How do you prioritize workloads for migration?
Use the dependency map and risk profile from assessment. Start with a low-risk pilot to prove the process, keep interdependent applications together, and schedule mission-critical or compliance-sensitive workloads later, once the approach is proven.
How long does an Azure migration take?
Centric's guidance is a few weeks to several months, depending on environment size, workload complexity, and approach - simpler lift-and-shift is faster, modernization takes longer. A detailed roadmap with milestones is produced during planning.
