Legacy Modernization Approaches: Which of the 7 Rs Fits You?

There are seven legacy modernization approaches, known as the 7 Rs: retain, retire, rehost, replatform, refactor, rearchitect and replace. The right one depends on each system’s business value and technical health, not on what worked for another company. In my experience leading modernization projects, the costliest mistake is applying a single approach to an entire IT estate. This guide explains each R, compares them on cost, time and risk, and gives you a simple framework to choose the right one for every system in your portfolio.

What Are Legacy Modernization Approaches?

Legacy modernization approaches are the seven ways to update an outdated system, known as the 7 Rs: retain, retire, rehost, replatform, refactor, rearchitect, and replace. Each approach changes the system to a different degree, from keeping it exactly as it is to swapping it for new software. Together, they form the decision layer of any legacy system modernization program. The roadmap sets when you act, and the approach sets what happens to each system.

The 7 Rs sit on a scale of effort. Retain and retire involve the least change and cost the least. Rehost and replatform move a system to new infrastructure with little or no code change. Refactor and rearchitect rework the code and its structure to remove technical debt. Replace demands the largest investment, because it either rebuilds the application from scratch or moves the function to SaaS.

The right approach is chosen per system, not once for the whole IT estate. In the portfolios we assess for Australian clients, a single estate typically uses several Rs at once. For example, a stable core system is retained, a customer-facing app is rearchitected, and a back-office tool is replaced with SaaS. The comparison table and selection framework below show how to match each system to the right R.

The 7 Rs of Legacy Modernization Explained

Each of the 7 Rs fits a different kind of system, depending on its business value, its technical health and how much change your team can absorb. We explain them in order of effort, from retain to replace, covering what each R involves, when it fits, and when to choose a different one.

1. Retain: Keep the System and Revisit Later

Retain means keeping a legacy system as it is and scheduling a review, instead of changing it now. It fits systems that are stable, still meet business needs and carry low security and support risk, such as a core calculation engine that rarely changes. Retain is the lowest-cost R in the short term, and it is the right call when your modernization budget delivers more value elsewhere in the portfolio.

Retain is the wrong choice when the vendor has ended support, when the system blocks critical projects such as AI adoption, or when only one or two staff still understand it. If you retain, plan for two Australian requirements:

• Security: a retained system keeps its compliance duties, so Essential Eight controls such as patching and application control still apply.
• Operational resilience: APRA-regulated entities must show under CPS 230 that critical operations running on the retained system stay within tolerance levels.

A retained system still has to work with new applications, so most teams add an API layer around it. For example, an insurer keeps its mainframe policy engine unchanged and exposes policy lookups to a new customer portal. Give each retained system a fixed review date, so retain does not quietly become “ignore”.

2. Retire: Switch Off Systems You No Longer Need

Retire means permanently switching off a legacy system that no longer delivers enough value to justify its cost. It fits duplicated, rarely used or end-of-value applications, such as a second CRM left over from a merger, or an old reporting tool that a BI platform has already replaced. Retire is usually the cheapest R in any portfolio, because it cuts licensing, hosting and support costs instead of adding new spending.

Retire is the wrong choice when a system still holds data or functions that no other platform covers. Before switching anything off, confirm two Australian obligations:

• Record-keeping: business records must be kept for their required period, which is generally five years for tax records under ATO rules.
• Privacy: Australian Privacy Principle 11 requires you to destroy or de-identify personal information once it is no longer needed.

The switch-off process itself, covering data extraction, archiving and decommissioning, is part of the move.

3. Rehost: Move the System As-Is to New Infrastructure

Rehost, often called “lift and shift”, means moving a legacy system to new infrastructure, usually the cloud, without changing its code. It fits systems that work well for users but run on failing hardware or in a data center with an expiring lease. Rehost is the fastest real change among the 7 Rs. A single application typically moves in weeks to a few months, depending on its dependencies.

Rehost is the wrong choice when the code itself causes the pain. Technical debt, slow release cycles and integration gaps move to the cloud unchanged. Cloud bills also tend to rise, because the application is not designed to scale up and down. If you rehost, plan for two Australian requirements:

• Security: a rehosted system keeps its old software versions, so Essential Eight controls such as patching and application control still apply in the new environment.
• Data residency: choose an Australian cloud region, such as Sydney or Melbourne, when the system holds personal or regulated data.

Rehost is often the first step of a wider cloud migration, with replatforming or refactoring following once the system is stable in its new environment.

4. Replatform: Make Small Changes to Run on a Modern Platform

Replatform means moving a legacy system to a modern platform and changing only the parts that connect to it, such as the database or hosting layer. The core business logic stays the same. It fits systems whose code works well but whose infrastructure is costly to run or hard to scale.

From our projects: A Japan-based EdTech company needed its learning platform, used by 2,000+ students and teachers, to scale without any code changes. We moved its Docker Swarm cluster from an on-premises data center to AWS, adding auto-scaling and CloudWatch monitoring. Deployments now run 60% faster, and infrastructure costs fell by 25%.

Replatform is the wrong choice when the code itself causes the pain, because a tightly coupled monolith stays tightly coupled. If you replatform, plan for two requirements:

• Shared responsibility: the provider patches the platform, but you still secure the application and its data under Essential Eight.
• Service location: confirm that each managed service runs in an Australian region.

Replatform delivers most of its savings through managed cloud services, which shift routine operations such as backups, scaling and patching away from your team.

5. Refactor: Clean Up the Code Without Changing What It Does

Refactor means restructuring a legacy system’s code to remove technical debt, while keeping its features and behavior exactly the same. Typical work includes splitting oversized modules, removing dead code, upgrading outdated frameworks and adding automated tests. It fits systems that still serve the business well but are slow to change, hard to test or built on unsupported libraries. Refactoring a single application typically runs over several months, alongside regular feature work.

Refactor is the wrong choice when the architecture itself limits the business. A monolith with clean code is still a monolith, and it still cannot scale individual features or release them independently. In that case, rearchitect instead. If you refactor, plan for two Australian requirements:

• Security: replacing unsupported frameworks and libraries closes known vulnerabilities, which supports the Essential Eight controls for patching applications.
• Test data: use masked or synthetic data in test environments, because Australian Privacy Principle 11 requires reasonable steps to protect personal information wherever it is stored.

Refactoring is also the usual groundwork for rearchitecting, because clean, well-tested modules are far easier to split into independent services.

6. Rearchitect: Redesign the System for Cloud-Native Scale

Rearchitect means changing a legacy system’s structure, typically by splitting a monolith into microservices or moving to an event-driven or serverless design. It fits systems that hold real business value but cannot keep up with growth. Common signs are that one busy feature slows down the whole application, releases need weeks of coordination, or new capabilities such as real-time data and AI cannot fit into the current design. Rearchitecting a core system typically takes 6 to 18 months, delivered in phases.

Rearchitect is the wrong choice for small, stable systems with few changes. Microservices add operational overhead, including more services to monitor, secure and deploy, which only pays off at scale. If you rearchitect, plan for two Australian requirements:

• Operational resilience: APRA-regulated entities must show under CPS 230 that critical operations stay within tolerance levels during the change, so map each critical operation to the new services.
• Data flows: a distributed design moves personal data between more services and locations, so confirm that cross-border flows meet Australian Privacy Principle 8.

Most rearchitecture projects follow the strangler fig pattern, which replaces the old system service by service on a cloud-native platform until the legacy core can be switched off.

7. Replace: Rebuild From Scratch or Switch to SaaS

Replace means retiring a legacy system’s code entirely, either by rebuilding the application from scratch or by switching to SaaS or off-the-shelf software. Rebuild fits systems that give you a competitive edge but whose code is too outdated or fragile to refactor, such as a custom pricing engine. SaaS fits functions that do not set you apart, such as HR, payroll, finance and CRM. A rebuild typically takes 12 months or more, while a SaaS rollout usually takes a few months.

Replace is the wrong choice when the system works and only its infrastructure or code quality holds it back, because rehosting, replatforming or refactoring costs far less. SaaS is also the wrong route for a differentiating process, because heavy customization erodes the benefits of standard software. If you replace, plan for two Australian requirements:

• Data location: check where a SaaS vendor stores and processes data, because sending personal information offshore must meet Australian Privacy Principle 8.
• Vendor risk: APRA-regulated entities must assess a SaaS provider that supports a critical operation as a material service provider under CPS 230.

Replace demands the largest investment of the 7 Rs, so compare its total cost of ownership with rearchitecting before you commit.

Legacy Modernization Approaches Compared: Cost, Time, Risk and Value

Retire and retain cost the least, rehost is the fastest real change, and rearchitect and replace cost the most but remove the most technical debt. The table below compares the 7 Rs on six criteria, so you can see the trade-offs side by side. Costs and timeframes are indicative, for a single application.

Read the table with two trade-offs in mind. First, the cheapest options keep technical debt in place, so their costs return later as maintenance and rework. Second, high-risk options become manageable when you deliver them in phases and keep the legacy system running until each new part is proven.

How to Choose the Right Legacy Modernization Approach

Choose an approach for each system in two steps: score its business value and technical health, then match it to your main business driver. Most portfolios end up combining several Rs, and the order you apply them in matters as much as the choice itself.

Score Each System on Business Value and Technical Health

Start with Gartner’s TIME model, which places each system on a 2×2 grid. One axis measures business value and the other measures technical health. Each quadrant points to a short list of Rs:

• Tolerate (low value, good health): the system works but does not differentiate you. Retain it, or rehost it if the hardware is ageing.
• Invest (high value, good health): the system is a core asset in good shape. Retain it and refactor regularly to keep it healthy.
• Migrate (high value, poor health): the system matters but holds you back. Replatform, refactor, rearchitect or rebuild it.
• Eliminate (low value, poor health): the system costs more than it returns. Retire it, or replace it with SaaS.

Match the Approach to Your Main Business Driver

The TIME model narrows the options. Your main business driver picks between them. In Australian government, for example, agencies spend about 80% of their technology budgets running existing systems, which makes cost reduction the first driver for many teams.

Should You Combine Approaches?

Yes. Most successful programs apply two or three Rs to the same system over time. Two sequences are common:

• Rehost → refactor → rearchitect: move off failing hardware first, clean up the code once it runs in the cloud, then split it into services when the business needs scale.
• Retain → replace: keep a core system behind an API layer now, and build its replacement gradually.

Both sequences rely on the strangler fig pattern. New services take over one function at a time, and the legacy system shrinks until it can be switched off. Each phase delivers value on its own, and you never bet the business on a single cutover.

How AI Is Changing Legacy Modernization Approaches in 2026

AI lowers the cost of the 7 Rs that change code (refactor, rearchitect and rebuild), because it handles much of the analysis work that used to take months. The biggest shift is in understanding old code. AWS Transform, for example, analyzes COBOL and generates full documentation of the business rules, logic, processes and data structures inside it, a task that previously depended on the few engineers who still knew the system.

The impact differs by R:

• Refactor: AI tools explain undocumented functions, generate unit tests and suggest cleaner code patterns. This makes the “tests first” step faster and cheaper.
• Rearchitect: AI maps dependencies across a monolith and proposes service boundaries, which shortens the planning phase of a strangler fig project.
• Replace (rebuild): IBM’s watsonx Code Assistant for Z lets developers selectively translate COBOL applications into Java, so mainframe systems can be rebuilt in stages rather than rewritten all at once.

AI does not remove the need for engineering judgment. In 2026, the leading modernization tools build a behavioral model of the legacy system and continuously check the new code against it, because generated code is only useful once it is proven to behave like the original. Your team still validates business rules with domain experts, reviews every change, and confirms that source code sent to AI tools stays within your security and IP policies.

At Kaopiz, we combine AI development expertise with legacy engineering, so AI speeds up delivery without replacing human review.

Which Approach Fits Your Industry? Practical Examples

The right R depends less on your industry than on each system’s value, health and constraints, but industries do share common patterns. The scenarios below are illustrative. They show how Australian organizations typically combine the 7 Rs for one system in four sectors.

Two patterns stand out across these examples. First, systems that hold regulated data favor phased approaches, such as retain before rearchitect or replatform before refactor, because each phase can be proven before the next one starts. Second, commodity functions move to SaaS early, which frees budget and engineering capacity for the systems that set you apart.

How Kaopiz Helps Australian Businesses Modernize Legacy Systems

Kaopiz helps Australian businesses choose the right R for each system and deliver it in phases, without disrupting daily operations. Founded in 2014, we have nearly 1,000 staff, and we hold ISO 9001 and ISO 27001 certifications for quality and information security.

Every engagement follows three steps:

• Portfolio assessment: we score each system on business value and technical health, and map its dependencies.
• Approach per system: we recommend one or more of the 7 Rs for each system, with indicative cost, timeline and risk.
• Phased delivery: our engineers deliver each phase, from rehosting and replatforming to refactoring, rearchitecting and rebuilding. Our teams in Vietnam work three to four hours behind Sydney, which gives you real-time collaboration during business hours.

Not sure which approach fits each system? Talk to our architects and we will map your portfolio to the right Rs.

Conclusion

The best of the legacy modernization approaches is the one matched to each system’s business value, technical health and constraints. Retire and retain clear the low-value parts of your portfolio, rehost and replatform fix infrastructure fast, and refactor, rearchitect and replace remove technical debt where it matters most.

Most Australian organizations combine several Rs and deliver them in phases, so each step proves its value before the next one begins. Score your portfolio before committing budget, and let each system’s needs, not a single company-wide strategy, decide its path.

FAQs

Which Legacy Modernization Approach Is the Cheapest?

Retire is the cheapest approach, because it removes licensing, hosting and support costs instead of adding new spending. Retain has the lowest upfront cost, but technical debt and security risk grow over time. Among the approaches that actually change a system, rehost costs the least, though it leaves the code and its technical debt unchanged.

What Is the Difference between Refactoring and Rearchitecting?

Refactoring improves a system’s code without changing its structure or behavior, for example by splitting oversized modules and adding automated tests. Rearchitecting changes the structure itself, typically by breaking a monolith into microservices. Refactor when the code slows your team down, and rearchitect when the design limits scaling or independent releases.

Is Rehosting Enough to Modernize a Legacy System?

Rehosting alone is rarely enough. It moves a system to new infrastructure quickly, but the code, technical debt and integration gaps move with it unchanged. Treat rehosting as a first step, then replatform, refactor or rearchitect once the system runs in its new environment.

How Long Does Each Modernization Approach Take?

Retire and rehost take weeks to a few months per application, and replatform takes a few months. Refactoring runs over several months alongside feature work. Rearchitecting takes 6 to 18 months, and a full rebuild takes 12 months or more.

What Is the Strangler Fig Pattern in Legacy Modernization?

The strangler fig pattern replaces a legacy system gradually. New services take over one function at a time, and the old system shrinks until it can be switched off. It reduces risk because each phase delivers value on its own and avoids a single, high-stakes cutover.