Business case
The Cost of Waiting Another Year on Your Legacy ERP
Most decisions to replace a legacy ERP feel like a cost you are choosing to take on. The migration budget is £2m, the timeline is eighteen months, and the obvious question is whether you can afford it. I want to flip that question, because the deferred decision has a price too, and it is rarely put on the table. Waiting is not neutral. Waiting is a choice with its own accumulating cost.
The finance case for modernisation rarely stands on its own as a saving. It stands when you add the cost of not doing it. That cost has four parts: the maintenance drift, the compounding technical debt, the lost agility, and the rising risk profile. None of them show up on a single invoice, which is exactly why they get ignored.
Deferral is still a decision
The first discipline is to stop treating "do nothing" as if it were free. The moment you decline to fund a migration, you have made a decision with consequences, and you owe those consequences the same scrutiny as the migration itself. That is uncomfortable for finance teams, because it turns a non-decision into a decision with a price. But it is the honest way to think about an estate that is quietly costing more every year.
The maintenance drift
Maintenance on a legacy system rarely stays flat. As the platform ages, annual support climbs, and once the vendor moves into extended paid support it climbs faster still. Beyond the licence there are the specialists, the people who keep an old ERP alive, who become harder to find and dearer to keep every year. Many of our clients discover that a system they thought of as cheap is, by year five, absorbing well into six figures a year before anyone has touched an upgrade.
This is the line that belongs in the deferral case in black and white. Model the support and specialist cost for the next three, five and eight years at your current path, and put it next to the same years on a modernised platform. The gap is the maintenance drift, and it is usually the easiest number to defend.
Technical debt that compounds
Technical debt is the code and configuration you inherit because each year of waiting forces you to patch around gaps rather than fix them. A legacy ERP reaches a point where the team can no longer make a clean change, only a workaround. Every workaround adds debt that the eventual migration must either carry or pay off. It is exactly the force described in what a legacy ERP migration really costs, because dirty data and accumulated customisations are what turn a modest project into a £10m one.
Waiting does not park this debt. It accrues it. The longer you wait, the more the eventual build inherits, and the more the migration spends on unpicking workarounds that exist only because you deferred. Forrester's research into technical debt puts the cost of deferring modernisation far above the maintenance bill alone.
A manufacturer we worked with had deferred for four years while business went through two acquisitions. By the time they moved, the migration had to reconcile three separate sets of part numbers and two chart of accounts. Roughly a fifth of the build budget went on cleaning up the legacy of waiting, money a decision three years earlier would have avoided.
The cost of lost agility
The hardest cost to quantify is the one that matters most to a growing business: what you cannot do because the system cannot change fast enough. New markets, new pricing models, new reporting obligations, new integrations with cloud tools, each of these is delayed, made expensive, or abandoned on a rigid legacy platform. A competitor with a flexible system ships the feature in a quarter. You take a year or quietly never do it.
Name the missed opportunities, even if you can only ballpark them. Two or three concrete examples, a new online channel that took twice as long, a reporting rule the old system could not produce, a partner integration that had to be done by hand, are worth more in a boardroom than a generic claim about agility. This is the positive side of the argument in legacy versus cloud ERP.
Building the case in numbers
To turn this into a decision, build a simple model in three columns. Column one is the cost to migrate now. Column two is the cost to migrate later, inflated by the extra debt and dirty data you will inherit. Column three is the cost of maintaining and missing opportunities in the years between. The case to move early is stronger when column three is growing, and weaker when your platform is genuinely small and stable.
The honest version is that a small, unremarkable ERP on a healthy support contract may be fine to keep for a year or two. The mistake is to keep it by default rather than by calculation. Where those lines sit for your organisation depends on the scale of your estate, which is why planning the migration step by step begins with exactly this kind of baseline.
Frequently asked questions
What is the cost of delaying an ERP migration?
It is the sum of rising maintenance and specialist support, the compounding technical debt you inherit later, the value of opportunities a rigid system blocks, and the growing risk of running unsupported or failing audits. Each can be modelled; together they usually outweigh a modest early migration.
How much does legacy ERP maintenance cost per year?
Typically around 20 per cent of the licence value annually, rising to more in extended support, plus the salary of scarce specialists who know the old platform. For a mid-size enterprise this often lands in the low six figures before any upgrade work is counted.
Should we migrate now or wait?
It depends on your estate size, support status and growth plans. The disciplined answer is to model the cost of both paths and compare. If the system is small and stable, waiting can be sensible. If it is large, heavily customised or nearing end of support, waiting usually costs more than moving.
How is technical debt in ERP measured?
By counting customisations, workarounds and data anomalies that a migration would have to resolve, then pricing the effort to unpick them. The rough proxy is that heavily customised estates consistently spend far more per migration than vanilla same-vendor replacements.
Sources and further reading
The argument in this article draws on public research. Where you want to go deeper, these are the sources cited in the text and further reading.
