The 7 R’s
Every application you move to the cloud gets a plan, and there are exactly seven plans to choose from. These are the 7 R’s — a menu of migration strategies that runs from “switch it off” all the way to “rebuild it from scratch.” Learn to pick the right R for each app and you turn a scary, all-at-once move into a calm, one-box-at-a-time move.
Imagine your family is moving house. For each thing you own you make one decision: throw it away, keep it in the old place a while longer, carry it as-is, hire a truck for the whole room, buy a brand-new one at the store, tweak it a little to fit the new house, or completely rebuild it. The 7 R’s are those seven decisions — but for computer programs instead of furniture.
Where the 7 R’s came from
☺ Like you’re 10: Smart people kept a list of “ways to move things,” and over the years they added new ways as the cloud got cleverer. The list started at five and grew to seven.
The list has real history — it wasn’t invented all at once. It began as a short list of engineering options and grew, decade by decade, as the cloud matured and people needed words for new ways of moving. Knowing where each R entered the story helps you see why there are seven and not five.
2011 — Gartner’s original “5 R’s” (Richard Watson)
The first version came from analyst firm Gartner. In 2011, Richard Watson published the original “5 R’s”: Rehost, Refactor, Revise, Rebuild, and Replace. This was a purely engineering-minded list — five different degrees of how much you change an application when you move it, from “barely touch it” to “rebuild it.”
2016 — AWS’s “6 R’s” (Stephen Orban)
Five years later, Stephen Orban of AWS reshaped that thinking into the famous “6 R’s” in a widely-read 2016 blog post. He renamed some of Watson’s terms into the words we use today, and crucially added Retire and Retain — two options that cover the apps you don’t actually move at all. That was the leap: the list stopped being only about how to move something and started being about whether to move it in the first place.
☺ Like you’re 10: The 2016 version added “throw it away” and “leave it alone” to a list that used to be only about how to carry things.
Later — AWS adds “Relocate” to make the 7 R’s
Later still, AWS added Relocate — a way to move a whole block of virtual machines at once without changing the apps inside them — turning the six into the modern 7 R’s we use today. The exact wording varies a little between clouds (Azure and Google Cloud describe the same ideas with slightly different labels), but the framework is universal and provider-neutral: for every app, you pick exactly one strategy.
The 7 R’s are not a ranking from worst to best. They are a menu. The “best” R is whichever one gives you the outcome you need for the least effort and risk — and that answer is different for every application.
The two R’s where you don’t move anything
☺ Like you’re 10: Before you pack a box, ask two questions — do we even need this thing anymore, and does it have to move right now?
The cheapest migration is the one you skip. Nutty the Squirrel’s discovery work (see the migration journey) always finds apps that fall into these two buckets first — so it pays to check them before you plan a single box.
Retire — switch it off for good
Retire means turn the app off permanently and stop running it anywhere. During discovery you often find apps nobody uses, or ten different tools that all do the same job. Every one of those is a candidate to simply delete rather than migrate. Effort: very low. Long-term benefit: high — you stop paying for it entirely.
When to use it: the app is redundant, obsolete, or its users have quietly moved on to something else. Example: an old internal reporting tool that was replaced two years ago but never actually switched off. Pro: instant cost savings and fewer things to secure and patch. Con: you must be certain nothing still depends on it — always verify with real usage data before you pull the plug.
☺ Like you’re 10: It’s the box you find in the attic that you can just throw away — nobody has opened it in years.
Retain — keep it where it is, for now
Retain means deliberately leave the app exactly where it is and not move it in this round. Some apps simply aren’t ready: a compliance rule pins the data on-premises, a vendor contract hasn’t expired, or the app is going to be decommissioned soon anyway. Effort: none today. Benefit: it avoids wasted work on something you’d only move once.
When to use it: there’s no business case to move yet, or a hard blocker exists that you can’t remove right now. Example: a mainframe app tied to a vendor contract that ends next year — you retain it until then. Pro: no risk and no rush. Con: you now run a hybrid setup (part cloud, part on-premises) which carries its own connectivity and management complexity.
The five R’s where you actually migrate
☺ Like you’re 10: Now the packing begins. These five range from “carry it exactly as-is” to “build a shiny new version.” The more you change, the more work — but the bigger the cloud reward.
Rehost — “lift-and-shift”
Rehost means move the app to the cloud unchanged — same operating system, same software, just running on a cloud server instead of your own. This is nicknamed lift-and-shift: lift the furniture and set it down in the new house without repainting. Effort: low. Risk: low. Cloud benefit: low-to-medium.
When to use it: you need to leave the old data center fast (a lease is ending), or the app works fine and you just want it in the cloud without a project. Example: moving a Windows application from a physical server to a cloud virtual machine using an automated migration tool. Pro: the fastest way to migrate, easy to reverse, and minimal retraining for the team. Con: you carry old inefficiencies with you and don’t use many cloud-native features yet — modernization, if you want it, comes later.
Relocate — move a whole platform at once
Relocate is like rehost’s big sibling: move an entire virtualized platform to a matching cloud service without buying new hardware, changing the apps, or converting anything. The classic case is moving a VMware environment to a cloud’s managed VMware service. Effort: low. Risk: low. Benefit: medium.
When to use it: you have a large block of virtual machines and want to move them together, quickly, with no app changes. Example: relocating hundreds of VMware VMs to a cloud-hosted VMware offering in one coordinated wave (see wave planning). Pro: very fast for big estates, almost no downtime, and it keeps your existing operational tools. Con: like rehost, you don’t modernize — you’ve just changed the address.
☺ Like you’re 10: Instead of carrying furniture piece by piece, you pick up the whole room and set it down in the new house exactly as it was.
Repurchase — “drop-and-shop”
Repurchase means retire your app and buy a ready-made replacement, usually a SaaS (Software-as-a-Service — software you rent over the internet instead of installing and running yourself). Nicknamed drop-and-shop: drop the old thing, shop for a new one. Effort: medium. Risk: medium. Benefit: high.
When to use it: a commercial product already does the job better than your custom-built app. Example: replacing a self-hosted email or CRM system with a subscription SaaS product. Pro: someone else runs it, patches it, and scales it, so your team is freed from maintenance. Con: you must migrate your data into it, retrain users, and accept the vendor’s way of doing things — you give up some control.
Replatform — “lift-tinker-shift”
Replatform means move the app but make a few smart tweaks to gain cloud benefits — without rewriting the core. Nicknamed lift-tinker-shift: carry it over, but swap a couple of parts on the way. Effort: medium. Risk: medium. Benefit: medium-to-high.
When to use it: a small, contained change unlocks a big win. Example: moving an app to the cloud while swapping its self-managed database for a fully-managed cloud database, so you no longer patch or back it up by hand. Pro: real cloud gains for modest effort — often the best value-for-money middle path. Con: “tinkering” can quietly grow into a full rebuild if you’re not disciplined about scope, so guard the boundary.
Refactor / Re-architect — rebuild for the cloud
Refactor (also called re-architect) means significantly rewriting the app to be truly cloud-native — often breaking it into microservices (small independent pieces), adding containers, or going serverless (see modernization). Effort: high. Risk: high. Benefit: highest.
When to use it: the app is business-critical and its current design actively blocks scaling, speed, or new features. Example: splitting a monolithic order system into separate services that scale independently on demand. Pro: maximum agility, scalability, and long-term savings. Con: the most expensive, slowest, and riskiest path — it needs strong skills and a clear payoff to justify it.
Effort vs. cloud benefit — the big trade-off
☺ Like you’re 10: The more you change an app, the more work it is — but usually the more you get back. This picture shows that climb.
The seven R’s aren’t random — they line up along a single idea: how much you change an app decides both how much effort it costs and how much cloud reward it earns. Plot them and a shape appears.
Reading the climb — from lift-and-shift to rebuild
Follow the dashed line from the bottom-left up to the top-right. Rehost and Relocate sit low and left: little effort, modest reward — you’ve moved the app but barely changed it. Replatform climbs higher for a middle amount of work. Refactor sits at the very top-right: the most effort, but the biggest long-term payoff. Retire and Retain hang off the bottom-left because they’re not really on the migration path at all — you spend almost nothing and the “benefit” is simply the work you avoided.
Why Repurchase sits off the line
Notice Repurchase floats a little below the trend line rather than on it. That’s deliberate: buying a SaaS product gives you a high-quality, well-run result (high benefit) for medium effort — but the benefit is the vendor’s, not a payoff from re-engineering your own code. It’s a genuinely great outcome that simply doesn’t follow the “change more, gain more” rule the other four obey, which is why it doesn’t land neatly on the diagonal.
The whole menu on one card
Here is every strategy side by side — how much work each takes and how much you get back — so you can compare them at a glance:
| Strategy | Nickname | Effort / risk | Long-term benefit | Best when… |
|---|---|---|---|---|
| Retire | Switch it off | Very low | High (savings) | App is unused or redundant |
| Retain | Leave it be | None now | Avoids waste | Blocker exists or no case to move |
| Rehost | Lift-and-shift | Low | Low–medium | Need to exit the data center fast |
| Relocate | Move the platform | Low | Medium | Big virtualized estate, no app changes |
| Repurchase | Drop-and-shop | Medium | High | A SaaS product already does it better |
| Replatform | Lift-tinker-shift | Medium | Medium–high | Small tweaks unlock big cloud wins |
| Refactor | Re-architect | High | Highest | Critical app blocked by old design |
How to decide which R per app
☺ Like you’re 10: For each app, ask a few simple questions. The answers point you to one R — like a flowchart for packing.
You don’t pick a single R for the whole company — you pick one per application, based on evidence from discovery. Two tools help: a short list of criteria to weigh, and a quick decision path to walk in order.
The five decision criteria
For each app, weigh these five factors together — no single one decides it alone:
- Business value — is this app important and growing? High-value apps often deserve replatform or refactor; low-value ones lean toward retire or rehost.
- Technical fit — will it run well in the cloud as-is, or does its design fight against it?
- Effort & time — how many weeks and people will it take, and is there a deadline (like a data-center lease ending)?
- Risk — how bad is it if this app breaks? Higher risk favors safer, more reversible R’s and careful testing.
- Licensing & cost — do software licenses transfer to the cloud, or is a SaaS repurchase actually cheaper over time?
A quick decision path
When you’re staring at a long inventory, walk each app through these questions in order and stop at the first “yes” — it’s a fast way to reach a sensible R that you can then sanity-check against the five criteria above:
- Do we still need it at all? No → Retire.
- Is there a hard blocker (compliance, contract, timing) that stops it moving now? Yes → Retain.
- Does an off-the-shelf SaaS already do this job better? Yes → Repurchase.
- Is it part of a big block of VMs we want to move together, untouched? Yes → Relocate.
- Does it work fine as-is and we mostly need speed out of the data center? Yes → Rehost.
- Would one or two small tweaks unlock a big cloud win? Yes → Replatform.
- Is it business-critical and held back by its old design? Yes → Refactor.
☺ Like you’re 10: It’s like sorting mail — check the quickest question first, and only keep going if the answer is “no.”
Don’t default every app to Refactor because it sounds impressive — it’s the slowest, priciest, riskiest path. And don’t default everything to Rehost just because it’s fast; you may carry old problems into the cloud and pay for them for years. Match the R to the app, not to a fashion.
Pick three apps you know (a shared spreadsheet tool, a company website, a homegrown internal app). For each, write one R and one sentence of “why,” using the five decision criteria above. Then ask: which one would be riskiest to get wrong, and how would you test it before cutover?
Foxy: Professor, there are seven R’s… do we run all seven on every app?
Professor Owl: No — you choose exactly one per app. It’s a menu, not a checklist.
Gizmo: Easy! Refactor everything — rebuild it all, cloud-native, maximum shiny! 🤑
Benny: Gizmo, that old print-log app has three users and dies next quarter. Refactor it? That’s months of my life for nothing.
Timmy: Fact-check: that one’s a Retire. And the VMware cluster? Relocate the whole thing — no rewrite needed.
Professor Owl: Exactly. Least effort for the outcome you need. That’s the whole art of the seven R’s.
Once each app has its R, you have a migration plan you can schedule, test, and cut over one wave at a time. From here, the movers get specific: Ellie handles the boxes in data migration, Mira leads the rewrites in modernization, and Timmy keeps you out of trouble with best practices and anti-patterns.
1. Which two R’s involve not migrating the app at all, and how do they differ? 2. What are the nicknames for Rehost, Replatform, and Repurchase? 3. Which R offers the highest long-term benefit but also the highest effort and risk? 4. Name three criteria you’d use to decide which R an app should get.
Check your answers
- Retire (switch the app off for good because it’s unused or redundant) and Retain (leave it where it is for now because of a blocker or no business case to move yet).
- Rehost = lift-and-shift; Replatform = lift-tinker-shift; Repurchase = drop-and-shop.
- Refactor / Re-architect — the biggest reward, but the most effort, cost, and risk.
- Any three of: business value, technical fit, effort/time, risk, and licensing/cost.