5.1.3. Design a Migration Solution
💡 First Principle: A successful cloud migration is a strategic process of discovery, planning, execution, and optimization that enables organizations to transition workloads to the cloud with minimal disruption, risk, and cost.
The migration lifecycle, and what belongs in each phase:
Two assessment outputs are examined far more than the rest. Dependency analysis is what turns a server list into correctly grouped migration waves — move one half of a chatty pair and its traffic crosses back to the datacenter. Performance-based sizing is what makes the cost projection honest, because sizing as-on-premises carries the estate's existing over-provisioning straight into Azure.
⚠️ Exam Trap: any option that starts replicating or cutting over during the assessment phase is wrong. It commits target sizing before the data that should inform it exists.
Scenario: You are designing a migration plan for a legacy enterprise application that includes several Virtual Machines, a large SQL Server database, and shared file servers on-premises. The business requires minimal downtime for the database and a phased migration approach for the VMs.
Think of cloud migration like moving offices. You wouldn't move everything in one truck on one day — you'd assess what you have, decide what to keep/upgrade/discard, move in waves starting with the least critical items, and validate each wave before the next. The 5 R's framework maps directly to this analogy:
| Strategy | Office Analogy | Azure Approach | Effort | Benefit |
|---|---|---|---|---|
| Rehost | Move desk as-is | Lift-and-shift to VMs | Low | Fast migration |
| Replatform | Same desk, new building utilities | Move to PaaS (App Service, managed DB) | Medium | Reduced ops |
| Refactor | Redesign workspace | Cloud-native rebuild (microservices, serverless) | High | Maximum cloud benefit |
| Retire | Throw away old furniture | Decommission unused apps | None | Cost savings |
| Retain | Keep in old office | Keep on-premises (for now) | None | Avoid unnecessary risk |
A migration solution facilitates the secure and efficient transfer of on-premises workloads, applications, and data to the Azure cloud, enabling organizations to leverage cloud benefits while minimizing disruption.
Key Design Considerations:
- Assessment and Planning: Evaluate existing infrastructure and dependencies. Define migration goals and create a detailed plan. Use Azure Migrate for discovery.
- Migration Strategy: Choose between rehost (lift-and-shift), refactor, re-architect, rebuild, or replace.
- Data Migration: Select appropriate tools for transferring data, considering volume and downtime tolerance. Use Azure Data Box for large offline transfers, or Azure Database Migration Service (DMS).
- Application Migration: Migrate applications, ensuring compatibility and performance.
- Network Connectivity: Establish secure connectivity between on-premises and Azure (Azure VPN Gateway, Azure ExpressRoute).
- Security and Compliance: Integrate security controls and ensure compliance throughout the migration.
- Azure Migration Services: Leverage Azure Migrate for discovery, assessment, and migration. Utilize Azure Database Migration Service (DMS) for specialized database migrations. Servers move by replication: the source keeps running while its disks are copied, test runs use the replicas, and cutover is a short final sync — which is what makes phased waves possible. Azure Migrate's server migration is the recommended tool (its agent-based mode uses Azure Site Recovery's replication), and Site Recovery itself can also replicate servers into Azure. A database that must stay online during the move goes through DMS instead, which migrates at the database level.
⚠️ Common Pitfall: A "lift-and-shift" migration with no plan for future modernization. While rehosting is a valid first step, stopping there means leaving most of the cloud's benefits—like elasticity and managed services—on the table.
Key Trade-Offs:
- Speed of Migration vs. Cloud Optimization: The fastest migration strategies (like rehosting) provide the fewest cloud-native benefits. The most beneficial strategies (like refactoring) take the most time and effort.
Evaluating a migration against the Cloud Adoption Framework
The Microsoft Cloud Adoption Framework for Azure (CAF) is the frame the exam uses when it asks you to evaluate a migration plan rather than pick a tool. It organizes Azure adoption into seven phases, each answering one decision:
| Phase | Key decision | What it means for a migration |
|---|---|---|
| Strategy | What should our Azure adoption look like? | The business goals that justify moving at all |
| Plan | How will we prepare for Azure adoption? | Assess workloads with Azure Migrate, map dependencies, choose a strategy for each workload |
| Ready | How will we build our Azure landing zone? | A platform landing zone plus an application landing zone for each workload |
| Adopt | How will we migrate, modernize, and build workloads? | Plan the migration, prepare workloads, execute, optimize, decommission the source |
| Govern | How will we control our Azure environment? | Policy and cost guardrails around everything that lands |
| Secure | How will we protect our Azure environment? | The security baseline the landing zone enforces |
| Manage | How will we operate and optimize Azure over time? | Operations after cutover |
CAF names eight strategies, not five. The five-strategy table earlier in this section is a simplification. CAF's cloud migration strategies are Retire, Rehost, Replatform, Refactor, Rearchitect, Replace, Rebuild and Retain, and each is chosen from a business driver rather than from convenience. Three of them carry guidance the exam likes:
- Rebuild is recommended for some infrastructure even when nothing is wrong with it. CAF's own example is Active Directory domain controllers: deploy new instances in Azure rather than migrating the old ones.
- Retain is for workloads that can't move, for example because of regulation. CAF recommends managing them from Azure with Azure Arc instead of leaving them outside the plan.
- Rehost only makes sense when the workload won't need modernizing within about two years. Rehosting a problematic workload carries its technical debt into Azure.
The Migrate sequence in the Adopt phase is five steps: plan the migration, prepare workloads, execute the migration, optimize in the cloud, then decommission the source. The migration plan lists two prerequisites, a migration adoption plan and an Azure landing zone, and asks for a tested rollback plan before any cutover.
How to evaluate a proposed migration solution:
| Check | A sound plan... |
|---|---|
| Landing zone | Has the Azure landing zone in place before the first wave |
| Strategy per workload | Ties each workload's strategy to a business driver, weighing application complexity and whether a PaaS equivalent exists, business criticality and tolerable downtime, and licensing terms (Azure Hybrid Benefit, vendor support on the target platform) |
| Waves | Groups workloads by dependency, moves non-production before production and simple before critical |
| Method | Chooses downtime or near-zero-downtime migration per workload, based on criticality |
| Rollback | Defines what counts as a failed deployment and tests the rollback before cutover |
⚠️ Exam Trap: an answer that rehosts every workload because lift-and-shift is fastest skips CAF's per-workload decision. Look for the option that retires what has no value, rebuilds what CAF says to rebuild, and retains (with Azure Arc) what cannot move.
Reflection Question: How does designing a migration solution (including assessment, strategy choice, data migration, and application migration tools like Azure Migrate and DMS) fundamentally facilitate the secure and efficient transfer of on-premises workloads to Azure, enabling cloud benefits while minimizing disruption and risk?
