A framework enterprise architects can run in a single workshop. No 200-page assessment required to choose between Rehost, Replatform, Refactor, Repurchase, Retire, and Retain.

Most teams cite the 6Rs (originally formalized by Gartner and popularized by AWS) but freeze when it is time to pick one per application. The result is a multi-month assessment that produces a slide deck nobody trusts. This is the 10-question framework we run in a single 90-minute workshop. It produces a defensible recommendation per app and, more importantly, a defensible sequence the board can sign off on.

The Short Version

The 6Rs (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) only become useful when paired with a forced-ranking question set. Ten questions per app across three axes (business value, technical fit, risk window) self-classify about eight in ten apps in a single workshop. The remaining two in ten are the ones worth a deeper assessment, and that is where discovery budget pays off.

If you remember nothing else: Retire first, Repurchase second, Replatform third. Refactor is the exception, not the default.

Why This Matters in 2026

Three forces are squeezing US enterprises into a decision they cannot defer past 2026. First, hyperscaler co-funding for migration (AWS MAP, Azure Migrate, Google RaMP) is being re-scoped toward AI-ready workloads, which means lift-and-shift credits are smaller and harder to renew. Second, end-of-life dates on Windows Server 2012 R2 ESU, RHEL 7, and several core Oracle and SAP releases land inside the next 18 months. Third, cyber insurance carriers are now pricing legacy-stack exposure explicitly, and renewals in 2026 will demand a documented modernization roadmap, not an intent.

The teams that lose ground are the ones that treat the 6Rs as an abstract taxonomy. The teams that win treat it as a forced-choice exercise with a deadline.

Background: Where the 6Rs Came From

Gartner originally published a five-option migration model (the 5Rs) in 2011. AWS extended it to six (and later seven, adding Relocate) in its 2016 Executive in Residence post on migration strategies. The same six options appear in AWS Prescriptive Guidance today. The labels travel across hyperscalers, but the decisions do not change.

The 6Rs in One Line Each

R: Retain | What it means: Leave it where it is, for now. | Best when: App works, low risk, no business pressure.

R: Retire | What it means: Turn it off. | Best when: Usage under 20%, function duplicated elsewhere.

R: Rehost (lift and shift) | What it means: Move the VM to cloud, no code change. | Best when: Time-critical exit from a data center.

R: Replatform | What it means: Swap one or two components such as the database or runtime. | Best when: You want cloud benefits without a rewrite.

R: Repurchase | What it means: Replace with a SaaS product. | Best when: Commodity function (HRIS, CRM, ITSM).

R: Refactor | What it means: Re-architect for cloud-native. | Best when: Core differentiating app with a long runway.

The 10 Questions

Run each question in order. Stop at the first answer that classifies the app.

1. Is the app still used by more than 20 percent of its intended users? If no, Retire.
2. Is the function available as a mature SaaS your industry already trusts? If yes, Repurchase.
3. Will the business still need this app in three years? If no, Retain with a documented sunset plan.
4. Is there a hard deadline (data center exit, license expiry, a regulator)? If yes, Rehost first and modernize later.
5. Does the app give you a competitive edge customers can feel? If no, Replatform. If yes, continue.
6. Is the codebase well documented and owned by an active team? If no, Replatform. If yes, continue.
7. Does it integrate with more than five other systems through brittle interfaces? If yes, Refactor with a Strangler Fig pattern. If no, continue.
8. Is downtime tolerance under four hours per quarter? If yes, Refactor with blue/green deployment. If no, Replatform is enough.
9. Is there budget for nine to eighteen months of parallel run? If no, Replatform. If yes, Refactor.
10. Does the app handle regulated data (PHI, PCI, NPI)? If yes, add compensating controls regardless of the R you picked.

Two Field Examples

A regional bank we advised had 84 applications and a 2026 data center exit driving urgency. Two days of workshop produced: 11 to Retire, 19 to Repurchase (mostly ServiceNow and Workday), 22 to Rehost (the deadline), 24 to Replatform, 6 to Refactor, and 2 to Retain. The Refactor list was the customer-facing digital banking app and the loan origination system, the two workloads that actually differentiate the bank in its market. The decisions held up under board review.

An automotive client needed to move off shared enterprise infrastructure to a dedicated Microsoft 365 environment. The 6R lens classified the migration as a Replatform with a few Repurchases for satellite functions. Total elapsed time from workshop to cutover plan was six weeks rather than the usual six months because the framework removed the most expensive cost in any modernization program: indecision. The full case study is linked below.

The Sequencing Rule Most Teams Skip

Picking the right R per app is the easy half. Picking the right order is what separates programs that finish from programs that stall. Three rules we apply on every roadmap:

11. Retire before you migrate. Every retired app removes a downstream dependency, a license line, and an audit scope item. Front-load retirements in the first quarter.
12. Move systems of record before the systems that depend on them. Refactoring a reporting layer before its source database is the most common reason programs slip by two quarters.
13. Group apps by shared data domain, not by business unit. Business-unit grouping looks tidy on a slide but creates duplicate integration work and conflicting cutover windows.

Common Mistakes Teams Make Running the 6Rs

• Running the workshop without finance in the room. The R that wins on a technical scorecard often loses on TCO. A finance partner with the run-rate numbers prevents three months of replanning.
• Defaulting to Refactor because it sounds rigorous. Refactor is the most expensive R and the slowest to deliver value. Force every Refactor candidate to justify why Replatform or Repurchase will not do.
• Treating Repurchase as zero engineering. SaaS still needs identity wiring, data migration, integration build-out, and change management. Budget 15 to 25 percent of license cost in year one for these.
• Ignoring Retain. A deliberate Retain with a documented review date is a valid decision. An accidental Retain (the app nobody picked an R for) is debt.
• Skipping a re-score after the first wave. The first 10 to 15 migrations almost always reveal information that changes the R for several remaining apps. Re-run the decision at the end of wave one.
• Forgetting the data and integration backbone. The 6Rs are application-centric. Without a parallel data and integration plan, every R lands on top of the same brittle middleware and the program stalls in year two.

Where the 6Rs Mislead You

• Refactor is not always best. Refactoring a commodity app is a vanity project. In our experience, roughly seven in ten apps should Repurchase or Replatform, not Refactor.
• Rehost is not always cheap. Lift and shift to AWS or Azure without rightsizing typically increases run cost in year one before the cloud bill stabilizes.
• Retire is the highest-ROI R. Every retired app removes recurring license, hosting, audit, and integration cost. Score retirements first.
• Sequencing matters more than the R itself. A wrong R can be revisited. A wrong sequence (refactoring a dependent app before its system of record) wastes the entire program.
• Repurchase is not free. SaaS replacements move cost from CapEx to OpEx and add per-seat growth that finance teams routinely underestimate by 30 to 40 percent over three years.
• The 6Rs do not cover data. You still need a parallel decision on data residency, lineage, and retention. A clean app decision with a messy data decision will fail compliance review.

Frequently Asked Questions

Is this the same as AWS’s 7Rs?

AWS added Relocate for VMware Cloud on AWS. Useful if you are already on VMware. For everyone else, the original 6Rs cover the same ground.

Where does Rearchitect fit in?

Rearchitect is the same as Refactor in this framework. The label changes by vendor. The decision does not.

Should we hire a consultancy to run this?

For 10 to 20 apps, no. Run it internally and trust the output. For 50-plus apps with regulatory exposure, an outside facilitator usually pays for itself in avoided rework and faster board sign-off.

What about mainframe?

Mainframe deserves its own decision lens because the economics, the talent market, and the exit options all behave differently. Do not force mainframe workloads into the 6Rs without that overlay. See our companion field report on GenAI-assisted COBOL refactoring.

How long should the workshop take?

Ninety minutes per 10 to 15 applications, with the right people in the room: one business owner, one architect, one operations lead, and one finance partner per app cluster. Anything longer usually means the wrong people are present or the question set is being relitigated.

What do we do with the 20 percent that do not self-classify?

Park them, finish the other 80 percent, then run a focused two-week assessment on the remainder. By that point the surrounding decisions usually collapse the ambiguity for you.

References

• AWS Prescriptive Guidance: 6 Rs (and 7 Rs) of migration — https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• AWS Executive in Residence: 6 Strategies for Migrating Applications to the Cloud (2016) — https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/
• Martin Fowler: Strangler Fig pattern — https://martinfowler.com/bliki/StranglerFigApplication.html