I have never met a board that said no to an ERP replacement out of principle. They say not yet. The system still works. The timing is not right. We will look at it in the new year. And because ERP projects run on the budget cycle, "in the new year" becomes "next year" becomes "the year after".
This article is about pricing that delay. Not vaguely, in the way people say "it is costing us money", but in a way you can put on a slide. Because once the cost of waiting is on a slide, the conversation changes from whether to act to how soon.
In this guide
What waiting actually costs
The cost of waiting has four parts, and only the first one shows up in the accounts:
- The operating drag. The rekeying, reconciliation, waiting and error correction from the last article on the real cost of running software you have outgrown. It renews every month, whether or not you decide anything.
- The forgone savings. The hours, licences and errors the new system would remove. Every month of delay is a month those savings do not start.
- The rising replacement price. The longer you wait, the more the old system decays, the more data accumulates, and the more expensive the migration becomes. Migrations do not get cheaper with time.
- The risk premium. Each quarter on life support is a quarter closer to the triggering event described in the day your ERP becomes a liability. The premium is the probability of that event times its cost.
Add the four together and the annual cost of waiting is usually a six-figure number for a mid-size business. The replacement project, by comparison, is a one-off with a defined end. Waiting is the only option where the cost has no end date.
Why the cost compounds
The cost of waiting does not stay flat. Three of the four parts grow each year. Maintenance rises. The workaround layer thickens. Data volume climbs, making the eventual migration harder. And the risk premium grows as support windows close and knowledge leaves. This is not a straight line. It is a curve, and the curve is why the decision keeps getting more expensive the longer it sits.
The business environment matters here too. The Confederation of British Industry tracks investment intentions across the economy, and the pattern is consistent: firms that hold back on productivity investment in difficult years tend to emerge from those years with the same problems and thinner margins. The Enterprise Research Centre makes the same point about UK small and medium businesses specifically: the firms that invest through uncertainty grow faster than the ones that wait for certainty, and certainty rarely arrives.
Even the government's own Small Business Survey 2024 shows how much of the UK economy's resilience sits with firms that keep improving their operations. Waiting for the perfect quarter is how the perfect quarter never comes.
A components business first built a replacement business case in 2021. The project was deferred twice, once for an acquisition and once for a downturn in orders. When I was brought in two years later, the business case numbers had aged badly: the maintenance bill had risen 19 percent, two of the three people who could run the old system had left, and a data migration that would have cost £60,000 was now a £110,000 job because nobody had kept the data clean. The business spent £430,000 on a project that would have cost £310,000 two years earlier, and lost the two years of savings in between. The delay, not the software, was the most expensive line in the whole exercise.
ROI now versus later
Build the comparison as two five-year totals and discount both to present value. On one side, the cost of staying: licences, maintenance, hosting, workarounds, risk, each year, projected forward. On the other, the cost of moving: project cost, new licences, migration, then the net operating cost of the new system, which should be lower.
The crossover point is the date after which waiting costs more than acting. In most of the cases I have worked on, the crossover lands between month nine and month twenty-four. That means the "wait for the right moment" position is usually already underwater by the time the next budget cycle opens.
Two refinements that boards respect: put a probability on the risk line rather than a worst case, and show the range, not a single number. A range is honest. A single number is a target for someone to argue with.
The budget cycle decides more than you think
ERP projects need capital approval, and capital approval runs on the budget cycle. Miss the cycle and the decision slides a full year, which means the cost of waiting doubles before anyone has said no to anything. The practical implication is brutal: the decision about whether the project starts this financial year has to be made roughly nine to twelve months before you want it to start.
That is why the timing question is not a finance question. It is a calendar question. If the business case is not on the agenda two quarters before the budget is set, the decision has effectively already been made, in favour of another year of waiting, by default.
When waiting is the right call
To be fair to the not-yet position, there are legitimate reasons to wait:
- The business is mid-transaction, and the change would land in the middle of it.
- A major process change is already underway, and layering ERP on top would confuse the outcome.
- The current system genuinely meets the requirements, and the business case for change is thin.
The test for all three is the same: does the wait have a date? A deliberate delay with a written review date, a named owner and a defined trigger is a plan. An open-ended wait is a risk wearing a plan's clothes. Put the review date in the diary, put the trigger in the risk register, and hold yourself to both.
When the decision tips toward action, the route is in planning an ERP change without disrupting daily operations, and if the new platform is cloud based, moving your back office to the cloud without losing sleep covers the practical path.
Frequently asked questions
What is the cost of delaying an ERP replacement?
Each year of delay costs the business the hidden operating costs of the old system, plus any savings the new system would have delivered, plus the rising risk of a triggering event. In my experience the total often exceeds the entire replacement budget within two years.
Is there ever a good reason to wait on an ERP change?
Yes: if the business is mid-transaction, if a major process change is already underway, or if the current system is genuinely meeting requirements. The test is whether the wait has a date. A deliberate delay with a written review date is a plan. An open-ended wait is a risk.
How do I calculate the ROI of replacing my ERP now versus later?
Compare two five-year totals: the cost of staying (licences, maintenance, workarounds, risk) against the cost of moving (project cost, new licences, net of savings). Discount both to present value and the crossover point tells you the date after which waiting costs more than acting.
How do ERP decisions fit into the budget cycle?
ERP projects usually need a capital approval that fits the annual budget cycle, so the practical question is whether the business case lands before the budget is set. Missing the cycle usually means waiting a full year, which is why the timing decision has to be made nine to twelve months ahead.
The honest summary: the only way to lose the timing argument is to let it run on the budget cycle. Price the delay, find the crossover point, and put the decision on the agenda two quarters before the budget is set. Then the calendar works for you instead of against you.
