The Types of Cloud Migration: Lift-and-Shift to Refactor (the 6 Rs)

Cloud migration strategies are commonly grouped into the "6 Rs": rehost (lift and shift), replatform, refactor, rearchitect, rebuild, and replace. Each trades a different amount of effort and risk for a different level of cloud benefit. Mature migrations rarely pick one - they assign the right R to each workload, guided by frameworks such as Microsoft's Cloud Adoption Framework.

Key Takeaways

• The 6 Rs are rehost, replatform, refactor, rearchitect, rebuild, and replace - a spectrum from lowest effort to deepest transformation.

• Lift and shift (rehost) is fastest and lowest-risk but captures the least cloud-native benefit and can carry technical debt forward.

• Refactor and rearchitect unlock cloud-native value (elasticity, managed services, containers) at higher effort and complexity.

• Microsoft's Cloud Adoption Framework and Well-Architected Framework are the standard references for choosing and governing the approach.

• The right answer is usually a portfolio decision: different workloads get different Rs based on value, risk, and constraints.

What are the 6 Rs of cloud migration?

The 6 Rs are a taxonomy for *how* a given application or workload moves to the cloud, not a single corporate strategy. They run along a spectrum: at one end, you relocate a workload with minimal change; at the other, you rebuild or retire it entirely. The further along the spectrum you go, the more cloud-native benefit you can capture - and the more effort, cost, and risk you take on.

Choosing well requires an honest assessment of each workload's business value, technical condition, and constraints. Centric's Azure migration and modernization practice treats this as a portfolio exercise: inventory the estate, then assign the appropriate R to each workload rather than forcing everything through one door. Here is what each option means in practice.

Rehost (lift and shift)

Rehosting - "lift and shift" - moves a workload to the cloud with little or no change to the application itself, typically from on-premises virtual machines to Azure infrastructure (IaaS). It is the fastest and lowest-risk path, which is why it is popular for time-boxed exits from a data center or a beat-the-end-of-support deadline.

When to use it: tight timelines, large estates, stable applications you do not plan to change soon, or as a first step before later optimization. The trade-off: you capture the least cloud-native benefit. Inefficiencies and technical debt come along for the ride, and a naive rehost can even cost more than on-premises if instances are not right-sized. Lift and shift is a legitimate strategy - just not a finish line for workloads that matter.

Not sure rehost is right for a critical workload? That single decision can determine whether you save money or just relocate your problems. Our deep dive on lift-and-shift vs refactor vs rebuild walks through the trade-offs in detail.

Replatform

Replatforming keeps the application largely intact but makes targeted changes to take advantage of cloud capabilities - for example, moving a self-managed database onto a managed service like Azure SQL, or containerizing an app without rewriting its core. It is sometimes called "lift, tinker, and shift."

When to use it: you want meaningful operational wins (less patching, better scaling, managed backups) without the cost of a full rewrite. The trade-off: more effort and testing than a pure rehost, and you must validate that managed-service behavior matches the application's expectations. For many enterprise workloads, replatform is the pragmatic sweet spot between speed and benefit.

Refactor

Refactoring (sometimes "repackage") changes parts of the application's code or structure to better fit the cloud - introducing cloud-native patterns, decomposing components, or adopting platform services - without a wholesale redesign. It begins to deliver real elasticity and maintainability gains.

When to use it: the application has business value worth investing in, and its current structure limits scalability, deployment speed, or cost efficiency. The trade-off: higher effort, code changes, and regression risk. Refactoring is where migration starts to blur into application modernization, and treating it as a modernization exercise - not just a move - is what makes the investment pay back in reduced technical debt.

Rearchitect

Rearchitecting materially changes the application's architecture to fully exploit cloud-native capabilities - for instance, breaking a monolith into microservices, adopting containers and orchestration, or moving to event-driven and serverless patterns. It targets the highest scalability and resilience.

When to use it: the workload is strategic, long-lived, and constrained by its current architecture, and the business benefit justifies the effort. The trade-off: this is the most demanding of the "keep the app" options - significant cost, time, and skills, with real delivery risk if scoped poorly. Rearchitecting should be reserved for the workloads where cloud-native scale genuinely moves the needle.

Rebuild

Rebuilding discards the existing implementation and recreates the application from the ground up as a cloud-native solution, preserving the business capability rather than the code. It is the deepest transformation short of removing the workload entirely.

When to use it: the existing application is beyond economical repair, no longer fits the business, or blocks a strategic capability, and a clean build will deliver more value than incremental change. The trade-off: highest cost and longest timeline of the build options. When a rebuild is the right call, it is often delivered as bespoke custom application development so the new system is engineered for the cloud from the first line of code.

Replace

Replacing (sometimes "repurchase") retires the custom application and adopts a commercial SaaS or packaged product that delivers the same capability - for example, moving off a homegrown CRM to a vendor platform.

When to use it: the capability is non-differentiating, a mature market product exists, and maintaining custom code is not a good use of engineering effort. The trade-off: you accept the product's constraints, must migrate data, and may face change-management and integration work. Replace is frequently the most cost-effective answer for commodity capabilities.

How do you choose between the 6 Rs?

There is no single correct R; there is a correct R *per workload*. The practical method is to score each workload on business value, technical health, effort, and risk, then map it to the strategy that maximizes benefit within your constraints. The table below summarizes the trade-offs.

Getting this mapping right is the heart of a sound plan. Our guide on how to plan an Azure migration shows how to turn a workload inventory into a sequenced roadmap, so the easy rehosts and the heavier refactors land in the right order.

Where does the Cloud Adoption Framework fit?

Microsoft's Cloud Adoption Framework (CAF) provides the methodology around the 6 Rs - covering strategy, planning, readiness, migration, and governance - while the Well-Architected Framework (WAF) offers pillars (such as reliability, security, cost optimization, operational excellence, and performance efficiency) for evaluating individual workload designs. Both are Microsoft references; the specifics evolve, so treat them as living guidance rather than a fixed checklist.

Used together, they keep an estate-wide migration coherent: CAF governs the program, WAF disciplines each design, and the 6 Rs label the per-workload decision. Centric draws on these alongside its own Microsoft cloud solutions experience, and the practical sequence shows up in the stages of an Azure migration.

How does Centric apply the model?

Centric assesses each workload during its Assess and Plan phase, assigns the appropriate R, and then executes during Migrate and Modernize using tooling such as Azure Migrate for discovery and movement. Lift-and-shift workloads typically complete faster - within weeks - while refactor and rearchitect efforts run longer, often into months, with a milestone-based roadmap agreed up front. The Optimize and Stabilize phase then validates performance, security, and cost, ensuring a rehost does not quietly become an expensive mistake.

Want help assigning the right R to each workload? Centric's Azure migration and modernization services begin with a workload assessment that produces a per-application strategy and a sequenced roadmap. Start the conversation about your estate.

FAQ

What are the 6 Rs of cloud migration?

They are rehost (lift and shift), replatform, refactor, rearchitect, rebuild, and replace - a spectrum of migration strategies from lowest effort and least change to deepest transformation, used to label how each workload should move to the cloud.

Is lift and shift a good migration strategy?

It can be, for the right workloads. Rehosting is fast and low-risk, ideal for deadlines and stable applications, but it captures the least cloud-native benefit and can carry technical debt or even raise costs if instances are not right-sized. It is often a first step rather than a destination.

What is the difference between replatform and refactor?

Replatform makes targeted changes (such as adopting a managed database) while leaving the application largely intact. Refactor changes parts of the code or structure to adopt cloud-native patterns. Refactor is more effort but unlocks more elasticity and maintainability.

How do I choose the right migration strategy?

Score each workload on business value, technical health, effort, and risk, then assign the R that maximizes benefit within your constraints. It is a per-workload, portfolio decision - not one strategy for the whole estate.

What is Microsoft's Cloud Adoption Framework?

It is Microsoft's methodology for cloud adoption, spanning strategy, planning, readiness, migration, and governance. Alongside the Well-Architected Framework, it is a standard reference for planning and governing migrations, though Microsoft updates the specifics over time.