The 6 Rs of Application Modernization Explained

Rehost or refactor? Retire or rebuild?

If you're staring at a portfolio of applications and trying to figure out what to do with each one, then you have landed at the right place.

Six options. One decision per app. And no, you don't get to use the same one for everything.

Pick wrong and the numbers get ugly fast. McKinsey and Oxford found that large IT projects run 45% over budget and deliver 56% less value than predicted. A lot of that comes down to picking the wrong R on day one.

So we're going to walk through each one. What each R means, when to use it and when to stay away.

Key Takeaways

• The 6 Rs of application modernization sit on a spectrum from least change (Retire) to most change (Replace/Rebuild).
• Pick one R per application, not one R for the entire portfolio. Most enterprises use four or five.
• The numbering (5 Rs, 6 Rs, 7 Rs) comes from how the framework evolved since Gartner's 2011 original.
• Three filters decide the right R: strategic value, technical health, and team capability to deliver.
• Replatform is the most underrated R. Retire is the most overlooked. Both are usually under-used in real portfolios.

Where the 6 Rs Came From (And Why You'll See 5, 6, and 7)

Gartner published the original 5 Rs of cloud migration in 2011: Rehost, Refactor, Revise, Rebuild, and Replace. The 5 Rs of modernization were designed for early-stage cloud adoption, not application modernization specifically.

AWS extended this into a 6 Rs framework by adding Retire and Retain, recognising that "do nothing for now" and "decommission" are valid portfolio decisions. This is the set most people mean today when they say "the 6 Rs of application modernization."

In 2021, AWS added a seventh, Relocate, to handle VMware-style block-level moves between data centres. The 7 Rs of cloud migration include all six plus Relocate. Some sources also use Repurchase as a separate R for replacing in-house software with SaaS.

Whichever variant you encounter, the underlying application modernization framework is the same: pick one approach per application based on its strategic value, technical health, and team capability.

1. Retire: Decommission What's No Longer Needed

Retire is the R that's easiest to skip and often the most valuable. You shut the application down. Users either migrate to a consolidated system or stop using the capability altogether.

A portfolio audit at a typical mid-sized enterprise will find that 15–30% of running applications are either redundant, unused, or duplicating functionality available elsewhere. Every one of those is a retire candidate.

When to retire:

• The application has fewer than 50 active users and a clear alternative exists elsewhere in the portfolio.
• The business capability it supports is no longer relevant (product line discontinued, regulation changed, process replaced).
• The cost of keeping it running (licences, infrastructure, security patches, staff time) outweighs its remaining value.

When not to retire:

• The application has compliance or audit requirements that mean it needs to stay accessible, even if only in archive mode.
• Decommissioning would break dependencies you haven't mapped. Always do the dependency analysis first.

The political cost: Retiring is usually blocked not by technology but by the person who owns the application and doesn't want to be the one who switched it off. Strong portfolio governance solves this. Weak governance lets dead applications run forever.

2. Retain: Keep Stable Systems As-Is

Retain is the choice to leave the application alone, on purpose. Not because it's good, but because the cost of touching it outweighs the benefit, given your current priorities.

This is a real decision, not a default. Saying "we'll retain App X" should require the same rigour as saying "we'll refactor App Y." It means: we've looked at this, we've considered the alternatives, and the right call is to leave it alone.

When to retain:

• The application works, isn't actively bleeding money, and your team has higher-priority work elsewhere.
• A vendor or platform decision is pending. You're choosing between SaaS replacements; you're waiting for a partner's roadmap. Don't modernize something you're about to replace.
• Compliance, security, or contractual constraints make change costly enough that it's not worth attempting this year.

When not to retain:

• The application is on unsupported infrastructure with a security exposure clock ticking. Retain plus exposure equals risk.
• "We'll retain it" is being used as a euphemism for "we don't know what to do." Name the problem and decide later, but don't formalise indecision as a strategy.

The portfolio rule: Every retain decision should come with a re-evaluation date. Three months, six months, twelve months, whatever fits, but never indefinite. Retain forever is just neglect with a label.

3. Rehost: Move to Cloud, No Changes

Rehosting is the "lift and shift" move. You take an application running on-premises or on legacy infrastructure and replicate it on cloud infrastructure with no code changes. The application doesn't know it's been moved. It just runs somewhere new.

This is the fastest and cheapest R that involves change. It's also the most overused.

When to rehost:

• The application is non-strategic but still business-critical. You need to keep it running, but you don't need it to be better.
• You're under time pressure (data centre exit deadline, hardware end-of-life, regulatory move).
• The application code is stable and well-understood, so re-engineering carries no upside.
• You want a cloud beachhead: a first easy win that proves the model before you tackle harder work.

When not to rehost:

• The application is already creaking. Lift and shift modernization won't fix performance, technical debt, or the developer experience. You'll just pay cloud rates to run an old problem.
• You're chasing AI-readiness, real-time data, or microservices benefits. Rehosting delivers none of these.
• The licensing model breaks in cloud. Some commercial software charges sky-high cloud rates.

The trap: Rehosting feels like progress because you can show "we moved to the cloud" on a status report. But if the application's underlying issues weren't addressed, you've just relocated them.

4. Replatform: Targeted Infrastructure Upgrades

Replatforming sits between rehosting and refactoring. You move the application to a new platform and make targeted changes that take advantage of that platform, without rewriting the application logic.

Examples: moving from a self-managed Oracle database to a managed cloud database service, swapping a self-hosted message queue for a cloud-native one, containerising a monolith without breaking it into microservices.

When to replatform:

• The application is solid but its underlying infrastructure is the problem. The code is fine; the database, queue, or runtime is the bottleneck.
• You want some of the cloud benefits (managed services, auto-scaling, lower ops burden) without the cost of a full refactor.
• You're standardising across a portfolio and want each application on a consistent platform pattern.

When not to replatform:

• The application's value depends on architectural changes that replatforming won't deliver, like moving to event-driven processing, splitting into microservices, or real-time analytics.
• The team doesn't have the operational experience to run the new platform components.

Where the value lands: Replatforming usually delivers 40–60% of refactoring's benefit at 20–30% of the cost. It's the most underrated R in most modernization portfolios. Teams skip it because it's "not real modernization," then over-commit to refactoring and run out of budget.

5. Refactor / Re-architect: Restructure for Scalability

Refactoring and re-architecting are the two R's most often used together. Refactoring changes the internal structure of the application — cleaner code, better separation of concerns, modular components — without changing what it does from the outside.

Re-architecting goes further: splitting a monolith into microservices, moving to event-driven patterns, swapping the runtime, restructuring the data layer.

The user doesn't see a difference. The engineering team sees a substantially different system.

When to refactor or re-architect:

• The application is strategically important and will be central to the business for years.
• The current architecture blocks something the business needs: speed of feature delivery, scalability, integration with other systems, AI/ML readiness.
• The team has the engineering depth to do it without breaking things. This approach without domain expertise is how you ship two years of risk for one year of value.
• You can scope it into phases. Big-bang refactors fail much more often than incremental ones.

When not to:

• The application is a candidate for retirement or replacement within three years. Don't invest in restructuring something you're about to throw out.
• The codebase is too fragile or undocumented to refactor safely. In that case, Replace or Rebuild is often a better answer than chasing partial refactors that keep breaking.

Rehost vs refactor (the classic question): Rehost is fast, cheap, and changes nothing about how the application works. Refactor is slow, expensive, and changes a lot. The right answer depends on whether the application's current behaviour is the problem or whether its underlying structure is the problem. Rehost the ones that just need new infrastructure. Refactor the ones that need a different shape.

The hidden cost: Refactor and re-architect projects tend to expand scope. What starts as "split the monolith" becomes "split the monolith and redo the data model and fix the testing infrastructure and on it goes." Every such project needs a hard scope boundary and a deliberate decision about what's in and what's parked.

6. Replace / Rebuild: Discard and Start Fresh

This is the highest-effort, highest-risk R. Replace means moving from your custom application to an off-the-shelf product (usually SaaS). Rebuild means writing the application from scratch, keeping the same business logic but starting with a new codebase, new architecture, and new technology stack.

Both options end with you no longer running the original application.

When to replace:

• A SaaS product covers 80% or more of what your custom application does, and the missing 20% isn't strategic differentiation.
• The capability is commodity (HR, payroll, expense management, ticketing, basic CRM). Don't build what you can buy.
• The cost of maintaining the custom application has overtaken what a SaaS subscription would cost.

When to rebuild:

• The existing application is so far gone (undocumented, unsupported, written in technology nobody knows) that refactoring would cost more than rewriting.
• The business logic is well-understood and stable, so the rewrite has clear acceptance criteria.
• The application is strategic enough to justify 12 to 24 months of engineering investment.
• You can run the old and new systems in parallel during transition. Without parallel running, rebuilds carry very high risk.

When not to do either:

• The business logic is unclear or rapidly evolving. You'll rebuild against a moving target, or you'll buy a SaaS product that doesn't fit your real workflow.
• The team has never rebuilt or migrated to SaaS at this scale before. This kind of experience is hard-won, and the first attempt is usually painful.

The honest reality: Most rebuild projects come in late and over budget. The ones that succeed treat the rebuild as a multi-year programme, not a project, and explicitly budget for the 30–50% timeline overrun that's typical. SaaS replacements are usually faster but bring their own scars: data migration, integration with surrounding systems, and change management for end users.

How to Choose the Right R for Each Application

The 6 Rs aren't a menu. They're a decision tree.

Most modernization portfolios end up using four or five of the six approaches across different applications. Using one R everywhere is almost always wrong.

Three filters help structure the choice.

Filter 1: Strategic value

How central is this application to your business, now and in the next three years? High-value applications justify higher-effort approaches (Refactor/Re-architect, Replace/Rebuild). Low-value ones default to Rehost, Retain, or Retire.

Filter 2: Technical health

What shape is the current application in? Healthy applications can stay where they are (Retain) or move with minimal effort (Rehost, Replatform). Unhealthy ones need either deep work (Refactor/Re-architect, Replace/Rebuild) or to be put out of their misery (Retire).

Filter 3: Time, money, team

What can you actually deliver? Rebuilding needs senior engineering capacity. Refactoring needs strong domain knowledge. Rehosting needs operational discipline more than coding skill. Match the R to the team you have, not the team you wish you had.

Lay these three filters across your portfolio and the answer usually becomes obvious. R-by-R picks only make sense inside a coherent application modernization strategy.  Without that, you're optimising individual decisions inside a broken plan.

A Quick Comparison

Summing Up!

The 6 Rs aren't a quiz where there's one right answer. They're a way to force structured decisions across a portfolio that's too big to handle case-by-case.

The teams that get modernization right don't argue about which R is best in the abstract. They look at each application, apply the three filters, make the call, and move on.

At Classic Informatics, we help mid-to-large enterprises apply the 6 Rs across real estates — from portfolio assessment and approach selection to migration design and execution. If you've got a list of applications and you're stuck on which R goes where, let's have a conversation.