The hidden cost of staying on the wrong system too long

2026-07-14 · 5 min read

Chart showing the cost of staying on outgrown software rising steadily over time as processes calcify, while the one-off cost of moving stays flat - so waiting makes the eventual move larger, not smaller.Why waiting costs more than movingtime on the wrong system →cost of stayingcost of moving (one-off)Break-evenafter this, waiting is the expensive option

"It still works" is the reason businesses stay on outgrown software for years. And it's true — it does still work. That's exactly what makes the cost so easy to ignore.

Chart showing the cost of staying on outgrown software rising steadily over time as processes calcify, while the one-off cost of moving stays flat - so waiting makes the eventual move larger, not smaller.Why waiting costs more than movingtime on the wrong system →cost of stayingcost of moving (one-off)Break-evenafter this, waiting is the expensive option

Where the cost hides

The cost of staying never arrives as an invoice, which is why it doesn't get counted:

  • Every workaround is time, repeated weekly or monthly, forever
  • Every re-key is an error risk that surfaces at the worst moment
  • Every spreadsheet is a decision made on data of unknown age
  • Every "only Sarah knows how that works" is a risk you're carrying uninsured

None of it shows on a licence renewal. All of it shows in your team's week.

Why it compounds

This is the part that catches people out. The cost doesn't stay flat — it accelerates, for two reasons.

First, processes calcify around the limitations. Workarounds become "how we do things", get taught to new starters, and acquire defenders. What began as a patch becomes policy.

Second, the eventual move gets bigger. More history, more integrations, more process to unpick. So the project feels more daunting each year, which makes it easier to postpone again — and the postponement makes it larger still.

That's the trap: the longer you wait because moving feels too big, the bigger moving actually gets. Waiting is not neutral.

Working out your own break-even

You don't need a formal business case to get a usable number. For one month, estimate:

  • Hours spent on manual workarounds that a fitted system would remove
  • Hours lost to month-end that a good close wouldn't need
  • The cost of one material error caused by re-keying or stale data

Annualise it. Compare to a realistic one-off cost of moving, plus the ongoing licence difference. For most businesses that have genuinely outgrown their system, the annual cost of staying is larger than people expect — and it's recurring, where the move is not.

The counter-argument, honestly

Moving isn't always right. If your problems are configuration rather than capability, fixing what you have is cheaper and faster. If you're about to go through a major change — acquisition, restructure, new market — waiting for a stable base can be sensible.

The point isn't that everyone should move. It's that "not now" should be a decision you make with the number in front of you, rather than a default you drift into.

Frequently asked

How do we know we're not just bad at using our current system?
Ask whether the problems are about getting data out (setup) or about what the system can structurally hold (ceiling). The first is fixable where you are.
Isn't it cheaper to wait until we're bigger?
Usually the opposite. More scale means more history and more process to migrate, so the move grows with you.
What's the minimum size for an ERP to make sense?
There's no clean threshold. Complexity matters more than headcount — a 15-person business with stock and multi-currency may need one before a 60-person consultancy does.
Can we phase it to spread the cost?
Often yes. Finance first, then operations, is a common and sensible sequence.
Take the free readiness check

Take the free readiness check

← All insights