Extend Legacy Systems Before You Replace Them

The Decision in Front of You

Somewhere in your company there is a system everyone complains about and nobody can turn off. It might be an order platform written twenty years ago, a heavily customized ERP, or a billing engine whose original authors have retired. A vendor, a consultant or your own team has proposed replacing it.

The choice on the table looks binary: keep paying to run the old thing, or fund a new one. A third option usually costs less and carries less risk. Keep the old system running, make it understandable, wrap it so new work can be built around it, and retire it in stages.

The stakes are large. US federal agencies report that about 80% of their IT spending, which exceeds $100 billion a year, goes to operating and maintaining existing systems ¹. Private companies carry the same pattern on a smaller scale. The money is already committed to the old system. The decision is whether the next dollar buys a bet on a replacement or buys steady improvement on something that already works.

What's Happening

Old systems are expensive, and that part is true

The case against legacy systems is real. In July 2025 the US Government Accountability Office reviewed 69 federal legacy systems and singled out 11 as most in need of modernization. Those 11 range from 23 to 60 years old and cost about $754 million a year to operate and maintain ¹². Eight of them use languages such as COBOL and assembly, and GAO notes a dwindling pool of people with the skills to support them ². Seven have known security vulnerabilities that cannot be fixed without modernization ².

GAO ran a similar exercise in 2019 and found the same pattern: outdated languages, unsupported hardware and missing modernization plans ³. Six years later, two of the 11 systems in the 2025 review still had no modernization plan at all, and only three had plans with milestones, a description of the work, and a plan for retiring the old system ¹².

Replacements fail in expensive and public ways

GAO's own background material shows how hard full replacement is. The Department of Veterans Affairs abandoned three attempts to replace its health records system after 2001, citing planning problems, high costs and long timelines. Its fourth attempt, begun in 2017, paused deployments in April 2023 ².

The private sector has its own recent examples.

Lamb Weston, 2024. The frozen potato maker moved its North American systems to a new ERP at the start of its fiscal third quarter. The company reported that the transition cut net sales by about $135 million in that quarter and reduced net income by about $72 million after tax ⁴. Of a $95 million hit to adjusted EBITDA, about $55 million came from orders it could not fill ⁴. It lowered its full-year sales guidance at the same time, citing the ERP impact along with weaker restaurant traffic ⁴.

Zimmer Biomet, 2024 and 2025. The medical device maker went live on a new SAP system in North America on July 4, 2024. In a lawsuit filed in September 2025, it alleges that it could not ship or receive product, issue invoices, or produce basic sales reports through the third quarter of 2024 ⁵. It claims more than $172 million in damages, and says implementation fees grew from an agreed $69 million to $94 million ⁵⁶. Deloitte, the implementer, denies the claims and has moved to dismiss; the case was unresolved at the end of 2025 ⁶.

Birmingham City Council, 2022 to 2026. England's largest local authority replaced a 1999 SAP system with Oracle Fusion and went live in April 2022. Its external auditor reported in February 2025 that the project would cost at least £90 million more than budgeted, and that the council would not finish reimplementing the system until 2026 or later ⁷. The auditor found the go-live risk was poorly understood and that the program had customized the new system to mirror old processes ⁷. The old SAP system had cost about £5.1 million a year to run ⁷.

The Post Office: a rewrite that became a five-year extension

The UK Post Office case shows how a replacement program turns into the most expensive way to keep a legacy system alive.

The Post Office set out to replace its Horizon branch system, in service since 1999, with an in-house build called New Branch IT. The budget grew from £180 million to £1.1 billion, and the target date slipped from 2025 to as late as 2030 ⁸. A 2024 government review rated the program "currently unachievable," citing weak governance, poor code quality, low test coverage and a team without large-scale delivery experience ⁹. Reviewers also found the program had been framed as a copy of Horizon instead of a business change with clear outcomes ⁹.

In May 2025 the Post Office dropped the in-house build and opened a £492 million procurement for outside suppliers ¹⁰. Meanwhile it kept extending the old contract: a one-year extension to March 2026 cost £63 million, bringing the total value of the Horizon contract since 1999 to £2.44 billion ¹¹.

Why the Usual Approach Fails

Rewrites fail for reasons that have little to do with the technology chosen.

Start with the specification. The old system is the specification. Twenty years of edge cases, regulatory fixes and customer workarounds live in its code and nowhere else. A team that sets out to copy it has to rediscover all of that, usually by breaking something in production. Birmingham and the Post Office both fell into this trap, rebuilding old processes in new software ⁷⁹.

Value also arrives late. A rewrite delivers nothing until cutover, so the business funds years of spending with no return and no early signal of whether the program is on track. GAO notes that missing or incomplete plans raise the risk of overruns, delays and outright failure ³. When the bad news arrives, it arrives all at once, close to go-live.

Culture compounds both problems. Large programs build momentum, and people stop reporting problems. Birmingham's auditor described a culture in which bad news was unwelcome or hard to raise ⁷. The Post Office review found leadership and the delivery team did not trust each other ⁹.

None of this means old systems should run forever. GAO's central recommendation is that agencies write modernization plans with milestones and a disposition plan for the old system ¹. GAO is asking for a retirement schedule, which can be met one capability at a time.

The Framework: The Extend-First Ladder

The Extend-First Ladder treats the legacy system as a working asset and climbs toward retirement one step at a time. Each rung delivers value on its own, so the program can stop at any rung without wasting what was spent.

flowchart LR
    A[Document<br/>what the system<br/>actually does] --> B[Wrap<br/>stable interface<br/>around it]
    B --> C[Extend<br/>new features<br/>outside the core]
    C --> D[Replace<br/>one capability<br/>at a time]
    D --> E[Retire<br/>funded plan<br/>with a switch-off date]

Document. Write down what the system does, who depends on it, and which business rules live only in its code. Capture its inputs and outputs in automated tests that record today's behavior. This is the cheapest risk reduction available, and every later step depends on it.

Wrap. Put a stable interface in front of the system, usually an API layer, so other systems talk to the interface instead of to the old code directly. New channels, reports and partners connect to the wrapper. The old system stops being a bottleneck for every new project.

Extend. Build new capability outside the core: a customer portal, an analytics feed, an AI assistant that reads the system's data. The business gets new features this quarter without touching the riskiest code.

Replace. When a specific capability justifies it, rebuild that capability behind the wrapper and route traffic to the new version. This is the strangler fig pattern, named by Martin Fowler after a vine that grows around a host tree until the tree is no longer needed ¹². AWS's guidance describes it in three steps: build the new component, run it alongside the old one with the old one kept for rollback, then remove the old function once traffic has moved ¹². AWS also notes its limits. It does not suit small, simple systems, it needs a place where requests can be intercepted, and the routing layer must be designed so it does not become a single point of failure ¹².

Retire. Once most capability has moved, fund the switch-off as its own project with a date, an owner and a budget. GAO's three plan elements apply directly: milestones, a description of the work, and a disposition plan for the old system ¹.

What the two paths cost

The following is an illustrative model for a hypothetical mid-size distributor whose order platform costs $1.2 million a year to run. Substitute your own figures.

The ladder does not finish retirement inside three years, and the table says so. Its advantage is that money starts returning value in the second quarter, each step is small enough to stop, and the company never has to bet the business on a single go-live weekend.

Costs, Risks, and Tradeoffs

Extending first is cheaper in most cases. It is also slower to reach a fully modern estate, and it can become an excuse to never finish.

How to Act

Questions to Ask Your Team

1. What does each of our oldest systems cost to run each year, including staff and contractors?
2. Who understands the business rules inside it, and what happens if they leave?
3. Do we have automated tests that describe what the system does today?
4. Could we put an interface in front of it so new work stops touching the old code?
5. What is the smallest piece of it we could replace first, and what would that return?
6. In our replacement business case, how many months of double running did we assume, and what happens to the case if that doubles?
7. Is there a written plan, with a date and an owner, for switching the old system off?
8. When was the last time someone on this program raised bad news, and what happened?

Closing

A working legacy system holds years of business knowledge that no requirements document captures. Rewriting it from scratch puts that knowledge, and the company's cash, at risk on a single go-live. Document the system, wrap it, extend it at the edges and replace it a capability at a time. Fund its retirement as a real project with a date. The company keeps earning from the old system while the new one proves itself, and the board can measure progress every quarter.