Legacy system integration in 2026: the tail risk that makes wrapping the safer decision

One in six large IT projects overruns by an average of 200%, and the overruns follow a power law, so the average is useless for planning. That tail risk, not cost, is the real argument for an integration layer over a replacement.

The case for wrapping a legacy system rather than replacing it is not that wrapping is cheaper. Nobody can tell you that credibly, because no primary source publishes the ratio. The case is that replacement carries a tail risk that business cases do not model.

What the research on IT project overruns actually found

The average IT project overrun, and the one that matters

• Average cost overrun. 27%. Across 1,471 IT projects. The figure that gets quoted, and the least useful for planning.
• One in six projects. 200% cost overrun. Black swan outcomes, with schedule overruns of almost 70%. Follow-up work across 5,392 projects found the distribution follows a power law.

The stated mechanism: a problem in a single component leads to chain reactions in which other interdependent components are affected. That is what an integration layer avoids.

Source: Flyvbjerg and Budzier, Harvard Business Review, September 2011; Flyvbjerg et al., Journal of Management Information Systems 39(3), 2022.

A study of 1,471 IT projects found an average cost overrun of 27%. That figure gets quoted and it is the least interesting part. One in six projects was a black swan, with an average cost overrun of 200% and a schedule overrun of almost 70%.

Follow-up work across 5,392 projects established that these overruns follow a power-law distribution. In practical terms that means the average is close to meaningless as a planning figure, because extreme outcomes are far more likely than a normal distribution predicts. The researchers name the mechanism: a problem in a single component leads to chain reactions in which other interdependent components are affected.

That mechanism is exactly what an integration layer avoids, because the components stay where they are.

What running the old system costs

What running the old estate costs

Public sector auditors publish what private companies keep internal.

Source: US Government Accountability Office and UK Department for Science, Innovation and Technology.

Public sector auditors publish the numbers that private companies keep internal. The US federal government spends over $100 billion a year on IT with roughly 80% going to operations and maintenance. A 2025 review of 69 federal legacy systems identified 11 as critical, aged 23 to 60 years, with eight using outdated programming languages. The IRS Individual Master File is 60 years old, written in Assembly and COBOL, and its replacement has slipped nine years.

The UK review is blunter still: DWP and NHS England spend 70 to 85% of their technology budgets on upkeep, and the review put over £45 billion a year of unrealised benefit on the table, equal to 4 to 7% of public sector spend.

These are the numbers that make the status quo look expensive. They are also the numbers that make a replacement look attractive, which is where the tail risk comes back in.

What happens when a migration goes wrong

One documented example is worth more than a general warning. A UK bank's 2018 core banking migration resulted in regulatory fines totalling £48.65 million, affected a significant proportion of 5.2 million customers, ran from April to December, and cost £32.7 million in customer redress on top. The regulators cited inadequate planning, insufficiently robust governance, inadequate risk management and poor management of the third-party IT supplier.

Not a technology failure. A programme failure, of exactly the kind the power-law research predicts.

The honest case for wrapping

Two ways to get data out of a system you cannot change

• Replace the system. Unbounded risk. Tail risk that business cases do not model. Removes the debt. One in six programmes overruns by around 200%.
• Wrap it with an integration layer. Bounded risk. Known scope, system of record intact, reversible. Defers the replacement rather than removing it, and adds a layer to maintain.

Put plainly: wrapping buys time and optionality at a known cost. If the underlying system has a hard end of support date, it is a bridge and needs a plan at the far end.

Source: Thinklytics migration practice, 2026, against the Flyvbjerg overrun distribution.

We will not pretend this is free. Wrapping defers a replacement rather than removing the need for one, and it adds a layer someone maintains. If the underlying system has a hard end of support date, an integration layer is a bridge and needs a plan at the far end.

What it buys is a bounded risk in place of an unbounded one, a system of record left intact, and something that can be reversed. For an organisation whose last replacement attempt stalled, that difference is the whole conversation.

The regulation nobody mentions

DORA has applied across EU financial entities since 17 January 2025, covering twenty types of financial entity plus their ICT third-party providers, with obligations for risk management, resilience testing and major incident reporting.

That has a specific consequence for legacy estates. You now have to document and test the resilience of systems many firms have treated as untouchable black boxes. An integration layer creates an observable, testable boundary with logging and a defined contract. An undocumented mainframe creates a compliance problem you cannot evidence your way out of.

What we would do first

Pick the single process that most needs data out of the old system and trace it end to end. Not the whole estate, one process. What comes out, in what format, how often, and what breaks when it does not arrive. That is a fortnight, and it tells you whether you need an interface or a programme.

Our system consolidation practice does that tracing, and MuleSoft consulting covers the integration layer itself where that is the right answer. For the adjacent case of SAP estates specifically, see why S/4HANA migrations fail.

Frequently asked questions

Is it cheaper to wrap a legacy system or replace it?

There is no published cost ratio for this and anyone quoting one is quoting themselves. We looked specifically. What is documented is the risk profile of replacement. A study of 1,471 IT projects found an average cost overrun of 27%, but one in six was a black swan with an average overrun of 200% and a schedule overrun of almost 70%. Later work across 5,392 projects found the overruns follow a power-law distribution, meaning extreme outcomes are far more likely than a normal distribution would predict.

Why do legacy replacement programmes fail so badly?

Cascading failure across interdependent components. The researchers behind the power-law finding describe the mechanism directly: a problem in a single technological component leads to chain reactions in which other interdependent components are affected. That is precisely the risk an integration layer avoids, because it leaves the components in place rather than replacing them simultaneously.

What does running legacy systems actually cost?

Government auditors publish the clearest numbers. The US federal government spends over $100 billion a year on IT with approximately 80% going to operations and maintenance of existing systems. The UK's 2025 digital government review found DWP and NHS England spending 70 to 85% of technology budgets on upkeep rather than modernisation, and estimated over £45 billion a year of unrealised savings and productivity benefits, equal to 4 to 7% of public sector spend.

How old are the systems we are talking about?

Older than most people assume. A 2025 review of 69 federal legacy systems identified 11 as most critical, ranging from 23 to 60 years old. Eight of the eleven used outdated programming languages, and Treasury runs COBOL and Assembly with what the auditors described as a dwindling number of people available with the skills. The IRS Individual Master File is 60 years old and its replacement has been delayed nine years.

What is the strongest argument for wrapping rather than replacing?

That it converts an unbounded risk into a bounded one. A replacement programme carries tail risk that conventional business cases do not model. An integration layer has a known scope, leaves the system of record intact, and can be reversed. It also creates an observable, testable boundary around a system that may have been treated as an untouchable black box, which matters under operational resilience rules.

Does this create technical debt we pay for later?

Yes, and that should be stated openly rather than argued away. Wrapping defers a replacement rather than removing the need for one, and it adds a layer to maintain. The honest framing is that it buys time and optionality at a known cost, against a replacement that carries tail risk at an unknown one. If the underlying system has a hard end of support date, wrapping is a bridge and needs a plan at the other end.

What regulation is pushing this now?

Operational resilience rules. DORA has been in application across EU financial entities since 17 January 2025, covering twenty types of financial entity plus their ICT third-party providers, with obligations for risk management, resilience testing and major incident reporting. That requires firms to document and test systems many have treated as black boxes for twenty years. An integration layer gives you an observable boundary. An undocumented mainframe does not.