English 
Português
Modernizing a legacy system is not a single decision: it is one decision per system. Each application has a different value, technical condition, risk and urgency, so each may call for a different path: moving to other infrastructure (rehost), swapping part of the platform (replatform), reorganizing the code (refactor), changing the architecture (rearchitect) or rebuilding from scratch (rewrite).
This guide is for CTOs, IT managers and architects at mid-sized and large companies that depend on proprietary or custom-built systems. You will find a table comparing the five paths, a five-question framework to decide between them, the strangler fig pattern for modernizing without stopping operations, and a four-phase roadmap.
When to modernize and when not to
Modernizing makes sense when the system still supports an important operation and the cost of keeping it as it is (in risk, in dependence on a few people, in difficulty integrating) exceeds the cost of changing it. When the system has lost relevance, the best decision may be to shut it down or leave it as it is.
Google Cloud defines legacy system modernization as the process of updating or replacing outdated systems, architectures and infrastructure so they better align with current and future business goals. The same page makes a point that guides this article: there is no single approach, and the right strategy depends on the application, the goals, the budget and the tolerance for risk.
That is why the starting point is not choosing a technology but classifying the portfolio. The most complete models, such as the AWS 7 Rs, include two options that many lists leave out: retire (decommission the system) and retain (keep it as it is for now, with a date to review). They free up budget and attention for the systems that really need investment.
If you are still assessing whether your system has reached that point, it helps to start with the concept of technical debt and the signs that keeping a system now costs more than modernizing it. Here, we assume the decision to modernize has already been made and the path remains to be chosen.
The five paths: rehost, replatform, refactor, rearchitect and rewrite
The five paths differ in what changes and in how costly a mistake is: from rehost (infrastructure only) to rewrite (everything), effort, potential benefit and the risk of losing business knowledge all increase. The itemis glossary describes the same progression: rehost moves the system without changing it, refactor and rearchitect transform it gradually, and rewrite develops it from scratch, with the highest risk of losing business knowledge.
| Path | What changes | Risk | Effort | Fits when |
|---|---|---|---|---|
| Rehost | Infrastructure only | Low | Low | The system works, but the infrastructure is the problem |
| Replatform | The platform (database, runtime, application server) | Low to medium | Medium | Swapping the platform pays off without touching the logic |
| Refactor | The code, without changing behavior | Medium | Medium to high | The problem is the internal quality of the code |
| Rearchitect | The structure (monolith to modules or services) | Medium to high | High | Scale and coupling demand a different architecture |
| Rewrite | Everything, from scratch (or replaced by an off-the-shelf product) | High | Very high | Business rules will be rethought or the code is unrecoverable |
The risk and effort levels are an editorial reading consistent with the cited sources; they are not measured data and vary by project.
A note on terminology: sources disagree. The original Gartner model, from 2010 (according to IBM), had five Rs: rehost, refactor, revise, rebuild and replace; AWS later expanded the list to seven. In that original model, “refactor” meant running the application on a platform as a service, a different sense from today’s usage, which is reorganizing the code. In this guide, we use the current meaning.
Rehost (lift and shift)
Rehost means moving the system to new infrastructure (usually the cloud) without changing code or architecture. IBM notes that it works best when an organization needs to migrate quickly, lacks the resources to rearchitect or wants immediate benefits such as lower data center costs. The limit is clear: the system keeps the same problems, only in a different place. For cloud-specific costs and risks, see our guide to system migration.
Replatform
Replatform swaps part of the platform (a database, an application server, a runtime version) to gain efficiency without rewriting the logic. It sits between rehost and reorganizing the code: it costs more than moving the system as it is, but usually avoids the risk of touching business rules.
Refactor
Refactor reorganizes the code from the inside, without changing what the system does for the user. It addresses problems such as tangled business rules and dependence on the few people who understand the code. For the full definition and the difference from migration and rewriting, see what refactoring is. What matters here is when to choose this path: when current behavior is fine and the internal structure is what gets in the way.
Rearchitect
Rearchitect changes the structure of the system, for example by splitting a monolith into modules or services. It costs more and takes longer than refactoring because it alters how components relate to each other. It makes sense when scale, coupling or integration needs demand a different architecture, and when the system is strategic for the coming years.
Rewrite (rebuild or replace)
Rewrite means rebuilding the system from scratch or replacing it with an off-the-shelf product. It is the highest-risk path, mainly because of the loss of business knowledge embedded in the old system. It is often the right choice when business rules will be rethought, when the code is unrecoverable or when a market product already meets the need. Rewrite is not a mistake; it is an expensive option that needs justification.
A five-question decision framework
This framework is a NextAge proposal, built on the 5 Rs and 7 Rs models. The idea is to answer five questions per system and let the path emerge from the combination of answers.
- Does the system still deliver strategic value? If not, retire or retain it and invest elsewhere. If so, go to the next question.
- Is the problem in the infrastructure, the platform or the code? If infrastructure, the path is rehost. If platform, replatform. If code or structure, go to the third question.
- Are there documentation, tests and knowledge of the business rules? If not, a rewrite risks losing rules nobody knows exist. Start with a discovery stage and tests that record current behavior.
- How much downtime can operations tolerate? If tolerance is low, prefer an incremental path (strangler fig, covered next). If acceptable downtime windows exist, a big-bang cutover may be viable.
- What are the time horizon and budget? With a short horizon, rehost or replatform solve the urgent need, and refactor or rearchitect wait for a second phase. With a long horizon and a strategic system, an incremental rearchitect usually pays off.
The result can be recorded in a simple table, one row per system:
| System | Strategic value | Main problem | Documented knowledge | Downtime tolerance | Recommended path |
|---|---|---|---|---|---|
| Example A | High | Structure (coupling) | Partial | Low | Incremental rearchitect |
| Example B | Medium | Infrastructure | Yes | Medium | Rehost |
| Example C | Low | Not applicable | Not applicable | Not applicable | Retire |
One detail worth remembering: AWS, in its guide to large-scale migrations, does not recommend refactor in that context, because it modernizes the application during the migration, which adds risk and time. In other words, mixing a change of location with a change of code in the same step is usually riskier than doing one thing at a time.
Strangler fig: modernizing without stopping operations
The strangler fig pattern lets you modernize a system gradually, building the new one around the old one and migrating functionality piece by piece until the legacy system can be switched off. Martin Fowler named it in 2004, after the strangler fig tree, which grows around its host until it replaces it.
Microsoft Learn describes the pattern as a phased approach that lets the existing application keep working during modernization. AWS summarizes it in three steps: transform, coexist and eliminate. In practice, a routing layer (a facade) decides, for each request, whether it goes to the old system or the new one, and the proportion shifts as functionality is migrated.
The advantages are concrete. The microservices.io article highlights that the pattern acknowledges modernization as a process of discovery (the real requirements are not always known at the start) and that it generates continuous feedback. The same source points out the limitation: unlike a big-bang rewrite, the pattern usually requires changes to the legacy system itself.
One management caution: treat the last items of the migration as a phase with its own budget and completion criterion. Without that, the legacy system is never fully switched off and the company ends up maintaining two systems.
Four typical scenarios
The scenarios below are illustrative and do not represent specific clients.
- Stable system on an old server. The application works well but runs on unsupported infrastructure. Likely path: rehost or replatform, with a review in 12 to 24 months.
- Critical monolith that is hard to evolve. Every change takes weeks, and few people understand the code. Likely path: incremental rearchitect with strangler fig, starting with the modules that change the most.
- Code with no tests and hidden business rules. The risk of rewriting is high. Likely path: discovery and characterization tests first, then refactor in parts.
- Standard functionality with an equivalent market product. A general-purpose module (for example payroll or document issuing) that does not differentiate the business. Likely path: replace, with integration to the rest of the environment.
After modernization: support and governance
Modernization does not end at delivery: without ongoing support and governance, the new system goes back to accumulating technical debt and dependence on a few people. An article in IT Forum sums up the challenge: the problem for companies is not only eliminating old systems but preventing modernization from producing a new legacy, more fragmented and harder to govern.
In practice, the post-project phase must answer four questions: who fixes failures and how fast; who adapts the system to changes in the environment; who evolves it; and who tracks indicators and risks. That is what a continuous support model organizes. NextAge’s Application Managed Services, for example, is structured around four pillars (corrective, adaptive, evolutive and governance), with a focus on the root cause of failures, monthly reports and access to operational indicators. Contracting is monthly, with an hours package, a defined SLA and a clear scope from the start, and the service page indicates that about one third of the package goes to monitoring, technical governance and indicators.
NextAge also modernizes legacy systems incrementally, validating each step, without a full rewrite (when the incremental path makes sense, as discussed above). For those who do not yet know where to begin, the first conversation is a diagnostic at no cost and with no commitment, which results in a risk map and an action plan.
A four-phase roadmap
The safest path is to advance in short phases, validating each one before widening the scope.
- Discovery. Inventory your systems, classify each with the five questions, and document dependencies and business rules. Result: a classified portfolio and priorities.
- Pilot. Choose a system or module with controlled risk and apply the chosen path, with success metrics defined before you start. Result: real learning and a more reliable estimate.
- Expansion. Repeat the method across the remaining systems in waves, keeping the legacy system running until each step is validated.
- Support. Define the team, indicators and governance for the modernized system. For new or rebuilt systems, a software factory can carry out the build, and support (AMS) takes over after delivery.
Frequently asked questions
What is legacy system modernization?
It is the process of updating or replacing old systems, architectures and infrastructure so they align with the business’s current goals, with more agility, security and scalability.
What are the legacy system modernization strategies?
The main ones are rehost, replatform, refactor, rearchitect and rewrite (also called rebuild or replace). Broader models, such as the AWS 7 Rs, also include retire, retain and relocate.
What is the difference between rehost and replatform?
Rehost moves the system without changing code or platform; replatform swaps parts of the platform (such as the database or runtime) to gain efficiency, without rewriting the logic.
When is it worth rewriting a system instead of refactoring it?
When business rules will be rethought, when the code is unrecoverable or when a ready-made product meets the need. A rewrite carries the highest risk of losing business knowledge.
What is the strangler fig pattern?
It is an approach named by Martin Fowler in 2004: the new system is built around the old one, and functionality is migrated bit by bit until the legacy system can be switched off.
How long does it take and how much does it cost to modernize a legacy system?
It depends on the path and the state of the system. A rehost tends to be faster, and a rearchitect of a system with years of undocumented rules tends to take much longer. A reliable estimate comes from a discovery stage, not from a generic range.
What should you do after modernizing?
Define support, indicators and governance so the modernized system does not become a new legacy.
Next step
If your company needs to decide the path for a critical system, or make sure it stays healthy after modernization, it is worth talking to a team that handles this kind of operation day to day. Learn about NextAge’s Application Managed Services or talk to a specialist.
