The Hidden Cost of Keeping Your Legacy ERP Running

For: A COO or CIO at a UK mid-market enterprise (£50M–£500M revenue) running a 10-to-15-year-old ERP — SAP ECC, Sage 200, or a bespoke .NET system — whose vendor has issued an end-of-mainstream-support notice and whose finance director is asking why the IT budget keeps growing without visible output

The honest answer to your CFO's question is this: doing nothing is not the cheap option, it is the option whose cost is hidden across four line items — extended-support surcharges you already pay, headcount absorbed by workarounds that never appear on the IT budget, HMRC and ICO exposure on an unpatched estate, and enterprise deals your integration layer cannot close. Once you total those, modernisation stops looking like capital spend and starts looking like the cheaper of two operating models. This post gives you the argument, the numbers to anchor it, and a sequencing plan that phases the spend so the first increment pays for the next.

The four buckets of the cost of doing nothing

A credible legacy ERP modernisation business case does not start with the cost of the new system. It starts with the fully-loaded cost of the current one — the number your finance director does not have because it is scattered across five cost centres. There are four buckets. Add them honestly.

1. The vendor surcharge you are already paying (or about to)

If you are on SAP ECC, the clock is explicit. Mainstream maintenance ends 31 December 2027, and SAP's CEO has publicly confirmed there will be no further deadline extensions. After that, SAP offers Extended Maintenance at an additional 2% of the annual maintenance fee on top of the standard 22% Enterprise Support rate, which Crowe calculates translates to a total cost increase of 9–12% once SAP's annual index-linked increases of up to 5% are stacked on top.

Worse, if you are on ECC EHP 0–5, you are already past the cliff — those versions lost mainstream support on 31 December 2025 with no extended maintenance option available. You are in Customer Specific Maintenance: no regular support, no legal updates, only limited security updates. That is not a supported platform; it is a paid observation.

Translate this for your CFO in one line: every year you defer, the vendor bill goes up by a known percentage on a platform with a known end date. This is not speculative. It is a contractual escalator on depreciating value. Sage 200 and bespoke .NET estates do not have SAP's dated timetable, but the pattern rhymes — third-party support, .NET Framework version deprecation, and Windows Server end-of-life dates all create the same escalator on a different clock.

2. Headcount absorbed by workarounds

This is the bucket finance never sees because it is hidden inside operational salaries. The month-end close that takes three people four days because journals move by spreadsheet. The AR clerk who re-keys invoices between the ERP and the customer portal. The two developers who exist only to maintain the crumbling integration between the ERP and the WMS.

Gartner puts a shape on it at the aggregate level: technical debt now consumes an estimated 40% of average IT budgets, climbing to 60–80% in enterprises running significant on-premises infrastructure. In practice, if your IT run-rate is £4M and your organisation looks like the second cohort, £2.4M–£3.2M of that is going to keep the lights on rather than build anything new.

Do the audit before the meeting. Pick your five most painful monthly processes. Count the human hours per month, multiply by loaded cost, annualise. That number goes on the slide.

3. Regulatory and audit exposure

This is the bucket that has changed most sharply in the last eighteen months, and the one CFOs under-weight because the exposure is probabilistic. It should not be.

On UK GDPR: the ICO issued £19.6 million in fines across just seven cases in 2025 — a sevenfold increase in value over 2024, with two-thirds of H1 2025 fines related to UK GDPR breaches, up from one-sixth in 2024. The Advanced Computer Software Group case is the precedent that matters most for legacy estates: the ICO found that known vulnerabilities were left unpatched and MFA was not implemented. Running an ERP the vendor no longer patches is now a documented aggravating factor in regulatory action, not a technicality.

Maximum UK GDPR fines reach the higher of £17.5 million or 4% of total annual worldwide turnover. You do not need to price the worst case to make the point — you need to price the probability-weighted case honestly and get it on the risk register.

On HMRC Making Tax Digital: the late payment regime effective from April 2025 charges 3% of outstanding tax at day 15, a further 3% at day 30, and 10% per annum from day 31 — with the day-15 and day-30 rates rising from 3% to 4% from April 2027. If your ERP-to-HMRC filing path is a fragile bridge held together by a monthly Excel export, you are one broken integration away from a penalty that compounds monthly. This is not a hypothetical. Ask your finance team how many MTD submissions in the last twelve months required manual reconciliation.

None of the above is legal advice — your general counsel or auditor needs to review the specifics of your data processing and filing obligations. But the pattern is directional and clear.

4. Revenue the system blocks

This is the bucket the CFO understands fastest because it is denominated in lost deals. Enterprise buyers now put API and data requirements in RFPs as gating criteria: real-time inventory endpoints, webhook-based order status, SSO via SAML or OIDC, SOC 2 evidence for data handling. If your ERP's integration layer is a nightly batch to a flat file, you are being disqualified in the first vendor screen and never told why.

Quantify it. Ask sales for the last twelve enterprise opportunities lost and mark which ones died on technical evaluation. That is a revenue number, not an IT number, and it belongs on the same slide as the surcharge.

Why the total is always bigger than you think

When you add the four buckets, the total is systematically higher than intuition suggests. Deloitte's 2024 Banking Survey found actual legacy TCO runs 3.4× higher than initial estimates — a mid-sized European bank budgeting €2M/year for core system costs discovered the true figure was €6.8M once compliance overhead, integration friction, and innovation drag were included. Banking is not identical to your business, but the multiplier is a useful challenge to the number your team first offers.

The other direction of asymmetry: McKinsey data shows companies that address technical debt systematically achieve 20–40% productivity gains, and Gartner finds organisations that ignore it spend up to 40% more on maintenance than peers who address it early. The gap between the two trajectories widens every quarter you defer.

Sequencing: strangler-fig vs big-bang

Once the case for action lands, the next question is how. There are two credible paths, and choosing between them is where most business cases go wrong.

Big-bang replacement

Rip out the ECC or the .NET monolith, put in S/4HANA or a modern equivalent, cut over in one weekend. This is the model most system integrators pitch because it is easier to scope and price.

What it is good at: a clean data model at the end, no long period of running two systems, a single vendor accountable for the outcome.

What it is bad at: risk concentration. Panorama Consulting research consistently finds that 50–75% of ERP projects exceed their originally approved budget, with the average overrun at 24–30%. Big-bang programmes carry the whole overrun in one hit, and the failure mode is a cutover weekend that becomes a cutover quarter. If your revenue depends on the system being up on Monday, this is a governance problem, not a technical one.

Strangler-fig increments

Coined by Martin Fowler and now standard practice in serious modernisation work. You leave the legacy system running, put an API façade in front of it, and replace one bounded capability at a time — customer master, then order capture, then invoicing — routing traffic through the new services as they come online. The old system shrinks each quarter until it is a shell, then it goes.

What it is good at: risk is spread across increments. Each increment has its own business case, its own payback, and its own go/no-go. You can pause after any increment without stranding the investment. The first increment — usually the integration façade itself — often pays for the second by unblocking two or three of the enterprise deals from bucket four.

What it is bad at: longer total elapsed time. You run two systems in parallel for a period, which means dual data governance and dual operational cost. It requires a product-led delivery culture your organisation may not yet have. And the API façade layer is real engineering work that has to be got right — a leaky façade is worse than no façade.

For a UK mid-market enterprise on SAP ECC with an unmoveable 2027 clock, the honest recommendation is a strangler-fig with a defined backstop: increments start now, the façade goes in first, and you contract with the vendor for extended maintenance as a paid insurance policy against the increments running long. You are not choosing between the two models — you are using extended maintenance to buy the runway to do strangler-fig properly.

What the business has to supply

Modernisation programmes fail on the business side more often than the technical side. Before you commission anyone — us, a Big Four, an SI — the following must exist inside your organisation:

• A single accountable executive. Not a steering committee. One name, usually the COO or CFO, whose bonus is tied to the outcome.
• Process owners for each capability being migrated. Finance owns the close, ops owns fulfilment, sales owns the quote-to-cash. IT cannot own business processes on behalf of the business.
• A data cleansing commitment. Every legacy ERP has fifteen years of accumulated master data debt — duplicate customers, dead SKUs, unreconciled GL codes. This does not migrate. Cleansing is a business activity, not a technical one, and it needs headcount ring-fenced.
• A tolerance for parallel running. The finance team will close the books in two systems for two quarters. Say so up front.

Phasing the spend so the first increment funds the next

The CFO-friendly way to structure the programme is to make each increment self-funding on a rolling twelve-month basis. In practice this means the first increment targets the bucket with the fastest payback — usually a mix of bucket two (kill the highest-cost workaround) and bucket four (unblock the highest-value stalled deal).

Illustrative example, all assumptions stated: a UK manufacturer with £120M revenue, £400K annual ECC support, three FTEs absorbed by month-end workarounds at a loaded cost of £75K each, and two enterprise deals worth £1.8M ARR stalled on API requirements. Increment one is the integration façade plus a modern order capture service, sized at a mid-six-figure capital spend. If it unblocks one of the two deals and eliminates two of the three FTE workarounds, the twelve-month payback is inside the increment cost before the extended-support surcharge is even counted. This is illustrative — your numbers will be different, and the shape of the payback depends heavily on which capability you pick first.

The specifics that turn any of this from a range into a real quote are: the scope of the first increment (which capability, how many integrations), the state of your master data (cleanse effort dominates smaller programmes), and your regulatory footprint (MTD complexity, data residency, sector-specific rules like FCA or MHRA). Those three variables move the number more than anything else.

How CodeNicely can help

We do this work as an AI-first legacy modernisation practice, and the most relevant reference for a UK mid-market ERP situation is our engagement with GimBooks, a YC-backed accounting SaaS serving Indian SMBs. The parallel is not the sector — it is the pattern: a compliance-heavy tax and accounting workload (GST there, MTD here), a legacy data model that had to be preserved while the surface was rebuilt, and a strangler-fig sequencing that kept the existing customer base live throughout. We built the new capability layer, ran it alongside the old, and cut traffic over increment by increment.

For UK enterprises specifically, we scope the first increment as a fixed-price discovery — the façade design, the data cleanse plan, the increment roadmap — so you get a real number to take to your CFO before you commit to the build. Full IP ownership, no vendor lock-in, and the modernisation runs on your cloud accounts, not ours. See our enterprise services for how we structure these engagements.

The argument you take into the meeting

Three slides. Slide one: the four buckets of the cost of doing nothing, totalled honestly, with the SAP 2027 clock and the ICO 2025 fine trend as the two anchoring facts. Slide two: strangler-fig vs big-bang, with the recommendation and the reason. Slide three: the first increment, its self-funding payback logic, and the go/no-go gate before increment two.

The CFO's job is to challenge the numbers. Your job is to make sure the numbers being challenged are the right ones — not the capital cost of the new system in isolation, but the delta between two operating models over the next five years. When the comparison is framed that way, the modernisation case does not need to be sold. It sells itself.

Frequently Asked Questions

What actually happens on 1 January 2028 if we are still on SAP ECC?

You move to SAP Extended Maintenance, which adds 2% to the standard 22% annual maintenance fee, or to a third-party support provider like Rimini Street, or to Customer Specific Maintenance where you receive no regular support. Nothing breaks technically on 1 January — the system keeps running. The exposure builds through 2028 as new tax rules, security vulnerabilities, and integration standards emerge without vendor updates behind them.

How do we quantify the cost of workarounds without a huge internal audit?

Pick your five most painful monthly processes — usually month-end close, AR reconciliation, inventory adjustments, tax filing, and one custom integration. For each, ask the process owner for hours-per-month and multiply by loaded cost. This gets you to a directionally correct number in a week, which is enough to challenge the current run-rate. A full activity-based costing exercise is not necessary to make the business case.

Is a strangler-fig approach realistic for a small IT team?

It is realistic only if you accept that the delivery partner runs the increment and your team runs the governance. A four-person internal IT team cannot deliver strangler-fig alone, but it can absolutely own the roadmap, the vendor management, and the operational cutover for each increment. The alternative — big-bang with the same team — is materially riskier, not safer.

How long does a modernisation programme like this take, end to end?

The elapsed time is driven by three things: the number of capabilities being migrated, the state of your master data going in, and your appetite for parallel running. A programme with a clean scope and disciplined governance runs in increments of roughly one quarter each, and most mid-market ERP replacements sequence six to twelve increments. The variables that turn that into an actual timeline for your situation are the ones worth a scoping conversation.

Can we defer the decision by moving to third-party support?

Yes, and for some organisations it is the right move — third-party support typically costs 50% less than the vendor equivalent and buys you two to three years of runway. It is a tactical decision, not a strategic one. It does not address buckets two, three, or four of the cost of doing nothing, and it does not solve the underlying platform obsolescence. Use it to buy time to modernise properly, not to avoid modernising.