Select your cloud migration strategies

With a clear inventory and understanding of your workloads, your cloud adoption plan must determine what to do with each workload in the cloud. There are multiple migration strategies, sometimes known as the “Rs” of cloud migration. Each workload can be Retired, Retained, Rehosted, Replatformed, Refactored, Rearchitected, Rebuilt, or Replaced. This section guides how to pick the right approach for each workload, presenting the options, when to choose each, and the pros/cons trade-offs.

Migration strategy overview

The following table provides an overview of all available cloud migration strategies. Use this reference to understand each strategy's primary business driver and key indicators that signal when to apply each approach to your workloads.

Determine business drivers before migration

A business driver defines why a workload needs to change in order to support a specific business goal. Business drivers connect cloud adoption decisions to measurable business value and strategic goals. Identifying these drivers ensures that migration efforts are purposeful and aligned with organizational priorities.

1. Define business goals. Business goals are high-level outcomes the organization wants to achieve from cloud adoption, such as adopting AI, increasing agility, accelerating innovation, reducing costs, and improving resilience. These goals provide the strategic context for all migration decisions. Use strategic planning documents, executive interviews, or business case workshops to identify and validate these goals with stakeholders.

2. Identify gaps. Perform a high-level gap analysis to understand what each workload must change to better support the defined business goals. This analysis should consider current performance, scalability, compliance, user experience, and architectural limitations. Document any shortfalls that prevent the workload from fully enabling the desired outcomes.

3. Determine the business driver. A business driver emerges from the gap between a workload’s current state and its desired future state. It represents a specific, actionable reason for change. These drivers guide the selection of an appropriate migration strategy.

   Business driver	Migration strategy
   Need to decommission redundant or low-value workloads	Retire
   Need minimal business disruption and no modernization in near future	Rehost
   Needs PaaS solutions and minimal code changes to offload maintenance and facilitate reliability	Replatform
   Need code changes to reduce technical debt or optimize code for cloud	Refactor
   Need architecture changes to unlock cloud-native capabilities	Rearchitect
   Need SaaS/AI solution to simplify operations	Replace
   Need new cloud-native solution to meet requirements	Rebuild
   Need stability and no change	Retain

Select the right migration strategy

A migration strategy defines how each workload transitions to Azure based on its business driver. Review the narrowed list of strategies and validate the selected option with business and technical stakeholders. Remove options that conflict with compliance, security, or operational constraints. Consider Azure readiness, team skills, and integration complexity when finalizing the strategy.

1. Retire (decommission)

Retire decommissions workloads that no longer provide business value. This strategy is important when workloads are obsolete, underused, or redundant. Validate this decision by confirming that the workload is obsolete and has no critical dependencies that would affect other systems. Update your inventory as you decommission workloads.

2. Rehost (like-for-like migration)

A rehost strategy enables fast and low-risk migration by moving workloads to Azure with minimal changes. A rehost is a like-for-like migration, which moves virtual machines to IaaS, IaaS to IaaS, and PaaS to PaaS.

1. Don't rehost problematic workloads. Rehosting doesn't resolve existing performance, reliability, or architectural issues. Migrating such workloads without modernization can carry forward technical debt and require rework later. Instead, modernize these workloads during migration to address root causes.

2. Confirm that the workload will not require modernization within two years. Rehosting is suitable only when you're confident that the workload remains in its current state for at least two years. If modernization is likely, consider refactoring or rearchitecting instead to avoid duplicate effort.

3. Use rehost to build foundational cloud operations. Rehosting helps teams gain experience with Azure operations, governance, and cost management. This early exposure supports broader cloud adoption goals and prepares teams for more complex modernization efforts.

3. Replatform (modernize hosting environment)

Replatforming moves workloads to a modern hosting environment with minimal code changes. This strategy is important when you want to reduce infrastructure management, improve scalability, and simplify operations without a full application rewrite.

Choose workloads where PaaS options reduce operational overhead, improve reliability, or simplify disaster recovery. Minimal code refactoring might be necessary to take advantage of PaaS services.

4. Refactor (modernize code)

Refactoring improves the internal structure of code without adding new features. This practice is important during cloud adoption because it helps teams modernize legacy code, reduce technical debt, and prepare workloads for long-term maintainability in Azure. You should refactor code when the migration process creates a unique opportunity to address technical debt or when post-migration behavior reveals areas for improvement.

5. Rearchitect (modernize architecture and code)

A rearchitect strategy redesigns the workload’s architecture to improve scalability, agility, and service orientation. This strategy is important when you need to break down monolithic applications, adopt microservices, or enable targeted scaling. You should rearchitect when your current architecture limits your ability to meet business goals or scale effectively. For an example, see Modern Web App Pattern.

6. Replace (use SaaS alternative)

A replace strategy uses commercial SaaS solutions to eliminate the need for custom development and ongoing maintenance. This strategy is ideal when SaaS offerings meet business needs with minimal customization. Replace workloads when SaaS solutions offer comparable features, integration capabilities meet requirements, and total cost of ownership justifies the transition. Consider data migration complexity, user training needs, and process changes when you evaluate replacement options. Common replacement scenarios include CRM systems, HR platforms, and collaboration tools where SaaS maturity provides reliable alternatives to custom solutions.

7. Rebuild (build cloud-native)

A rebuild strategy is a full redevelopment of a workload using cloud-native solutions. This approach is appropriate when legacy systems are obsolete or when modernization isn't feasible. Rather than modernizing legacy functionality, you can reimagine the solution to use Azure capabilities like PaaS, automation, and AI. Some workloads required a rebuild, like DHCP server. For other workloads, it's better to deploy new instances of services in Azure rather than migrating them, such as Active Directory Domain Controllers.

8. Retain (keep as is)

A retain strategy keeps workloads in their current environment when they're stable, compliant, and meet all current and future business needs with no near-term driver to move. You must retain workloads that can't be migrated due to regulatory constraints, technical dependencies, or business continuity requirements. Use Azure Arc to manage retained on-premises workloads from Azure, providing unified management capabilities. Consider a more modern on-premises solution like Azure Local for your workloads and connect to Azure. Shift workloads that can't be migrated to another migration wave or revisit them later when constraints change.

Understand when to modernize during migration

Modernization during migration refers to replatforming, rearchitecting, or refactoring workloads to maximize cloud value. Modernization can deliver long-term benefits but introduces complexity and risk to migration timelines. You must evaluate whether to modernize during migration or defer modernization to post-migration phases based on clear business justification. Follow these recommendations:

1. Modernize when your team has the required skills and time. Attempting modernization without adequate expertise or time increases risk and delays. If your team lacks readiness, defer modernization to a later phase.

2. Modernize workloads that require compatibility updates. Legacy technologies, unsupported SDKs, or the need to adopt SaaS solutions might require modernization. Justify each effort with a clear business case.

3. Modernize when migration enables funding and alignment. Migration projects often unlock funding and stakeholder support. Use this opportunity to align modernization with business priorities. Delaying might result in inefficient workloads and missed opportunities.

Communicate decisions to stakeholders

Clear communication ensures all stakeholders understand and support migration decisions throughout the adoption process. Stakeholder alignment reduces execution risk and improves project outcomes by establishing shared understanding of priorities and constraints. You must establish a structured communication plan to maintain alignment throughout the migration process. Follow these recommendations:

1. Define success metrics that validate the business outcome. Success metrics quantify the value of the chosen action and confirm whether the business driver is achieved. This step ensures that decisions are based on business value rather than technical completion. Use metrics such as:

   Cloud migration strategy	Example success metrics
   Retire	• Retire 100% of workloads identified as obsolete before migration
   Rehost	• Migrate 100% of Tier 1 workloads from other cloud to Azure with no service-level agreement (SLA) degradation • Decommission 30% of on-premises infrastructure post-migration.
   Replatform	• Reduce deployment lead times by 30% for migrated applications • Reduce infrastructure and licensing costs by 25% within 12 months
   Refactor	• Improve application response time by 40% using Azure-native services • Achieve 95% observability coverage through code instrumentation
   Rearchitect	• Support 2x user load with no performance degradation • Integrate three new Azure-native services into existing architecture
   Replace	• Transition CRM to SaaS with 99.9% uptime and no custom code • Shift 30% of dev effort to competitive differentiators.
   Rebuild	• Launch new cloud-native application in three months vs. six months on-premises • Cut operational costs by 40% using PaaS services
   Retain	• Maintain current SLA and compliance posture • Manage on-premises workloads from Azure using Azure Arc

2. Document and share workload treatment decisions with all relevant stakeholders. Migration decisions can affect multiple organizational functions and require broad stakeholder input. Include business owners, legal teams, security teams, and technical leads in decision communication. Explain how each migration strategy decision supports documented business goals and addresses stakeholder concerns.

3. Coordinate migration plans with the cloud strategy team. The cloud strategy team provides organizational context and ensures migration decisions align with broader cloud adoption objectives. Regular coordination prevents conflicts between individual workload decisions and enterprise-wide cloud strategy. Review migration strategy selections against the cloud adoption plan established during the Strategy phase to maintain consistency.

4. Establish regular communication between mandate owners and execution teams. Ongoing communication between decision makers and implementers ensures plans remain viable as technical realities emerge. Schedule regular progress reviews to track migration progress, identify risks, and address technical issues. Use this feedback loop to adjust migration strategies when implementation challenges or new opportunities arise.

5. Review and update migration strategies based on evolving requirements. Business priorities and technical insights change throughout the migration process, requiring strategy adjustments. Establish a regular review cycle to reassess workload treatment decisions against current business goals and technical capabilities. Update strategy mappings to reflect new priorities, lessons learned, and changing organizational needs.

Next steps