Fifty-five per cent of ERP programmes go over budget and sixty-eight per cent run long, with cost overruns averaging 189 per cent. The technology is rarely what breaks. What breaks is everything the business built around the technology while nobody was writing it down.
There is a version of the modernisation conversation that goes wrong before it starts. It opens with the system — its age, its vendor’s support horizon, its unfashionable architecture — and proceeds directly to replacement options.
The system is the visible object. It is not usually the constraint.
The constraint is the accumulated set of workarounds, spreadsheets, undocumented interfaces, tribal process knowledge and quiet exceptions that have grown around the system over a decade. That layer is invisible, unowned, and considerably more expensive to replace than the software it surrounds.
Where modernisation programmes actually fail
The published failure statistics are not subtle. Overall ERP failure rates sit somewhere between 60 and 70 per cent depending on definition. In discrete manufacturing the figure reaches 73 per cent failing to meet stated objectives, with average cost overruns of 215 per cent. Typical enterprise programmes run seventeen months and more than half exceed budget.
The instructive part is the cause. The most common driver of overrun is not technical complexity in the new platform. It is poorly defined scope generating change orders, and underestimated data migration — specifically, discovering mid-project that the legacy system’s data is inconsistent in ways nobody flagged at scoping.
That is a discovery problem, not an engineering problem. It is entirely preventable, and it is prevented before the contract is signed rather than after.
189%
average cost overrun on ERP programmes — the replacement costs roughly three times what was approved
The mid-market position
A typical mid-market business spent somewhere between €500,000 and €1m on its ERP six or more years ago. Around 63 per cent of European SMEs are still running on legacy systems, and nearly half of SAP ECC customers are expected to remain on their legacy ERP beyond 2027.
These businesses are not negligent. They are making a rational calculation: the system works, the replacement is expensive and risky, and the organisation has adapted around every limitation. That adaptation is the point. Each workaround was individually sensible. Collectively they have become the actual operating model, and the ERP is now merely where some of the data lives.
Ten years of sensible workarounds is not technical debt. It is an undocumented business process with a database attached.
Why dependency is the better frame
Framing the problem as dependency rather than obsolescence changes what you measure, and therefore what you decide.
Obsolescence asks: how old is it, when does support end, what would replace it? These questions produce a procurement exercise.
Dependency asks: what would stop if this system stopped, who knows how it works, how many processes route through it, and what has been built around it that would have to be rebuilt? These questions produce a map — and the map is what a credible business case requires.
The dependency map routinely reveals that the estate is less monolithic than assumed. Some functions are genuinely entangled and must move together; others are separable and can be moved independently, at lower risk, with value delivered before the programme completes. That distinction is invisible from the obsolescence view, which sees only one large object requiring one large decision.
What good looks like instead
The incremental patterns — strangler fig, parallel run, capability-by-capability extraction — are well established and well understood. They are chosen far less often than they should be, for a reason worth naming honestly: a phased approach is harder to approve. A single replacement has one business case, one budget line and one board decision. A phased modernisation requires sustained commitment across multiple budget cycles.
That is an organisational obstacle, not a technical one, and it should be addressed as such rather than avoided by choosing the riskier approach because it is easier to fund.
Before approving a modernisation business case
- Map dependency, not age — what stops, who knows, how many processes route through it
- Profile the legacy data now, at scoping, and treat inconsistency as an assumption to disprove rather than discover
- Cost the workarounds explicitly: the spreadsheets, the manual reconciliations, the exception handling
- Identify which capabilities are genuinely separable and could move first, delivering value inside twelve months
- Name what will NOT be migrated — most estates carry functionality nobody has used for years
- Fund the phased approach properly, or acknowledge you have chosen the higher-risk route for budgeting reasons
The honest position on AI here
AI-assisted tooling has made a genuine difference to migration work, with credible reports of 40 to 60 per cent reductions on well-scoped tasks. That qualifier is doing considerable work in that sentence.
AI accelerates code translation and test generation. It does not tell you which processes matter, which exceptions are load-bearing, or which of the seventeen spreadsheets in the finance team is the one that actually runs the month-end. The expensive part of modernisation was never the code, which is why acceleration of the code has a smaller effect on total programme cost than vendors suggest.
The system is replaceable. The dependency has to be understood first, and that remains a human exercise.