Legacy modernisation strategies: the 7 Rs and how to choose

Why modernise, and why not all at once

A legacy system is rarely a problem because it is old. It becomes one when every change is slow and risky, when the people who understood it have left, when it can’t be patched or scaled, or when it blocks something the business needs, such as an integration, a new channel or AI built on its data.

The cost of standing still is easy to underestimate because it is spread across years of budgets. Public-sector audits make it visible:

• The US federal government spends more than $100 billion a year on IT, and agencies “have typically reported spending about 80 percent on operations and maintenance of existing IT” (GAO, July 2025).
• The same review found the 11 federal systems most in need of modernisation were about 23 to 60 years old and cost about $754 million a year to operate and maintain; eight use outdated languages and seven run with known cybersecurity vulnerabilities. Of the 10 critical systems GAO flagged in 2019, three had been modernised by February 2025.

The obvious response, rewriting everything at once, is also the riskiest. A full rewrite has to reproduce years of business rules, many of them undocumented, before it delivers any value, while the old system keeps changing underneath it. Martin Fowler describes the trap: “Replacements seem easy to specify, but often it’s hard to figure out the details of existing behavior. What’s worse, much of that behavior is stuff that isn’t really wanted, so building it is a waste.” His Thoughtworks colleagues, the authors of Patterns of Legacy Displacement, describe organisations “stuck on a treadmill of half-done legacy replacement efforts”.

The strategies below exist so you can choose a different route for each part of the estate, and deliver value along the way.

The 7 Rs of modernisation

The “Rs” started as Gartner’s five ways to move applications to the cloud and grew to seven in AWS’s migration guidance: AWS’s Stephen Orban described six strategies in 2016, building on “the 5 R’s that Gartner outlined here in 2011”, and AWS’s current guidance lists seven. They are useful beyond the cloud, as a vocabulary for deciding what to do with each system:

AWS itself calls refactoring “the most complex and costly of the migration strategies” and, for large migrations, recommends moving first and modernising after. Microsoft’s Cloud Adoption Framework, which used to describe “five Rs of rationalization”, now lists eight strategies (retire, retain, rehost, replatform, refactor, rearchitect, rebuild and replace) and adds a warning worth repeating: “Don’t rehost problematic workloads. Rehosting doesn’t resolve existing performance, reliability, or architectural issues.” The labels matter less than the habit: decide per system, on purpose, instead of applying one strategy to everything.

How to choose, system by system

Start with an inventory: every application, what it does, who uses it, what it connects to and what it costs to run. Then place each one on two axes.

• Business value: how much revenue, operations or customer experience depends on it, and whether it is part of how you compete.
• Technical health: how safely it can be changed, whether it is supported and patched, how well it is documented and tested.

Then test the shortlist against the questions that usually decide it:

• Is there a deadline, such as an expiring data-centre lease, an end-of-support date or a regulation?
• Does the system hold business rules nobody has written down? (Then plan time to recover them, whatever the strategy.)
• Would a commercial product cover most of it without bending your process out of shape?
• Who will run the result, and do they have the skills?

The strangler fig: replacing a system piece by piece

For the systems that need re-architecting, the safest route is usually incremental. Martin Fowler named the approach after the strangler fig, a plant that grows around a host tree until it can stand on its own. “Like the fig, it begins with small additions, often new features, that are built on top of, yet separate to the legacy code base. As we do this we move bits of behavior from the legacy system into the new code base.” In his original 2004 note he gave the main reason to prefer it: “The most important reason to consider a strangler fig application over a cut-over rewrite is reduced risk.”

In practice it works like this:

1. Put a seam in front of the old system. A proxy, API gateway or routing layer that every request passes through, so traffic can be redirected without users noticing.
2. Pick one capability to move. Ideally one with clear boundaries and real value: a report everybody waits for, a slow checkout step, an integration that breaks every month.
3. Build it new, and keep the data consistent. The new service and the old system often have to share or synchronise data for a while; this is usually the hardest part.
4. Switch traffic over gradually, behind a feature flag, comparing results with the old path, with a way back if something is wrong.
5. Remove the old code for that capability, then pick the next one.

The temporary code that makes this possible (adapters, synchronisation jobs, routing rules) is work you throw away later. The Patterns of Legacy Displacement authors call it transitional architecture: “Software elements installed to ease the displacement of a legacy system that we intend to remove when the displacement is complete.” Fowler’s verdict on the cost: “While this may appear to be a waste, the reduced risk and earlier value from the gradual approach outweigh its costs.”

Data is usually the hard part

Code can be rewritten; years of data, with its quirks and the reports people rely on, has to be carried across intact. Treat migration as a project of its own:

• Map and profile the data before designing the new model: duplicates, missing values, fields used for something other than their name.
• Rehearse. Migrate a sample, then a full copy, as many times as it takes for the run to be routine.
• Reconcile. Compare counts, totals and spot checks between old and new, and have the people who own the data sign them off.
• Run in parallel where the risk justifies it, so the old system remains the record until the new one has been proven.

A roadmap that survives contact with reality

A modernisation plan that works tends to have the same shape, whatever the technology:

1. Assess (two to three weeks). Inventory, interviews, a look at the code, the infrastructure and the data; a strategy per system and a sequenced roadmap.
2. Make change safe. Before moving anything: automated builds and deployments, monitoring, and tests around the behaviour you are about to change.
3. Deliver one slice. Move or rebuild the first capability end to end, including data and cut-over, to prove the route and the tooling.
4. Repeat, and retire. Each slice should switch something off. If old systems never get decommissioned, the estate only grows.

This is how our technology consulting and modernisation work runs: usually a two-to-three-week assessment, then a phased roadmap delivered in increments, using strangler fig, parallel runs and feature flags so parts of a system move one at a time and can be rolled back.

Where AI helps, and where it doesn’t

AI coding assistants have changed parts of modernisation work, mostly the reading and the first drafts:

• Understanding code. Summarising unfamiliar modules, tracing where a field is used, drafting documentation for code nobody has documented.
• Writing characterisation tests that pin down what the old code actually does today, which is exactly the safety net a migration needs.
• Drafting translations between languages or frameworks, as a starting point for an engineer.

What they don’t change is the need for evidence. Generated code and generated explanations can be confidently wrong, especially about undocumented business rules. Every change still needs tests, review by someone who understands the domain, and the same incremental cut-over as before.

Mistakes to avoid

• A big-bang cut-over with no way back. Plan every switch so it can be reversed.
• Lift-and-shift, then expecting savings. Rehosting moves the costs; it rarely removes them without further work.
• Modernising without tests. If you can’t tell whether behaviour changed, you can’t tell whether the migration worked.
• Leaving data to the end. Data problems found in the last month become the delay.
• Never switching anything off. Value comes from retiring the old system, not from running two.

If you’re weighing whether to replace a system with a product instead, our build vs buy framework covers that decision in detail.

Sources

Every source below was read on 26 October 2026. Prices and product details change; check the current page before relying on a figure.

1. US Government Accountability Office: Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems (GAO-25-107795)
2. Amazon Web Services: About the migration strategies (AWS Prescriptive Guidance)
3. Amazon Web Services: 6 Strategies for Migrating Applications to the Cloud (Stephen Orban)
4. Microsoft Learn: Select your cloud migration strategies (Cloud Adoption Framework)
5. Martin Fowler: Strangler Fig
6. Martin Fowler: Original Strangler Fig Application
7. Ian Cartwright, Rob Horn, James Lewis: Patterns of Legacy Displacement
8. Ian Cartwright, Rob Horn, James Lewis: Feature Parity
9. Ian Cartwright, Rob Horn, James Lewis: Transitional Architecture