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.
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.
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.
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.
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:
| Strategy | One-line definition | Effort | Relative cost | Best for |
|---|---|---|---|---|
| Rehost (lift and shift) | Move the application to cloud VMs unchanged | Low | Low upfront | Deadline-driven exits, stable legacy apps |
| Replatform (lift, tinker, shift) | Move with targeted optimizations, like swapping to a managed database. | Medium | Medium | Apps worth improving but not rewriting |
| Repurchase (drop and shop) | Replace the application with a SaaS product. | Medium | Subscription-based | Commodity functions like CRM, HR, email |
| Refactor / Rearchitect | Redesign the application to be cloud-native. | High | High upfront, variable long-run | High-value apps that must scale and evolve |
| Relocate | Move entire virtualized environments at the hypervisor level | Varies | Medium-high ongoing | VMware estates on tight timelines |
| Retain | Keep the application where it is for now. | None | Existing costs continue. | Compliance-bound, latency-bound, or recently upgraded systems |
| Retire | Decommission the application entirely. | Low | Potential savings | Redundant, unused, or end-of-life apps |
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.
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.
Score every application against these nine factors before assigning an R:
Each strategy below follows the same structure: definition, when to use it, an illustrative scenario, trade-offs, and the pitfall we see most.
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.
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.
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.
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.
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.
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.
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.
| Criterion | Rehost | Replatform | Repurchase | Refactor | Relocate | Retain | Retire |
|---|---|---|---|---|---|---|---|
| Effort | Low | Medium | Medium | High | Varies | None | Low |
| Upfront cost | Low | Medium | Low-medium | High | Low | None | Minimal |
| Ongoing cost | Medium-high | Medium | Subscription | Variable | Potentially high | Unchanged | Eliminated |
| Timeline | Weeks | Depends on scope | Weeks-months | Depends on scope | Depends on scope | N/A | Days-weeks |
| Cloud-native benefit | None | Partial | Vendor-delivered | Full | None | None | N/A |
| Application risk | Low | Medium | Medium | High | Varies | None | Low |
| Typical share of a portfolio | Portfolio-specific | Portfolio-specific | Selective | Few, high-value apps | VMware estates | Portfolio-specific | Portfolio-specific |
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.
| Decision field | Question to answer | Evidence to retain |
|---|---|---|
| Business owner | Who approves continued operation or retirement? | Named owner and sign-off |
| Dependency group | Which systems, data feeds, or users depend on the app? | Dependency map and interface inventory |
| Current cost | What does the application cost to operate today? | Hosting, licensing, labor, support |
| Candidate R | Which strategy fits the known constraints? | Assessment score and rationale |
| Main uncertainty | What must be tested before final approval? | Pilot result or technical proof |
| Review gate | When can the decision change? | Date, approver, and trigger |
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.
Run this sequence for every application in your inventory. It doubles as a decision tree:
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.
All three hyperscalers use the same underlying logic with different vocabulary and tools:
| 7 Rs term | AWS framing and tools | Azure framing and tools | Google Cloud framing and tools |
|---|---|---|---|
| Rehost | Rehost; AWS Application Migration Service | Rehost in the Cloud Adoption Framework; Azure Migrate | Lift and shift; migrate to virtual machines |
| Replatform | Replatform; managed services like RDS | Refactor (minor) / replatform; App Service, managed SQL | Improve and move; Cloud SQL, GKE |
| Repurchase | Repurchase via Marketplace/SaaS | Replace; Marketplace and SaaS | Replace with SaaS |
| Refactor | Refactor/rearchitect | Rearchitect / rebuild | Remove and replace (rebuild); see Google Cloud migration guidance |
| Relocate | Relocate; VMware Cloud on AWS | Azure VMware Solution | Google Cloud VMware Engine |
| Retain | Retain | Retain in CAF assessments | Retain |
| Retire | Retire | Decommission | Retire |
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.
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.
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.
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.
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.