The 7 Rs of Cloud Migration: Strategies and Examples

Every cloud migration project eventually arrives at the same question: for each application we own, do we move it as-is, improve it on the way, replace it, rebuild it, or leave it alone? The 7 Rs framework exists to answer exactly that question, one application at a time. It has become the shared vocabulary of cloud architects, and with IaaS and data center systems now the fastest-growing segments of a $6.37 trillion global IT market, the pressure to get those per-application calls right has never been higher.

At Calance, we run these portfolio decisions with clients every month, and one recurring risk is that poor early strategy decisions can increase migration expense even when the tooling works, when someone is assigned the wrong R to the wrong workload. So this guide does more than define seven words. We explain where the framework came from, give you an illustrative example for every strategy, compare them all against identical criteria, and hand you the assessment process we use ourselves.

Quick Answer

One Framework, Seven Ways to Reach the Cloud

The 7 Rs (Rehost, Replatform, Repurchase, Refactor, Relocate, Retain, and Retire) provide a framework for common paths an application can take during cloud migration. The terminology developed through earlier migration frameworks and AWS guidance, and today the seven categories are documented by AWS.

The Expensive Part Isn’t Moving; It’s Choosing

Pick the wrong R and you either lift-and-shift technical debt into a pricier home or burn significant effort refactoring an app that should have been retired. Poor workload classification can cause avoidable redesign, delayed schedules, and costs that are hard to reverse.

Match the Strategy to the Application, Not the Trend

A portfolio can use several strategies, depending on application needs. We give you per-R examples, an effort and cost matrix, a step-by-step assessment process, and verdicts for seven common scenarios so you can classify your own applications this week.

What Are the 7 Rs of Cloud Migration?

The 7 Rs of cloud migration describe seven strategies for moving, replacing, retaining, or retiring applications to the cloud: Rehost, Replatform, Repurchase, Refactor (Rearchitect), Relocate, Retain, and Retire. The framework, documented in AWS Prescriptive Guidance, gives organizations a consistent way to classify every application in a portfolio by effort, cost, risk, and payoff before any data moves. Here is the whole framework in one table. If you remember nothing else from this page, remember this:

Where Did the 7 Rs Framework Come From?

Getting the history right matters, because half the articles online get it wrong. Gartner introduced the original 5 Rs around 2010 to 2011: Rehost, Refactor, Revise, Rebuild, and Replace. In 2016, AWS enterprise strategist Stephen Orban published six strategies for migrating applications to the cloud, reshaping Gartner’s categories into Rehost, Replatform, Repurchase, Refactor, Retire, and Retain, which acknowledged for the first time that “don’t move it” and “delete it” are legitimate strategies. The seventh R, Relocate, was added after VMware Cloud on AWS made hypervisor-level migration practical, and the full 7 Rs now anchor AWS Prescriptive Guidance.

The lineage maps roughly like this: Gartner’s Revise became Replatform, Rebuild folded into Refactor/Rearchitect, and Replace became Repurchase, and Retire, Retain, and Relocate are additions that reflect how real enterprise portfolios behave.

Why Is Choosing the Wrong R the Most Expensive Migration Mistake?

Because the strategy decision multiplies across everything downstream. Rehost a sprawling, underutilized application estate wholesale, and you recreate your data center’s inefficiency at cloud prices, which is exactly how companies end up shocked by their first year of bills; Flexera’s annual State of the Cloud research consistently finds organizations estimate that a meaningful share of their cloud spend, often more than a quarter, is wasted. Refactor everything, and the opposite failure arrives: multi-year timelines, consumed budgets, and a business that lost patience before value appeared. McKinsey research on large migrations has found projects routinely running over budget and behind schedule, and hurried classification is one preventable contributor.

The wrong R also compounds quietly. A misclassified application drags its dependencies with it, breaks its integrations, or forces emergency rework mid-wave. We wrote about the broader failure patterns in our guide to the five challenges of cloud migration, and strategy selection sits underneath every one of them.

What Criteria Should Drive Your Strategy Choice?

Score every application against these nine factors before assigning an R:

• Business value. Differentiating applications justify refactoring; commodity ones justify repurchase or retirement.
• Technical debt. The older and more fragile the code, the less sense pure rehosting makes in the long term.
• Licensing constraints. Some enterprise licenses penalize or prohibit cloud deployment; others (like VMware subscriptions) now push toward relocation decisions.
• Compliance requirements. Data residency, industry regulation, and audit scope can force retain or dictate the landing zone design.
• Timeline pressure. A data center lease expiring in nine months rules out portfolio-wide refactoring.
• Budget shape. Rehost is cheap now and pricier forever; refactor is the reverse.
• In-house skills. Microservices without engineers who can operate them is a liability, not modernization.
• Performance and latency needs. Shop-floor systems and trading apps may need to stay close to the hardware.
• Dependencies. Applications migrate in clusters, not alone. Map the web before cutting any single thread.

The 7 Rs Explained With Illustrative Examples

Each strategy below follows the same structure: definition, when to use it, an illustrative scenario, trade-offs, and the pitfall we see most.

1. Rehost (Lift and Shift)

Rehosting moves an application from on-premises servers to cloud virtual machines without changing its code or architecture. It is the fastest way to move a working application and the most common strategy in large legacy migrations, where AWS field experience notes the majority of applications are often rehosted first and optimized later.

When to use it: hard deadlines, stable applications with acceptable performance, or as phase one of a migrate-then-modernize plan.

Illustrative example: a manufacturer moves a legacy ERP hosted on Windows virtual machines to Azure using Azure Migrate. The application remains largely unchanged, while the infrastructure location changes.

Pros: fastest migration path, lowest skill barrier, minimal application risk, mature tooling on every cloud.

Cons: carries inefficiency and technical debt with it, gains no cloud-native benefits, and oversized VMs inflate bills.

Effort and timeline: low; often relatively short, subject to dependencies and testing.

Pitfall: treating rehost as the destination instead of a waypoint. The companies that never revisit rehosted workloads are the ones we meet later through our work on what most companies get wrong about cloud cost reduction.

2. Replatform (Lift, Tinker, and Shift)

Replatforming moves an application to the cloud with targeted optimizations that capture cloud benefits without changing the core architecture. You keep the application; you upgrade its foundations.

When to use it: the application is worth keeping, a few components cause disproportionate operational pain, and you have slightly more time than a pure rehost allows.

Illustrative example: a retailer migrates its e-commerce platform to AWS but swaps its self-managed SQL Server for a managed database service and moves static assets to object storage behind a CDN. The codebase barely changes; the 2 a.m. database patching pages stop entirely.

Pros: real operational wins (managed backups, patching, scaling) for modest effort, often lowers run costs versus rehost.

Cons: scope creep is a constant threat, some platform lock-in begins, and testing needs are higher than rehost.

Effort and timeline: medium; depends on component changes, integrations, and testing.

Pitfall: “tinker” quietly becoming “rebuild.” Define the two or three optimizations up front and defer everything else to post-migration.

3. Repurchase (Drop and Shop)

Repurchasing retires an existing application and replaces it with a SaaS equivalent, moving from owning software to subscribing to it. You migrate data and processes, not code.

When to use it: the application serves a commodity function where SaaS products are mature, customization is light, and maintaining your own version adds no competitive value.

Illustrative example: a professional services firm running an on-premises CRM with years of patches replaces it with a cloud CRM subscription. The project becomes data migration, integration rebuilding, and user training rather than infrastructure work.

Pros: eliminates infrastructure and upgrade burden permanently, instant access to vendor innovation, predictable per-user pricing.

Cons: per-seat costs compound at scale, customizations rarely transfer, data migration and integration work is routinely underestimated, and you accept the vendor’s roadmap.

Effort and timeline: medium; weeks to months depending on data complexity and integrations. Our guide to ERP integrations covers the connective work that makes or breaks these moves.

Pitfall: comparing SaaS subscription cost against license cost alone, forgetting the infrastructure and labor the old system consumed.

4. Refactor / Rearchitect

Refactoring redesigns an application to take full advantage of cloud-native capabilities, such as breaking a monolith into microservices, adopting containers or serverless, and rebuilding data layers on managed services. It is the highest-effort, highest-reward strategy in the framework.

When to use it: the application is core to the business, needs scale or release velocity the current architecture cannot deliver, and the long-term payoff justifies serious investment.

Illustrative example: a logistics company’s monolithic dispatch system buckles every peak season. It is decomposed into containerized services on Kubernetes with event-driven messaging, letting the routing engine scale independently, and releases ship weekly instead of quarterly.

Pros: elasticity, resilience, faster delivery, lowest long-run infrastructure cost per unit of work, unlocks AI and modern data capabilities.

Cons: highest cost and risk, longest timeline, demands skills many teams must first build, and business value arrives late.

Effort and timeline: high; potentially a long engineering program for complex systems. This is the strategy where our application modernization services and DevOps practice spend most of their time, because refactoring without CI/CD and automation discipline just creates a distributed monolith.

Pitfall: refactoring for fashion. If the application doesn’t need to scale or change often, microservices add complexity without return.

5. Relocate (Hypervisor-Level Lift and Shift)

Relocating moves entire virtualized environments to the cloud at the hypervisor level, transferring VMs intact to platforms like Azure VMware Solution or VMware Cloud on AWS without converting machines, changing operating systems, or retraining operations teams.

When to use it: large VMware estates, aggressive data center exit deadlines, or licensing events that make staying on-premises untenable, especially when the operations team’s vSphere expertise is an asset worth preserving.

Illustrative example: a healthcare organization with a VMware estate and an approaching data center lease expiration relocates the entire estate to Azure VMware Solution. Existing management practices can often be reused; individual workloads are then modernized selectively over later phases.

Pros: fastest path for virtualized estates at scale, near-zero application change, and operational continuity.

Cons: typically potentially significant ongoing infrastructure costs, no cloud-native gains until a second-phase effort, and dedicated node commitments require capacity planning.

Effort and timeline: very low per workload; duration depends on VM volumes, network, capacity, and testing. Before committing, work through what to assess before moving VMware workloads to the cloud, and our VMware to cloud migration services exist for exactly this scenario.

Pitfall: treating relocation as the end state. It buys time brilliantly; it saves money rarely.

6. Retain

Retaining means deliberately keeping an application on-premises or in its current environment, documented and revisited on a schedule. It is an active decision, not a leftover bucket.

When to use it: regulatory or data-residency rules that current cloud regions can’t satisfy, ultra-low-latency needs tied to physical equipment, applications nearing retirement anyway, mainframe dependencies, or systems upgraded so recently that migration destroys fresh investment.

Illustrative example: a pharmaceutical company retains a validated lab-instrument system because revalidation under regulatory protocols would cost more than three years of its hosting, while scheduling a re-review when the instrument contract renews.

Pros: zero migration risk, preserves recent investments, respects genuine constraints.

Cons: it maintains two operating models (the hidden cost of hybrid), aging hardware risk continues, and “retain” silently becomes “ignored” without governance.

Effort and timeline: none to migrate, but hybrid connectivity, identity, and security integration still require design, which is where a well-built foundation like the one in our Azure landing zones checklist pays off.

Pitfall: retaining by default instead of by decision. Every retained app needs a documented reason and a review date.

7. Retire

Retiring means decommissioning an application entirely because it is redundant, unused, or no longer worth its cost. It can remove ongoing operating costs, provided dependencies and retention requirements are addressed.

When to use it: duplicate systems after mergers, apps with a handful of logins per month, functionality already absorbed by another platform, or end-of-life software kept alive out of habit.

Illustrative example: during portfolio assessment for an acquisition integration, an organization discovers duplicate reporting tools, file-transfer utilities, and a departmental database. After checking usage, ownership, and retention obligations, it retires redundant systems and reduces the migration scope.

Pros: immediate savings, smaller attack surface, less to migrate, license and support contracts end.

Cons: requires data archival for compliance, political resistance from the two people who still use it, and dependency surprises if discovery was shallow.

Effort and timeline: low; mostly archival, stakeholder sign-off, and clean shutdown.

Pitfall: retiring the app but not its data obligations. Archive to meet retention requirements first, power off second.

Master Comparison: All 7 Rs Side by Side

Calance Application Strategy Decision Record

We recommend recording the reason for each decision before migration begins. The record below gives technical and business owners a common way to review trade-offs and revisit a choice after discovery.

Example assessment: An internally hosted reporting application is lightly used but exports a daily regulatory file. Low usage alone is not enough to retire it. First confirm the recipient, archive requirements, and replacement workflow. The initial decision may be "retain," followed by "retire" after the report is replaced and signed off. This is an illustrative decision case, not a Calance client outcome.

How Do You Decide Which R Fits Each Application?

Run this sequence for every application in your inventory. It doubles as a decision tree:

1. Is the application still used and still needed? No: Retire. Archive data, confirm no dependencies, and decommission.
2. Does a constraint (compliance, latency, contract, recent investment) block migration right now? Yes: Retain, with a documented reason and review date.
3. Does a mature SaaS product cover this function without heavy customization? Yes: Repurchase and plan the data and integration migration.
4. Is this part of a large VMware estate under deadline or licensing pressure? Yes: Relocate the estate, then reclassify individual workloads in a later phase.
5. Is the application high-value, constrained by its architecture, and funded for real change? Yes: Refactor, with the skills and DevOps foundation to sustain it.
6. Would one or two component swaps (managed database, object storage, container packaging) remove most of the operational pain? Yes: Replatform.
7. Everything else:Rehost now, tag it for post-migration optimization, and actually schedule that optimization.

The honest assessment behind steps 1 and 2 is where most of the savings hide, which is why we start every engagement with discovery tooling, dependency mapping, and stakeholder interviews rather than a migration quote.

How Do the 7 Rs Map to AWS, Azure, and Google Cloud?

All three hyperscalers use the same underlying logic with different vocabulary and tools:

Note the terminology traps: Azure historically used “refactor” for what AWS calls “replatform,” and Google compresses the framework into alternative groups such as move, improve, replace, and remove. The concepts align; read definitions, not labels.

Most Real Migrations Combine Multiple Rs

A single-strategy migration is a red flag. Healthy portfolios split across three to five Rs, sequenced into waves: retire and retain decisions first (they clarify scope), relocate or rehost waves next to hit deadlines and exit infrastructure, replatform quick wins alongside, repurchase projects on their own vendor-driven timelines, and refactor programs running as a parallel modernization track rather than blocking the exit. A typical mid-size portfolio we assess lands near a combination of retirement, retention, rehosting, relocation, replatforming, and selective modernization, depending on discovery results. Plan waves around dependency clusters, prove the pattern with a pilot wave of low-risk applications, and keep a standing reclassification process, because discovery always surprises you.

Which Mistakes Should You Avoid?

• Lifting and shifting everything, then wondering why cloud costs exceed the data center.
• Refactoring too much at once, then running out of budget with the data center still open.
• Skipping the retire bucket because nobody wants to own deleting things.
• Letting “retain” mean “never looked at” instead of “reviewed annually.”
• Sizing cloud VMs to match on-prem peak specs instead of actual utilization.
• Migrating before the landing zone, identity, and network design are ready.
• Treating security as a post-migration task; misconfigured access during transition is a classic breach vector, and our breakdown of cloud migration security risks shows how often strategy choices create them.
• Declaring victory at cutover and never running the optimization phase.

What Happens After Migration?

The R you chose determines your day-two work. Rehosted and relocated workloads need right-sizing, reserved-capacity purchases, and a modernization backlog. Replatformed apps need performance baselining against the new managed services. Refactored systems need the operational maturity (observability, CI/CD, incident process) to match their new architecture. Across all of them, cost governance starts immediately: tagging, budgets, and anomaly detection from day one, following the practices in our guide to FinOps on Azure. Migration ends when the business case is realized, not when the last VM boots.

Which Strategy Fits Your Scenario?

• Data center exit on a deadline: Relocate the VMware estate or rehost aggressively, retire ruthlessly first, modernize after the lease ends.
• Cost-cutting mandate: Retire and repurchase lead; replatform the biggest infrastructure consumers; be skeptical of rehost-only plans.
• Modernization initiative: Refactor the two or three systems that differentiate you; replatform the supporting cast; don’t refactor the payroll system.
• M&A consolidation: Retire duplicates first (the highest-value bucket in any merger), repurchase to standardize commodity functions, and rehost the rest into the surviving tenant’s landing zone.
• Heavily regulated workloads: Retain what regulation genuinely requires, document why, and design hybrid connectivity properly; migrate everything regulation doesn’t actually name.
• Hybrid by design: Retain plus replatform, with identity and networking as the real project.
• Mixed portfolio, no burning platform: Run the full assessment, pilot one wave, and sequence by dependency clusters using our Azure migration services playbook: assess, land, wave, and optimize.

Choose the Right Rs With Calance

The framework is free; the judgment is the hard part. At Calance, we assess application portfolios, classify every workload against the 7 Rs with the people who actually run them, design the landing zone, and execute mixed-strategy migrations end to end across Azure and hybrid environments, then stay on for the optimization phase where the business case is actually won through our Microsoft cloud consulting practice.

Talk to our cloud migration team for a portfolio assessment: we’ll tell you which applications to move, which to change, which to drop, and in what order, before you spend a dollar on the wrong strategy.

Frequently Asked Questions

1. What are the 7 Rs of cloud migration?

The 7 Rs are Rehost, Replatform, Repurchase, Refactor (Rearchitect), Relocate, Retain, and Retire: seven strategies for deciding how each application in a portfolio moves to the cloud, or deliberately doesn’t.

2. What is the difference between the 6 Rs and 7 Rs?

AWS’s 2016 framework listed six strategies: rehost, replatform, repurchase, refactor, retire, and retain. Relocate was added later, after hypervisor-level migration via VMware Cloud on AWS became practical, creating today’s 7 Rs.

3. Who created the 7 Rs framework?

Earlier Gartner models described five migration approaches. AWS reshaped and expanded the model, first to six strategies in 2016 and then to seven, now documented in AWS Prescriptive Guidance.

4. What is the difference between rehosting and replatforming?

Rehosting moves an application to cloud VMs with no changes. Replatforming makes targeted optimizations during the move, such as switching to a managed database or object storage, without altering the core architecture.

5. What is the difference between rehost and relocate?

Rehost moves individual applications onto native cloud VMs, usually with some reconfiguration. Relocate moves entire virtualized environments at the hypervisor level (for example, VMware estates to Azure VMware Solution) with no per-application conversion at all.

6. What is the difference between refactoring and replatforming?

Replatforming swaps components while keeping the application’s architecture intact. Refactoring changes the architecture itself, such as decomposing a monolith into microservices, to gain cloud-native scalability and release velocity.

7. Which of the 7 Rs is the cheapest?

Retire is cheapest because it removes cost entirely. Among actual migrations, rehost and relocate have the lowest upfront cost, while refactor can improve long-term unit economics when demand and architecture support it.

8. Which of the 7 Rs is most commonly used?

Rehost is common in time-constrained migrations, with replatforming and refactoring applied selectively afterward, because speed and risk reduction dominate early waves.

9. Which migration strategy is the fastest?

Relocate may be efficient for compatible virtualized estates, but timing depends on dependencies and available capacity. Rehost is fastest for individual applications. Refactor is slowest, often running potentially a long engineering program for complex systems.

10. What is lift and shift in cloud migration?

Lift and shift is the common name for rehosting: moving an application from on-premises servers to cloud infrastructure as-is, without modifying code or architecture, trading optimization for speed and low risk.

11. Is retiring an application really a migration strategy?

Yes. Retire is a formal strategy because deciding not to migrate something is a portfolio decision with real savings. Assessments may identify redundant or unused applications to retire, shrinking cost, risk, and scope before migration begins.

12. When should an application be retained on-premises?

When regulation or data residency blocks cloud placement, latency ties it to physical equipment, a recent upgrade would be wasted, or it is near end-of-life anyway. Every retained application should carry a documented reason and a scheduled review date.

13. Do Azure and Google Cloud use the 7 Rs too?

Conceptually yes. Azure’s Cloud Adoption Framework uses rehost, refactor, rearchitect, rebuild, and replace; Google frames migration as move, improve, replace, or remove. The labels differ, but each maps cleanly onto the 7 Rs.

14. How do you choose between the 7 Rs for an application?

Score it against business value, technical debt, licensing, compliance, timeline, budget, skills, performance needs, and dependencies, then walk the decision sequence: retire, retain, repurchase, relocate, refactor, replatform, and rehost as the default for everything left.

15. Can one migration project use multiple Rs?

It should. Many migration programs use several strategies across the portfolio, sequenced in waves: retire and retain decisions first, rehost or relocate waves for speed, with replatform, repurchase, and refactor tracks running on their own timelines.