The Real Cost of the System You Keep Postponing

Every company between 50 and 250 people has one system nobody wants to touch. It runs the warehouse, or the payroll, or the order book, and everyone agrees it is fragile, and it survives every budget round because replacing it is expensive and it has not actually broken yet.

That last part is the trap. "Has not broken yet" is not the same as "costs nothing." Technical debt does not send an invoice, so it is easy to treat as free. It is not free. It is a cost you are paying every month in a currency that does not show up on the systems line of the budget: slower delivery, higher headcount, and engineers who leave.

Why the cost stays invisible

A new system shows up as a capital cost with a start date and an end date. Technical debt shows up as a tax spread across every other project: the two extra days a developer spends working around the old invoicing module, the manual export somebody runs every Friday because the system will not talk to the new CRM, the one person who understands the scheduling logic and cannot take two consecutive weeks off.

None of that appears on an invoice. All of it appears on a P&L, as lower output from the same headcount.

A framework for putting a number on it

Four questions turn a vague sense of dread into a figure a board can compare against a rebuild quote.

1. What is the workaround tax? Add up the recurring manual steps that exist only because the system cannot do something natively: the spreadsheet reconciliation, the duplicate data entry, the manual export. Multiply by the hourly cost of the person doing it, weekly, for a year.

2. What is the delivery drag? Ask your technical lead how much longer a typical feature takes because of this system, as a percentage. Twenty percent longer on a team of four developers is close to one full developer's annual cost, spent on friction rather than output.

3. What is the retention risk? Legacy systems are a leading reason capable engineers leave mid-career roles. Replacing one senior developer typically costs six to nine months of their salary in recruitment and ramp-up. If the old system is why someone is already looking, that cost belongs in the total.

4. What is the failure exposure? What does one day of this system being down actually cost you, in missed orders, idle staff, or breached SLAs? Multiply by your honest estimate of how likely that is this year, not zero.

Sum the four and you have an annual cost of doing nothing. Compare it against a rebuild or replatform quote, amortised over three to five years. Most owners are surprised which number is larger.

The regional version of this problem

There is a Central European wrinkle worth naming. A large share of the core systems still running in Czech and Slovak mid-market companies were built or heavily customised during the 2000s growth years, often by a local supplier who has since been acquired, changed direction, or stopped supporting that product. The debt is not only in the code. It is in the fact that the people who understood it no longer work anywhere you can reach them.

That changes the calculation. When a system is unsupported, the workaround tax and the retention risk both rise, because every change now depends on a small number of internal people reverse-engineering decisions nobody documented. If your supplier relationship has quietly ended, treat that as a material change in the cost of keeping the system, not a neutral event.

Where we disagree with most vendors

Most vendors who sell modernisation projects will tell you to replace everything, because a full rebuild is the biggest invoice they can write. That is usually the wrong advice. A full rebuild is justified when the system blocks growth outright: it cannot handle a second country, a second currency, or a second product line. Short of that, a staged migration, replacing the worst-offending module first while the rest of the system keeps running, gets you most of the benefit at a fraction of the risk and the cost. We have run exactly this pattern for a scale-up client, rebuilding a core product without stopping the business.

The system you keep postponing rarely needs a single heroic rewrite. It needs someone to actually run the four numbers above, then fix the one line item that is bleeding the most.

Frequently asked questions

How do I know if I have a technical debt problem or just an ageing system?

Age alone is not the signal. The signal is whether the system is now shaping business decisions. When you avoid a new market, a new integration, or a new hire because "the system cannot do that", the debt has started to run the company rather than the other way round.

Is a full rewrite ever the right call?

Yes, when the current system cannot support a structural change you already need: a second country, a second product line, or a compliance requirement it was never built for. Short of that, staged replacement of the worst component usually beats a full rewrite on both cost and risk.

Who should own this calculation inside the business?

Whoever owns the P&L for the team most affected, working with whoever leads engineering or IT. The finance framing matters: this exercise only changes minds when the output is a number the board can put next to a rebuild quote, not a technical description of code quality.

If you want a second opinion on what your oldest system is actually costing you, book a 30-minute technical audit conversation. No rebuild quote attached.