The 6-Rs Migration Framework

The 6-Rs Migration Framework is a structured approach for categorising how each on-premises workload should move to the cloud. Microsoft and the broader industry use these six strategies — also called migration patterns — to make portfolio decisions efficient and consistent. Rather than applying a one-size-fits-all approach, architects assess each application individually and assign it the most appropriate R.

Rehost (Lift and Shift) means moving a workload to Azure with no code changes. You take the existing VM image or application binary and run it on Azure IaaS. This is the fastest strategy and is typically used for legacy applications that are difficult to modify or for organisations with tight migration deadlines. Azure Migrate's replication engine automates rehosting for most Windows and Linux VMs.

Replatform (also called Lift, Tinker, and Shift) involves minor optimisations during migration without changing the core architecture. Examples include moving a self-managed MySQL database from a VM to Azure Database for MySQL, or swapping a self-hosted SMTP relay for Azure Communication Services. You gain managed-service benefits — patching, backups, scaling — without rewriting application logic.

Rearchitect (or Refactor) means significantly changing the application's architecture to take advantage of cloud-native capabilities. A monolithic .NET application might be broken into microservices deployed on Azure Container Apps, or a cron-job-based batch system might be reimplemented as Azure Functions. Rearchitecting produces the greatest long-term benefits in scalability and cost but requires the most investment.

Rebuild means discarding the existing application entirely and building a new cloud-native solution. This strategy is chosen when the legacy application is too costly to maintain, uses an end-of-life technology stack, or simply cannot meet business requirements even if migrated. Rebuild delivers maximum cloud-native advantage but has the highest time-to-value. Azure PaaS and serverless services like Azure App Service, Azure Functions, and Cosmos DB are common targets.

Replace means replacing an existing on-premises application with a commercially available SaaS product that delivers equivalent or superior functionality. For example, replacing an on-premises CRM with Dynamics 365, or a legacy file server with SharePoint Online. Replace eliminates infrastructure management entirely. The tradeoff is reduced customisation and potentially significant data migration and change management effort.

Retire is the simplest strategy — you identify applications that are no longer used, redundant, or superseded, and decommission them instead of migrating them. Discovery data gathered by Azure Migrate often reveals a significant percentage (sometimes 20–30%) of on-premises servers have very low utilisation or no active users. Retiring these applications reduces migration scope, licensing costs, and operational complexity.

Selecting the appropriate R requires analysing four factors for each application: business criticality, technical complexity, migration timeline, and total cost of ownership. A simple web front-end with no integration dependencies is a good Rehost candidate. An application with hundreds of stored procedures and custom database features may need Rearchitect or Rebuild. Low-value internal tools are prime Retire or Replace candidates.

Azure Migrate provides a Business Case feature that automatically suggests a migration strategy for discovered servers based on utilisation data, licensing, and Azure pricing. It groups workloads into Rehost, Replatform, and End-of-Support buckets, giving you a head start on 6-Rs classification. You can override any recommendation and add your own business context before finalising the migration plan.

Once each application has an assigned R, you group them into migration waves. Low-risk Rehost candidates typically form the first wave to build team confidence and tooling familiarity. Rearchitect and Rebuild projects run in parallel workstreams with longer timelines. Dependencies between applications — for example, a web tier that calls a shared database — must be respected so that related apps migrate together or in the correct order.

The 6-Rs align with the Adopt phase of Microsoft's Cloud Adoption Framework. The CAF provides wave-planning templates, RACI matrices, and workload assessment questionnaires that operationalise the 6-Rs at enterprise scale. Governance guardrails established during the Ready phase — landing zones, policies, identity — must be in place before migration waves begin so that migrated workloads land in a compliant environment from day one.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: the 6-Rs framework (Rehost, Replatform, Rearchitect, Rebuild, Replace, Retire) provides a vocabulary for migration decisions, each R has a different cost-vs-speed trade-off, and Azure Migrate's Business Case can auto-suggest strategies based on utilisation data. Next up we explore how Azure Migrate discovers and assesses on-premises servers.