Azure Migration Strategy: The 6 Rs Explained (Rehost, Replatform, Refactor, and More)

• 31 July 2026
• Azure
• Written by Editorial Team

Ask five people how to migrate an application to Azure and you will get five different answers. One wants to move the VMs as they are and be done by Friday. Another insists nothing should move until it is rebuilt on containers. A third quietly points out that the application is being replaced by a SaaS product next year anyway, so why migrate it at all?

All three can be right. That is the entire point of an Azure migration strategy: there is no single correct way to move to the cloud, only a correct way to move each workload. The framework the industry uses to make that call is known as the 6 Rs of cloud migration, and applying it well is the difference between a migration that finishes on schedule and one that stalls in month four with half the portfolio in limbo.

This guide explains each of the six strategies, when to use it, what it costs in effort and risk, and how to run the decision process across a real application portfolio.

What Is an Azure Migration Strategy?

An Azure migration strategy is a documented plan that defines how each workload in your portfolio will move to Azure: which applications are rehosted as-is, which are modernized during the move, which are replaced by SaaS alternatives, and which are retired or left where they are. Rather than treating migration as one big decision, the strategy treats it as a portfolio of small decisions, one per workload, each made deliberately.

The payoff of doing this before touching anything is speed and predictability. Teams that skip portfolio-level planning tend to default to one approach for everything, and both defaults fail: rehosting everything moves technical debt into the cloud at cloud prices, while modernizing everything turns a six-month migration into a multi-year engineering program.

The 6 Rs of Cloud Migration at a Glance

The 6 Rs framework traces back to migration strategy work first published by Gartner and later popularized across the industry. The six strategies, ordered from least to most transformation:

Strategy	What It Means	Effort	Typical Use Case
Rehost	Move the workload as-is to Azure VMs (lift and shift)	Low	Datacenter exit, hardware end of life, tight deadlines
Replatform	Move with targeted upgrades to managed services, no code rewrite	Low to medium	SQL Server to Azure SQL, web apps to App Service
Refactor / Rearchitect	Restructure the application to be cloud-native	High	Monoliths that need to scale, apps central to the business
Repurchase	Replace the application with a SaaS product	Low (technical), medium (change management)	Self-hosted email, CRM, or HR systems moving to SaaS
Retire	Decommission the workload entirely	Minimal	Redundant, unused, or duplicate applications
Retain	Keep the workload where it is, for now	None	Compliance constraints, recent hardware investment, latency-bound systems

In practice, most enterprise portfolios end up using at least four of the six. The sections below cover each strategy in the depth you need to make the call per workload.

Rehost: Lift and Shift to Azure

Rehosting moves a workload to Azure infrastructure with no changes to the application itself. The server that ran on VMware or Hyper-V yesterday runs as an Azure virtual machine tomorrow, with the same operating system, the same application binaries, and the same configuration.

What Azure Lift and Shift Actually Involves

“Lift and shift” sounds like copying files, but a well-run rehost still follows a disciplined process:

• Discovery and dependency mapping: Azure Migrate discovers servers and maps which applications talk to which, so you never migrate half of a dependency chain and break the other half.
• Right-sizing: On-premises servers are chronically overprovisioned. Azure Migrate’s assessment recommends VM sizes based on actual utilization, which is where most of the immediate cost savings come from.
• Replication and test failover: Workloads replicate to Azure while production keeps running, and you validate each application in an isolated test environment before any cutover.
• Cutover in waves: Applications move in dependency-aware groups during planned windows, keeping downtime to the final synchronization and switchover.

When Rehosting Is the Right Call

• A datacenter lease, hardware refresh, or hypervisor licensing deadline puts a hard date on the exit.
• The application is stable, commercially supported, and has no pressing need to change.
• The vendor does not support a PaaS deployment model, so infrastructure is the only option anyway.
• Your team needs to build cloud operational experience before taking on modernization projects.

The honest limitation: rehosting captures infrastructure savings and agility, but the application itself gains nothing. You still patch the OS, still manage the middleware, and still carry whatever technical debt came along for the ride. That is acceptable, and often correct, as long as it is a conscious choice rather than a default. Rehost also works well as a two-step play: move now to meet the deadline, then replatform selectively once you are running in Azure. Licensing helps here too, since Azure Hybrid Benefit lets you apply existing Windows Server and SQL Server licenses with Software Assurance to reduce VM costs.

Replatform: Move and Improve

Replatforming moves the workload to Azure while swapping selected components for managed services, without rewriting application code. It is the middle path, and for many workloads it delivers the best return per hour of engineering effort in the entire framework.

Common Azure Replatforming Moves

• SQL Server on a VM to Azure SQL Managed Instance: Near-full SQL Server compatibility with backups, patching, and high availability handled by the platform. Azure Database Migration Service manages the data movement.
• IIS web applications to Azure App Service: The app runs on a managed platform with built-in scaling, TLS management, and deployment slots, and the web servers disappear from your patch list.
• Self-managed file servers to Azure Files: SMB shares served natively from the platform, optionally cached on-premises with Azure File Sync.
• Application components to containers: Packaging an app into containers on Azure Container Apps or AKS without redesigning it, which standardizes deployment even before any re-architecture.

The common thread: the application logic is untouched, but entire categories of operational work (OS patching, database maintenance, backup jobs, failover clustering) move to Microsoft. That reduction in day-2 burden is the real product of replatforming, and it compounds every month after go-live.

Rehost vs Replatform: How to Choose

This is the decision teams wrestle with most, because both options are reasonable for a large share of workloads. The comparison that matters:

Factor	Rehost	Replatform
Migration speed	Fastest; weeks for most workloads	Slower; adds testing and cutover complexity per component
Code changes	None	None to minimal (connection strings, configuration)
Ongoing operations	You manage OS, middleware, and database	Platform manages patching, backups, and availability for replatformed components
Risk profile	Lowest; the application is unchanged	Moderate; compatibility must be validated per component
Long-term cost	Higher; VM sprawl and management overhead persist	Lower for most workloads once managed services absorb operations
Best when	Deadline-driven moves, vendor-constrained apps	Databases and web tiers with clean managed-service equivalents

A practical rule that holds up across most migrations we run: rehost by default when the calendar is the constraint, replatform by default when operations are the constraint. If the driver is a datacenter exit date, rehost broadly and replatform after landing. If the driver is a lean IT team drowning in patching and backup maintenance, replatform the database and web tiers on the way in, because touching them once is cheaper than touching them twice.

And it is not either-or per application. The most common winning pattern is a hybrid: rehost the application servers, replatform the database underneath them. You get most of the operational relief for a fraction of the modernization effort.

Refactor and Rearchitect: Going Cloud-Native

Refactoring (and its deeper cousin, rearchitecting) changes the application itself so it can take full advantage of the cloud: breaking a monolith into services, moving to Azure Kubernetes Service or Azure Container Apps, adopting serverless components like Azure Functions, or redesigning the data layer around managed platforms.

When the Investment Is Justified

• The application is core to the business and under active development, so architecture improvements pay dividends on every future release.
• The current design blocks a real requirement: it cannot scale for peak demand, cannot deploy without downtime, or cannot isolate failures.
• Infrastructure costs are dominated by capacity held in reserve for spikes that elastic, cloud-native design would absorb automatically.

When It Is Not

• The application is stable, changes rarely, and its only sin is being old. Rehost or replatform it and spend your engineering budget where it changes outcomes.
• The team lacks the cloud-native skills to carry the redesign. Microsoft’s own guidance is direct on this point: modernize during migration only when your team has the skills and time, and defer it to a post-migration phase when it does not. An under-resourced refactor is the single most common way migration timelines collapse.

A sequencing note worth internalizing: refactoring belongs to a small, deliberately chosen subset of your portfolio. In most enterprise migrations the majority of workloads rehost or replatform, and a handful of high-value applications justify deeper investment. If your draft plan shows half the portfolio marked “refactor,” the plan is usually wrong before the migration starts.

Repurchase: Replace with SaaS

Repurchasing drops the application entirely in favor of a SaaS product. The classic example every organization has already lived through is email: nobody migrates an aging Exchange server to an Azure VM when Exchange Online exists. The same logic applies to self-hosted CRM, HR, helpdesk, and file collaboration systems.

The technical migration is usually the easy part; data export, import, and identity integration are well-trodden paths. The real work is change management: new interfaces for users, new admin models for IT, and license negotiations. Evaluate repurchase candidates early in your planning, because every application you repurchase or retire is one you never have to migrate, and shrinking the migration scope is the cheapest optimization available.

Retire and Retain: The Strategies That Save the Most Money

• Retire

  Every mature environment carries applications nobody uses: the reporting tool that was replaced two years ago but never switched off, the duplicate dev environment, the system whose only remaining user left the company. Discovery data makes these visible; utilization metrics from Azure Migrate assessments routinely reveal servers with no meaningful activity. Retiring them costs almost nothing and permanently removes their infrastructure, licensing, and security surface from your books. It is common for rationalization exercises to shrink the actual migration scope meaningfully before a single workload moves.

• Retain

  Some workloads should stay put, at least for this planning cycle: systems bound to on-premises hardware (manufacturing controllers, license dongles), applications with latency requirements that a round trip to the region cannot meet, workloads under compliance constraints still being worked through, or servers on hardware purchased last year that finance will not write off. Retain is a legitimate strategy, not a failure, provided each retained workload has a documented reason and a revisit date. A hybrid architecture connected through ExpressRoute or VPN keeps retained systems integrated with everything that moved.

The 6 Rs vs Microsoft’s Cloud Adoption Framework Terminology

One source of genuine confusion: Microsoft’s Cloud Adoption Framework does not use exactly the same list. Current CAF guidance describes eight migration strategies: retire, retain, rehost, replatform, refactor, rearchitect, rebuild, and replace. The frameworks describe the same reality with different granularity:

Common 6 Rs Term	Microsoft CAF Equivalent
Rehost	Rehost
Replatform	Replatform (minor changes to adopt managed services)
Refactor	Split into refactor (code-level restructuring), rearchitect (redesigning the architecture), and rebuild (full redevelopment)
Repurchase	Replace (adopt a SaaS solution)
Retire	Retire
Retain	Retain

Do not let the vocabulary slow you down. Whether your team says 6 Rs, 8 Rs, or CAF rationalization, the underlying decision per workload is identical: how much transformation does this application deserve on its way to Azure? Pick one vocabulary for your migration documents and use it consistently so stakeholders are never comparing strategies across mismatched terms.

Building Your Azure Migration Strategy: A 5-Step Process

• Step 1: Inventory Everything

  Deploy Azure Migrate discovery (or import from your CMDB) to build a complete picture: servers, applications, databases, utilization, and the dependencies between them. Strategies assigned without dependency data are guesses, and guessed cutover waves are how migrations break production.

• Step 2: Eliminate Before You Migrate

  Sweep the inventory for retire and repurchase candidates first. Every workload removed here shrinks cost, timeline, and risk for everything that follows.

• Step 3: Assign an R per Workload

  Score the remainder on business value and technical fitness. High value plus poor fitness points to refactor or replatform; low value plus decent fitness points to rehost; vendor-supported SaaS equivalents point to repurchase. Document the reason next to each assignment, because those one-line justifications settle stakeholder debates for the rest of the project.

• Step 4: Prepare the Foundation

  Before the first wave moves, your governance, identity, and network foundation must exist. That foundation is the Azure landing zone, and building it first means every migrated workload inherits security policies, logging, and cost controls automatically instead of having them bolted on later.

• Step 5: Migrate in Waves and Optimize

  Group workloads into dependency-complete waves, starting with low-risk applications to prove the process. After each wave, right-size, apply reservations or savings plans where usage is steady, and feed lessons into the next wave. Post-migration optimization is where the projected savings become real savings.

Common Migration Strategy Mistakes to Avoid

• One R for everything: Blanket rehosting recreates your datacenter in the cloud with its debt intact; blanket refactoring turns migration into a multi-year rewrite. Portfolios are mixed, and strategies should be too.
• Sizing Azure like the datacenter: Matching on-premises specs one-to-one carries years of overprovisioning into a pay-per-use model. Assessment-based right-sizing is where lift-and-shift economics come from.
• Ignoring licensing strategy: Azure Hybrid Benefit for Windows Server and SQL Server, and reserved instances for steady-state workloads, materially change the cost comparison. Model them during planning, not after the first invoice.
• Migrating dependencies apart: Moving an application to Azure while its database stays on-premises inserts a WAN round trip into every query. Dependency-complete waves exist to prevent exactly this.
• No day-2 plan: The migration ends; operations do not. Monitoring, patching, backup validation, security posture, and cost governance need an owner from the first cutover, whether internal or through a partner delivering Azure managed services.

How Apps4Rent Executes Migration Strategies End to End

Apps4Rent is a Microsoft Solutions Partner and Tier-1 Cloud Solution Provider, SOC 2 Type II certified, and has been moving businesses onto Microsoft cloud platforms since 2003, with over 10,000 businesses served. Our Azure migration services cover the full strategy lifecycle:

• Assessment and rationalization: We run discovery, map dependencies, and deliver a per-workload strategy with the R assigned and justified, plus Azure cost projections including Hybrid Benefit modeling.
• Rehost and replatform execution: VMware, Hyper-V, and physical server migrations through Azure Migrate; SQL Server moves to Azure SQL through Database Migration Service; Exchange, SharePoint, and file server transitions to their Microsoft cloud destinations.
• Landing zone and governance: We build the foundation before the first wave, so security and cost controls are inherited, not retrofitted.
• Post-migration operations: 24/7 monitoring, patching, backup, security management, and continuous cost optimization by phone, chat, and email, so the environment keeps improving after go-live.

As a CSP, we also handle Azure subscription provisioning and consolidated billing, which means one partner owns the plan, the move, and the support behind it.

Frequently Asked Questions

1. What are the 6 Rs of Azure migration?

   The 6 Rs are rehost (move as-is to Azure VMs), replatform (move with targeted upgrades to managed services), refactor (restructure the application to be cloud-native), repurchase (replace with a SaaS product), retire (decommission the workload), and retain (keep it on-premises for now). A complete Azure migration strategy assigns one of these to every workload in the portfolio.

2. What is the difference between rehost and replatform?

   Rehosting moves a workload to Azure with no changes at all, typically as virtual machines, while replatforming makes targeted component swaps during the move, such as shifting a database from SQL Server on a VM to Azure SQL Managed Instance. Rehosting is faster and lower risk; replatforming reduces ongoing operational work because the platform takes over patching, backups, and availability for the replatformed components.

3. What is lift and shift in Azure?

   Lift and shift is the informal name for the rehost strategy: moving servers and applications to Azure virtual machines without modifying them. Azure Migrate handles the discovery, assessment, replication, and cutover, allowing workloads to move in planned waves with downtime limited to the final synchronization and switchover.

4. Is lift and shift a bad migration strategy?

   No. Lift and shift is the right strategy when deadlines drive the migration, when applications are stable and vendor-constrained, or when the team needs to build cloud experience before modernizing. It becomes a problem only when it is applied to every workload by default, because it carries existing operational overhead and technical debt into the cloud. The strongest migrations rehost where speed matters and replatform or refactor where the payoff justifies it.

5. Does Microsoft use the 6 Rs framework?

   Microsoft’s Cloud Adoption Framework currently describes eight migration strategies: retire, retain, rehost, replatform, refactor, rearchitect, rebuild, and replace. It covers the same decisions as the common 6 Rs, with the refactor category split into finer levels of transformation and repurchase named replace. Teams can use either vocabulary as long as they apply it consistently across their migration planning.

6. How do I decide which migration strategy to use for each application?

   Score each workload on business value and technical fitness using discovery data. Applications with high value but aging architecture justify replatforming or refactoring, stable low-change applications suit rehosting, workloads with strong SaaS equivalents are repurchase candidates, and anything unused should be retired. Document the reasoning per workload and group migrations into dependency-complete waves.