The 7 Rs are the standard menu of legacy modernization approaches: retain, retire, rehost, replatform, refactor, rearchitect, and rebuild. They run from leaving a system untouched to building a new one from scratch — and most real programs use several of them across a portfolio, not just one.
Picking the right R for each system is the whole game. Choose too light an approach and you carry the same problems to new infrastructure; choose too heavy and you spend a year rebuilding logic that already worked. This guide explains each of the seven, what it costs in risk, and how to decide.
What are legacy modernization approaches?
A modernization approach is the strategy you apply to an old system to make it fit a modern stack — not a single tool, but a decision about how far to change the thing. The 7 Rs (an extension of Gartner's original 5 Rs) give that decision a shared vocabulary, so "we're replatforming the billing system but refactoring the order engine" means the same thing to everyone in the room.
The Rs sit on a spectrum of effort and risk. The first question isn't how to modernize a system — it's whether and how far.
The 7 Rs of modernization
Here's the full menu, ordered from lowest effort to highest:
| Approach | What it means | Effort & risk | Best when |
|---|---|---|---|
| Retain | Leave it as-is, revisit later | None | The system works and there's no pressing reason to touch it |
| Retire | Decommission it entirely | Low | The capability is redundant, unused, or replaced elsewhere |
| Rehost | Lift and shift to new infra, no code change | Low | You need cheaper or cloud hosting fast, code is fine |
| Replatform | Move with minor tweaks (e.g. managed DB) | Low–medium | Small changes unlock real hosting or cost benefits |
| Refactor | Rewrite internals, same behavior | Medium | The logic is valuable but the code is hard to maintain |
| Rearchitect | Restructure the system (e.g. to microservices) | High | The architecture itself blocks scale or change |
| Rebuild | Build it new from scratch | Highest | The logic no longer fits and the tech is unsupportable |
The two ends are easy: retain and retire need no engineering. The middle is where judgment lives — and where the legacy system modernization service work actually happens.
Retain and retire — the cheapest wins
The fastest modernization is often no modernization. Retain the systems that work and don't block anything; spend your budget where it moves the needle. Retire anything redundant — every system you switch off is one you never have to migrate, secure, or staff. Auditing for these two first shrinks the rest of the program.
Rehost and replatform — move it, mostly as-is
Rehost (lift and shift) moves an application to new infrastructure, usually the cloud, with no code change. It's the quickest path off failing hardware or an expensive data center. Replatform goes one small step further — swapping to a managed database or container runtime — to capture cloud benefits the raw lift misses. Both are low-risk because the application's behavior doesn't change.
Refactor and rearchitect — change the inside
Refactor rewrites the internals of a system to improve structure, performance, or maintainability while keeping the same behavior. Rearchitect goes deeper, reshaping how the system is organized — for example, breaking a monolith into services. These cost more and carry more risk, but they're how you make a valuable old system genuinely modern instead of just relocated.
Rebuild — the last resort
Rebuild means writing the system new. It's the most expensive and riskiest of the modernization approaches, so it earns its place only when the business logic itself no longer fits or the underlying technology is unsupportable. The mistake teams make is reaching for rebuild by default — and throwing away years of hard-won logic that a refactor would have kept.
How to choose the right approach
Score each system on three axes, then match it to the lightest R that meets the goal:
- Business value — how much the company depends on it. High value justifies more investment.
- Technical health — how maintainable, secure, and supportable the code and stack are.
- Risk and urgency — what breaks, and how soon, if you do nothing.
Low-value or redundant systems get retired. Healthy systems that just need better economics get rehosted or replatformed. High-value systems with bad internals get refactored or rearchitected. Only the few where the logic is the problem get rebuilt. Run this across the whole portfolio and the right mix of approaches falls out on its own.
From approaches to modernization strategies
The 7 Rs are the approaches; a modernization strategy is how you sequence them across the whole estate. Legacy modernization strategies turn this per-system scoring into a staged plan — what to modernize first, what to wrap behind APIs, and what to retire — so the business keeps running while the portfolio evolves. The approaches answer "how far do we change this system?"; the strategy answers "in what order, and at what cost?" For the full playbook, see our legacy modernization strategy guide, and when the decision is between upgrading and starting over, our modernize vs rebuild breakdown.
Modernizing without betting the business
The riskiest part of any approach isn't the code — it's the cutover. A big-bang switch can take operations down. The safer pattern, and the one we use, is incremental: wrap the legacy system in APIs, modernize one capability at a time behind a stable boundary, and keep a rollback at every stage. This strangler-fig method lets the old system keep running in production while the new one grows beside it, so the business never goes dark.
It's also why the people matter as much as the plan. Modernization needs engineers fluent in both old stacks — COBOL, mainframe, dated frameworks — and modern cloud and AI tooling. A senior nearshore team in Mexico, working US business hours from Monterrey, keeps that constant assess-wrap-migrate loop in real time, leaner and lower-cost than an enterprise systems integrator. AI now accelerates the reading and documenting of legacy code, but the judgment about which R to apply is still human.
The bottom line
The 7 Rs aren't a ranking — they're a toolkit. The best legacy modernization approaches for your portfolio are almost always a mix: retire the dead weight, rehost what just needs better hosting, refactor what's valuable but fragile, and rebuild only where the logic itself has stopped fitting. Decide system by system, modernize incrementally, and keep the business running the whole way through.
