Most legacy systems aren’t just inefficient. They’re quietly costing the business six or seven figures a year.
The problem is, no-one has quantified it.
Instead, legacy estates are discussed in technical terms:
- brittle architecture
- slow releases
- hard to maintain
All are true. None of it gets funded.
Boards don’t invest in ‘cleaner architecture’. They invest in reduced risk, faster revenue, lower operating cost and stronger future capability.
If you can’t put a number on your tech debt, you can’t make the case to fix it.
Legacy systems don’t fail. They accumulate cost
Legacy systems rarely fail all at once. They erode capability over time.
Releases take longer. Integrations become riskier. Senior engineers spend more time protecting fragile services than building new value. Incidents become normalised and manual workarounds multiply.
What looks like an IT inefficiency is actually something more serious – a growing, off-balance-sheet liability.
McKinsey & Company describes technical debt as accumulated work that must be done in the future. Its research suggests:
- 10–20% of new product budgets are diverted to tech debt
- tech debt can represent 20–40% of the total technology estate value
That’s the reframing. Legacy systems aren’t just ageing assets. They are ongoing financial drag.
Why most modernisation business cases fail
Most modernisation proposals start in the wrong place.
They focus on the cost of change:
- migration cost
- delivery teams
- platform investment
- transition risk
But that only answers half the question. The real decision is – what is the cost of doing nothing?
If the organisation keeps the current estate for the next 12 – 36 months:
- How much engineering capacity is lost?
- How many initiatives are delayed?
- How many incidents repeat?
- What risk remains unmanaged?
Until that is quantified, modernisation looks like a cost. Once it is quantified, it becomes a financial decision.
The bridge between technical pain and financial impact
To make the case, technical symptoms need to be translated into commercial outcomes.
| Technical symptom | Financial translation |
| Slow releases | Delayed revenue, delayed cost savings or delayed service improvement |
| Repeated incidents | Downtime cost, recovery effort, SLA exposure and customer impact |
| Manual workarounds | Labour cost, process inefficiency and higher error rates |
| Legacy dependencies | Scarce skills, supplier risk and higher maintenance cost |
| Poor integration | Missed automation, duplicated effort |
| Unsupported platforms | Security, audit and compliance exposure |
This is the point where the business case either works or fails. The conversation shifts from ‘We should modernise’ to ‘This estate is costing £X per year and increasing risk’.
Where legacy cost actually shows up
In practice, legacy drag typically appears in three places:
- Lost time (engineering effort, delays, inefficiency)
- Lost money (missed revenue, wasted spend)
- Increased risk (incidents, compliance exposure, operational instability)
The job is to quantify each of these in financial terms.
The four cost categories most organisations miss
-
Opportunity cost (usually the largest)
Opportunity cost is the value the business should already be realising, but isn’t.
Legacy systems don’t just slow delivery. They delay revenue, defer savings and block initiatives that have already been approved.
Examples include:
- delayed product launches
- postponed integrations
- missed upsell or renewal windows
- blocked automation initiatives
A typical scenario:
A new digital service is expected to generate £1M annually. Launch is delayed by 6 months due to legacy integration constraints.
That delay alone costs £500,000.
Calculation: Opportunity cost = monthly value × months delayed
-
Incident cost
Legacy estates create recurring incident patterns:
- fragile batch processes
- failed releases
- manual interventions
- prolonged recovery times
Even when they don’t hit headlines, they still carry cost.
Measure:
- number of incidents
- time to resolve
- number of people involved
- lost transactions or downtime
- support and SLA impact
Calculation: Incident cost = incidents × hours × blended cost + business impact
The Consortium for Information & Software Quality estimated the cost of poor software quality in the US at $2.41 trillion in 2022, with $1.52 trillion attributed to technical debt.
The principle is simple. Poor systems create measurable economic loss.
-
Talent cost (often under-estimated)
Legacy systems don’t just consume time. They degrade engineering effectiveness.
Common patterns include:
- senior engineers maintaining instead of building
- slow onboarding for new hires
- increased attrition risk
- higher salary premiums for niche legacy skills
This creates two direct costs:
- Capacity loss (time spent on maintenance)
- Capability loss (reduced ability to deliver new value)
If senior engineers are spending 30–40% of their time maintaining legacy systems, you are effectively paying senior rates for low-value work.
Calculation: Talent cost = hours spent on legacy work × blended engineering rate
-
Compliance and security risk (often ignored)
Compliance risk is often excluded because it hasn’t materialised yet. That’s a mistake.
Legacy systems frequently introduce:
- unsupported components
- weak audit trails
- manual controls
- fragmented data flows
This creates exposure to:
- regulatory fines
- audit failure
- delayed deals due to compliance gaps
- reporting inaccuracies
The goal is comparability, not certainty.
Calculation: Compliance exposure = likelihood × impact
A practical tech debt model in financial terms
At its simplest, every legacy estate can be reduced to five cost drivers: The right approach depends on which cost dominates.
Annual legacy cost =
- incident cost
- opportunity cost
- talent cost
- compliance risk
- infrastructure waste
This turns technical debt into something the board can evaluate.
A practical tech debt calculator for CTOs
Start with known costs, then model recurring operational drag and risk-weighted exposure.
| Cost area | What to measure | Calculation |
| Incident cost | Outages, war-room time, failed transactions | incidents × hours × cost + business impact |
| Opportunity cost | Delayed initiatives, product releases | monthly value × delay |
| Talent cost | Time spent maintaining or working around legacy systems | hours × engineering rate |
| Compliance risk | Unsupported systems, audit gaps, security exposure | likelihood × impact |
| Infrastructure waste | Hosting, licensing, support, duplicated tools | avoidable annual spend |
Build a CFO-ready view (not false precision)
The goal is not perfect accuracy. It’s a credible financial range that finance can work with.
Produce three scenarios:
| Estimate | What it includes |
| Low | Known measurable costs only |
| Mid | Known costs + recurring operational drag |
| High | Full cost including risk and opportunity |
The output: Current annual cost of legacy drag: £X – £Y
From there, compare it against the cost of stabilisation, migration, modernisation or replacement. That creates a board-level decision – is the cost of doing nothing still acceptable?
What this looks like in practice
In one Catapult CX engagement, a global mobile network provider had consolidated multiple critical systems into a single platform, creating severe instability and performance issues.
Catapult CX stabilised and simplified the platform through targeted optimisation and architectural improvements.
The results were measurable:
- 243 trading hours recovered per week
- message failures reduced from 12% to 0.3%
- billing system performance increased by more than 1000x
- CRM performance improved by 30%
- release outage window reduced from 21 days to 30 minutes
- 42 physical machines freed up
This shifted the platform from a cost centre causing operational drag to a stable foundation supporting growth.
Read the full case study on consolidating multiple legacy systems
Modernise, migrate or replace? Use the numbers to decide
Not every legacy system should be replaced. The right decision is not technical. It depends on which cost is highest.
| Dominant cost driver | Recommended approach |
| High incident + talent cost | Modernise and stabilise |
| High infrastructure + compliance cost | Migrate |
| High opportunity cost (blocking growth) | Replace |
| High risk, low change tolerance | Wrap |
| Uncertain value | Minimum viable replacement |
This reframes the decision from ‘What should we do technically?’ to ‘Which option reduces the highest financial drag with the lowest risk?’
CTO checklist. Building the business case
A strong case should:
- quantify annual legacy cost
- show cost of inaction over 12 – 36 months
- highlight risk across incidents, compliance and delivery
- compare intervention options (not just replacement)
- phase value (early wins matter)
- show payback period
If legacy drag costs £750,000 per year and a phased programme costs £500,000, the decision becomes straightforward.
Explore Legacy System Modernisation
Quantify the cost before you modernise
Legacy systems don’t need to be emotional arguments.
The strongest case for modernisation is financial:
- what the estate costs today
- what risk it carries
- what value is being delayed
But many organisations stay with the status quo because the path away from technical debt feels unclear or high risk. Replatforming, migration and replacement programmes can seem more disruptive than maintaining the existing estate.
That is why modernisation needs to be approached incrementally and pragmatically. The goal is to reduce technical debt and operational risk through controlled, measurable change.
If you can’t quantify your legacy cost today, you’re making decisions without the full picture.
Catapult CX helps CTOs define that number, build the business case and reduce legacy drag through practical, risk-controlled modernisation.
FAQs about legacy software modernisation and tech debt
What is legacy software modernisation?
Legacy software modernisation is the process of improving, migrating, wrapping or replacing older systems so they can support current business needs.
How do you calculate the cost of technical debt?
Estimate the annual financial impact of:
- incidents
- delayed delivery
- manual workarounds
- talent drag
- compliance risk
- infrastructure waste
A practical model is: Annual legacy cost = incident cost + opportunity cost + talent cost + compliance risk + infrastructure waste
How do you start quantifying tech debt if you don’t have perfect data?
Start with the data you already have:
- incident logs
- engineering time allocation
- delayed project timelines
- infrastructure and licensing costs
You don’t need precision. A credible estimate based on known data and reasonable assumptions is enough to build a business case. The model can be refined over time.
How accurate does a tech debt calculation need to be?
It does not need to be exact. The goal is to produce a defensible range that shows the scale of the problem.
Boards are used to working with scenarios and ranges. A structured estimate is more useful than a precise but incomplete number.
How do you present tech debt to the board or CFO?
Frame it as a financial issue, not a technical one.
Focus on:
- annual cost of inaction
- risk exposure
- comparison of intervention options
- expected payback period
Avoid technical language. The discussion should be about cost, risk and return.
What is the typical payback period for legacy modernisation?
It varies by scope, but many programmes begin delivering measurable returns within 6 – 12 months through:
- reduced incidents
- faster delivery
- lower support overhead
Phased approaches typically shorten time to value.
What are the hidden costs of legacy systems?
Common hidden costs include:
- delayed initiatives
- recurring incidents
- manual processes
- scarce skills
- duplicated effort
- compliance exposure
- reduced engineering productivity
These rarely appear in budgets but materially affect performance.
When should a legacy system be modernised instead of replaced?
Modernise when the system still has value but limits change, integration or scale. Replace when it structurally blocks growth, resilience or customer experience. Migrate when the issue is primarily platform, hosting or data location.
When should you not modernise a legacy system?
Not all systems justify modernisation. Avoid major investment when:
- the system is nearing end-of-life
- business value is low or declining
- the cost of change outweighs the benefit
In these cases, containment or gradual replacement is often more appropriate.
