Retire, Retain, Rehost, Relocate, Repurchase, Replatform, Refactor. The 7 Rs are not a strategy you pick once for the whole company — they are seven dispositions you assign one at a time, one per application. This is the definitive reference: a precise definition of each R, its cost/effort/risk/time-to-value, the decision logic for choosing between them, the migrate-then-modernize sequencing that ties them together, and a worked example for every R.
The phrase "the 7 Rs" gets used as though it were a strategy. It is not a strategy; it is a vocabulary. Each R is one possible fate for one application. The strategy is the distribution of those fates across a portfolio, plus the order you execute them in. Get that framing right and everything else follows.
A useful mental model: imagine every application in your estate lined up, each facing seven doors labelled Retire, Retain, Rehost, Relocate, Repurchase, Replatform, and Refactor. Migration planning is walking down the line and sending each application through exactly one door — a 30-app estate produces 30 decisions, a 400-app estate 400 — and nothing about the model says they all go through the same one. So "what is our cloud migration strategy?" is the wrong first question; "what is the right disposition for each application?" is the right one. A real strategy is a portfolio of per-application decisions plus the sequencing and business case that justify them.
Two properties hold across the whole model. First, the seven are roughly ordered by ascending effort — Retire costs almost nothing, Refactor costs the most — and cost, risk, and time-to-value generally rise in step. Second, the cloud-native payoff also rises with effort: a Retired app saves its entire run cost but delivers no new capability, whereas a Refactored app can unlock elasticity, managed services, and per-feature scaling the original never could. Most of migration economics is the tension between those two facts. (And the Rs describe what you do to an application, not which tool you use — Rehost is Rehost whether the engine is AWS Application Migration Service or a manual rebuild.)
The 7 Rs did not arrive fully formed. Understanding how the model grew from five options to seven explains why the seven sit where they do — and why a couple of them feel like close cousins of their neighbours.
The original framing came from Gartner analyst Richard Watson in a 2010 research note that proposed five ways to move an application to the cloud: Rehost, Refactor, Revise, Rebuild, and Replace. It was a useful starting taxonomy, but the labels were fuzzy — "Revise" and "Rebuild," in particular, blurred into each other depending on how much of the original code survived. As large-scale migration matured, AWS and the practitioner community reshaped the list into Rehost, Replatform, Repurchase, Refactor, Retire, and Retain — six Rs — and AWS added a seventh, Relocate, to capture an increasingly common case: moving an entire VMware estate at the hypervisor level without converting the individual VMs. The order AWS uses (see the callout) runs loosely from least change to most, so reading the list left to right is reading a gradient of ambition.
The practical reason the history matters: because the model grew by accretion, two pairs of Rs sit close together and are frequently confused. Rehost vs Relocate is one (both move the workload unchanged — the difference is individual VMs vs the whole hypervisor). Replatform vs Refactor is the other (both improve the application — the difference is changing a little vs rebuilding a lot). Most of the genuine decision difficulty in a real migration lives inside those two pairs, which is why each R gets extended treatment below.
In AWS's order: Retire (decommission), Retain (keep where it is, for now), Rehost (lift-and-shift the VM), Relocate (move the hypervisor, not the VMs), Repurchase (drop and adopt SaaS), Replatform (lift-tinker-shift), Refactor (re-architect). Gartner's original five (2010) were Rehost, Refactor, Revise, Rebuild, Replace; the practitioner consensus reshaped and extended them to these seven.
The first four dispositions range from "do nothing but switch it off" to "move it exactly as it is." They carry the lowest effort and the lowest risk, and between them they account for the majority of a typical estate.
A blunt truth about real migrations: most applications do not need to be rebuilt, and a meaningful fraction do not need to move at all. Honest discovery routinely finds servers running at near-zero utilisation that nobody has logged into for months. The four Rs below are where the bulk of an estate lands — and getting comfortable with the unglamorous ones (Retire and Retain especially) is what keeps a migration on budget.
What it means: The application is no longer needed, so you decommission it rather than migrate it. Every server you retire is one you never pay to assess, move, test, license, or run again. Retire is the only R with negative cost — it removes spend rather than adding it.
When to choose it: Discovery shows near-zero CPU and network activity, no recent logins, or the function has been superseded. Classic candidates: duplicated dev/test environments, internal tools replaced by SaaS, dormant reporting servers, and "we think someone still uses that" boxes that turn out to be idle.
Cost / effort / risk / time-to-value: Effort is low (confirm it is truly unused, snapshot any data you must keep, decommission); cost is negative; value is immediate. The one risk — retiring something that turns out to matter — is mitigated by a short observation window and a data-retention snapshot before the lights go out.
Worked example: A discovery scan flags 140 servers; over a six-week window ~19 show effectively no traffic — old QA environments and reporting servers superseded by a BI tool. After a snapshot and sign-off they are retired before the migration even starts, cutting the servers to move (and pay a partner to handle) by ~14% on day one.
What it means: You consciously decide not to migrate the application yet, leaving it in its current environment. Retain is a deferral, not a permanent verdict — and it should always carry a documented revisit date.
When to choose it: A hard data-residency or compliance constraint, a mainframe or licensed appliance with no clean cloud path, an application slated for retirement within ~12 months, or a tight coupling to a system that must move first. Retain is a legitimate answer; forcing a doomed or constrained app into the cloud just to claim "100% migrated" is a mistake.
Cost / effort / risk / time-to-value: No effort now (you defer); cost is the continuing legacy run cost plus a possible hybrid-connectivity bill (Direct Connect or VPN) if the retained app must talk to migrated systems; no direct migration value. The risk is a permanent "temporary" hybrid state — Retain decisions without a revisit date have a way of becoming forever.
Worked example: A healthcare workload sits under a residency rule the target region cannot satisfy until a new local zone goes live in nine months. Rather than block the migration, the team marks it Retain with a revisit date tied to the zone launch, stands up a temporary VPN so the migrated front-end can still reach it, and moves on with the other 60 applications.
What it means: Move the application to the cloud essentially unchanged — same OS, same binaries, same configuration — typically by replicating the server into a cloud VM. No code changes, no architecture changes. This is the workhorse disposition for most portfolios.
When to choose it: You need to exit a data centre or another cloud quickly (a lease expiry, a renewal deadline, a divestiture clock), the application is stable and you would rather not touch it, or it is a deliberate stepping stone — Rehost now, modernise later once you have real usage data. Rehost is the default for the single largest share of most estates.
Cost / effort / risk / time-to-value: Effort is low-to-moderate (replication, a test cutover, then production cutover), migration cost is the lowest of the genuinely-moving Rs, and the move is fast — weeks per wave. Risk is low: replication keeps the source running until cutover, so you can roll back. The honest tradeoff is that a pure lift-and-shift can cost more per month than the source if you forget to right-size cloud VMs sized like the old on-prem hardware — right-sizing during the Rehost is where the savings come from.
Worked example: A logistics company with a lease expiring in five months has 180 mostly-stable applications — too many to modernise in the window — so the bulk are Rehosted: replicated, tested in a staging cutover, then cut over wave by wave, with each VM right-sized down a tier or two based on observed utilisation. The estate exits on time, and right-sizing turns a flat lift into a ~20% run-cost reduction.
What it means: Move an entire virtualised environment — most commonly a VMware estate — to the cloud at the hypervisor level, without converting the individual VMs to native instances. The VMs keep running as VMs, just on cloud-hosted infrastructure (for AWS, VMware Cloud on AWS). It is the lowest-touch way to move a large vSphere footprint.
When to choose it: A large VMware estate that has to exit a data centre fast, where converting hundreds of VMs to native instances one at a time would take far too long and the operations team already lives in vSphere and wants to keep its tooling. Relocate buys time: move in weeks at the platform level, then Replatform or Refactor selectively afterwards, at your own pace.
Cost / effort / risk / time-to-value: Effort is low relative to converting every VM (you move the platform, not each guest), exiting the source is very fast, and risk is low because the VMs do not change. The cost catch: you pay for VMware-on-cloud capacity, its own pricing model and not the cheapest steady state — so deeper cloud-native savings are deferred until you convert selected workloads off the relocated platform. Relocate is a fast on-ramp, not usually the final destination.
Worked example: A manufacturer running ~300 VMs across two vSphere clusters faces a data-centre exit in four months — converting 300 VMs individually is a non-starter. Instead they Relocate the whole VMware environment to a cloud-hosted vSphere, keep their existing tooling intact, hit the deadline, and over the following year peel off the highest-value workloads to Replatform or Refactor onto native services.
The final three dispositions change the application itself — by replacing it entirely, by optimising parts of it, or by rebuilding it. They carry more effort and more risk, but they unlock the value that the lift-and-shift Rs leave on the table.
This is where migration shades into modernisation: Repurchase removes an application by buying a replacement, Replatform keeps it but swaps components for managed equivalents, and Refactor rebuilds it around cloud-native primitives. The further right you go, the larger the prize and the larger the bill — which is exactly why the sequencing in the next section matters so much.
What it means: Retire the existing application and replace its function with a commercial product, usually SaaS — off a self-hosted CRM to a SaaS CRM, off a custom helpdesk to a SaaS helpdesk, off a legacy HR system to a SaaS HRIS. You are not migrating the app; you are replacing the capability and decommissioning the original. (Sometimes called "drop and shop.")
When to choose it: The application is a commodity capability with a strong off-the-shelf market, the self-hosted version is expensive to run or maintain, or its customisations no longer earn their keep. Repurchase is most attractive where the business logic is generic (email, CRM, collaboration, HR, ticketing) rather than a genuine differentiator.
Cost / effort / risk / time-to-value: The effort is not infrastructure work but data migration, integration, and change management — the organisational lift (retraining users, re-wiring integrations, reproducing custom reports) is the real cost and risk. Value is variable: fast if the SaaS maps cleanly onto how the business works, slow if it forces process change. Watch for feature gaps versus the bespoke system and for subscription cost replacing one-off run cost; the recurring benefit is that you stop running and patching the application entirely.
Worked example: A company runs a heavily customised self-hosted CRM on three servers that two people spend half their time maintaining. Rather than Rehost it, they Repurchase: migrate the accounts and pipeline data into a SaaS CRM, re-point the integrations, retrain the sales team over a few weeks, and decommission the servers — converting a maintenance burden into a predictable subscription and freeing the maintainers for higher-value work.
What it means: Move the application to the cloud while making a few targeted optimisations that do not touch its core architecture — the "lift-tinker-shift" middle path between Rehost and Refactor. The canonical move is swapping a self-managed component for a managed equivalent: a self-hosted database becomes a managed database service, a hand-rolled VM cluster moves to a container service, static assets move behind a managed CDN, TLS termination moves to a managed load balancer.
When to choose it: The application is fundamentally sound but carries a couple of high-toil components a managed service would handle better — most often the database (offloading patching, backups, failover) or the runtime (snowflake VMs to managed containers). Replatform is the sweet spot when Rehost leaves obvious operational savings unclaimed but a full Refactor cannot be justified.
Cost / effort / risk / time-to-value: Effort is moderate — more than Rehost (you change components and must test the swaps), far less than Refactor (the architecture stays put) — and the payoff is quick, landing in weeks per application. Risk is contained because each change is bounded and individually testable. Managed services typically cut operational toil and improve resilience immediately, and you start capturing cloud-native savings a pure lift-and-shift never reaches.
Worked example: A web application runs on hand-managed VMs with a self-hosted PostgreSQL database the team spends real time patching. Instead of a flat Rehost they Replatform: the application tier moves to a managed container service, the database to a managed PostgreSQL service (automated backups, patching, a failover standby), and static assets behind a managed CDN. No code is rewritten, yet operational toil drops sharply and the database is materially more resilient.
What it means: Substantially rewrite or re-architect the application to take full advantage of cloud-native capabilities — decomposing a monolith into services, adopting serverless functions, moving to event-driven patterns, replacing a relational store with a purpose-built database where it fits. Refactor changes how the application is built, not just where it runs. (Some frameworks call the most extreme version "Re-architect"; it sits at the same end of the spectrum.)
When to choose it: The application is strategically important and its architecture is actively holding the business back — it cannot scale to meet demand, it is too slow to change, or its cost is structurally high because it cannot use elastic, pay-per-use services. Refactor is justified when the future value (agility, elasticity, per-feature scaling, lower marginal cost) clearly exceeds the considerable cost of the rebuild. It is the wrong default for commodity or stable applications.
Cost / effort / risk / time-to-value: The highest of all seven on every axis — most engineering effort, longest timeline, most risk (you are changing behaviour, not just location) — and the slowest to realise but largest once it does. The benefits (elasticity, faster delivery, lower marginal cost) compound over time, so Refactor pays back best on applications you will invest in for years. The mitigation is scope discipline: Refactor only where the payback is unambiguous, and resist rebuilding what a Rehost or Replatform would have served perfectly well.
Worked example: A SaaS company's core monolith cannot scale its busiest feature independently, so peak load forces the team to over-provision the whole application. They Refactor: the hot feature is extracted into independently scalable services, batch work moves to serverless functions that cost nothing when idle, and the messaging backbone goes event-driven. The rebuild takes two quarters — but the feature now scales on its own, idle cost collapses, and ship velocity for that part of the product roughly doubles.
Knowing the seven definitions is the easy part. The real skill is the disposition decision — looking at one application and confidently sending it through one door. There is a repeatable logic to it, and it is mostly about asking the questions in the right order.
The decision is driven by two forces in tension: business value (how strategic is this application, and how much would cloud-native capability help it?) and migration effort (how hard, risky, and expensive is each disposition for this specific app?). The right R maximises value for the effort you are willing to spend — which is rarely the most ambitious option and almost never the laziest.
A practical way to run the decision is a short cascade of questions, asked in order. The first "yes" usually points at the disposition:
Three guardrails keep the decision honest. Default down, not up: when two Rs both look defensible, the lower-effort one is usually right, because its cost and risk are immediate while the higher R's extra payoff is speculative and deferred. Decide per application, not per portfolio — a single estate will legitimately span all seven Rs, and applying one favourite R to everything optimises for tidiness, not outcomes. And write down the why: a disposition without a recorded rationale and (for Retain) a revisit date will be re-litigated endlessly and quietly drift. On any estate beyond a handful of apps this pass is a structured exercise — automated discovery for real utilisation and dependencies, then a portfolio analysis that assigns one R per app and groups them into waves — which for AWS migrations is the (frequently AWS-funded) Assess phase covered next.
Assigning an R to every application is necessary but not sufficient. The dispositions still have to be executed in an order that controls risk and starts returns early. The 2026 consensus on that order has a name: migrate-then-modernize.
The core idea is simple. Move first with the lowest-risk disposition that exits the source environment — usually Rehost, sometimes Relocate or Replatform — so you stop paying for the old environment, start the clock on cloud savings, and begin collecting real production usage data. Then Refactor selectively, once you are on the cloud and can see which applications actually warrant the investment. The alternative — Refactor everything during the migration — is the single most reliable way to blow both the timeline and the budget, because you take on the hardest disposition for every app at the exact moment you have the least operational data and the most schedule pressure.
Several concrete reasons this ordering wins: you exit the costly source environment sooner (often the whole financial point of the migration — the lease, the renewal, the divestiture clock); you gather real usage data on the cloud, making later Refactor decisions evidence-based rather than guesses; you de-risk by changing one variable at a time (move the app, prove it works, then change how it is built); and you bank savings — especially if you right-size during the Rehost — that help fund the modernisation that follows.
It does not mean "Rehost everything and modernise never." The Refactor work is real and planned — it just happens after the move, targeted where the assessment said the payback is clear and informed by data the migration produced. Nor does it forbid all modernisation during the move (Replatform bakes light optimisation in; Repurchase replaces an app outright); the rule is specifically about heavy Refactor. As practitioners put it, the right amount of modernisation is "less ambitious than engineering wants, more ambitious than finance fears" — the assessment sets the targets, migrate-then-modernize sets the order.
Move with the lowest-risk R that exits the source environment (usually Rehost, right-sized), start saving and collecting real usage data, then Refactor the handful of applications where the data confirms the payback — never the whole estate, never during the cutover.
A common planning mistake is to imagine a heroic, mostly-Refactor migration. Real estates almost never look like that — the mix tends to cluster in a recognisable shape, heavy in the middle with a meaningful Retire tail and a small, deliberate Refactor set. The numbers below are directional anchors, not promises (the actual mix falls out of the assessment), and they work best as a gut check: a draft plan with 60% Refactor is wrong, and one with 0% Retire has not looked hard enough.
The pattern to take from those bands: the low-and-middle Rs dominate, and Refactor is a scalpel rather than a sledgehammer — its small share is a feature of a well-run migration, not a failure of ambition. The estates that get into trouble invert this shape and try to rebuild everything; the ones that finish on time and on budget respect it.
One table to hold the whole model. Effort, migration cost, risk, and cloud-native payoff generally rise as you move down the list; time-to-value is fastest for the do-nothing Rs and the lift-and-shift Rs, slowest for Refactor. Use it as a quick reference when assigning dispositions.
| R (disposition) | What you do | Effort | Risk | Time-to-value | Best for |
|---|---|---|---|---|---|
| Retire | Decommission — switch it off | Very low | Low | Immediate | Idle / superseded apps |
| Retain | Leave it in place, for now | None now | Low | None (deferral) | Constrained or soon-to-die apps |
| Rehost | Lift-and-shift the VM, as-is | Low–moderate | Low | Fast (right-size to realise) | Stable apps, deadline-driven moves |
| Relocate | Move the hypervisor (e.g. VMware) | Low | Low | Very fast to exit source | Large VMware estates on a clock |
| Repurchase | Drop the app, adopt SaaS | Moderate (data + change mgmt) | Moderate | Variable | Commodity capabilities (CRM, HR) |
| Replatform | Lift-tinker-shift — managed swaps | Moderate | Contained | Good (weeks) | Sound apps with high-toil components |
| Refactor | Re-architect for cloud-native | High | Higher | Slowest, largest payoff | Strategic apps held back by architecture |
Situation: A hard lease-exit deadline with no realistic chance of modernising 120 applications in six months. The team had a long server list but no disposition for any of it, no view of what was actually idle, and an engineering instinct to Refactor far more than the timeline or budget could support. They needed the estate classified, sequenced into waves, and a credible plan to hit the deadline without a flat, savings-free lift.
What CloudRoute did: Routed within a day to a vetted AWS partner who ran the Assess phase (Application Discovery Service + portfolio analysis), funded through the Migration Acceleration Program. The pass assigned all seven Rs: ~18 Retired (idle/superseded), ~12 Retained (compliance + imminent decommissioning, each with a revisit date), the large VMware bulk split between Relocate and right-sized Rehost to hit the deadline, ~9 Replatformed (databases to managed services), 4 Repurchased (self-hosted CRM and helpdesk to SaaS), and 6 strategic apps flagged for Refactor after the move — then waves and a TCO business case.
Outcome: The estate exited on schedule via the migrate-then-modernize sequence. Right-sizing during Rehost turned a flat lift into a double-digit run-cost reduction, the Retire pass removed ~15% of the servers before any migration spend, and the six Refactor candidates were scheduled for the following two quarters using real post-move usage data. The Assess phase and a large share of the migration were AWS-funded — net cost to the customer near $0; CloudRoute's commission was paid by the partner.
estate: ~120 apps · all 7 Rs assigned · servers cut ~15% pre-migration via Retire · sequence: migrate-then-modernize · cost to customer: ~$0 (AWS-funded)
CloudRoute routes you to a vetted AWS partner who runs the disposition assessment (the MAP Assess phase, frequently AWS-funded), assigns the 7 Rs per application, sequences the waves, and executes migrate-then-modernize. The migration itself is often MAP-funded too — typically $0 to you.