When should you replace existing software — and when shouldn't you?

Somewhere in the organisation a system has been running for years. It is slow, it is ugly, and no one quite knows how it works anymore — except perhaps one employee who has tried to retire three times. But the system runs. Orders come in. Invoices go out.

The question of whether to replace this system is one of the hardest decisions in IT, because acting too early and too late both cost money. Companies that replace too early waste capital on a migration that was unnecessary. Companies that replace too late pay a hidden toll for years in productivity loss, technical debt, and missed opportunities.

Here is an honest framework for making the decision.

The signals that say: replace it

The system creates its own workload

If employees are structurally spending more than two hours per day on workarounds for the system — manual data entry between systems, Excel files as an intermediate layer, copy-paste work that should be automated — then the system is no longer a facilitating tool. It has become part of the workload.

Calculate this concretely. Four employees each spending two hours per day on workarounds: that is eight person-hours per day, forty per week, over two thousand per year. At an average cost level of €40 per hour, that is €80,000 per year in hidden system costs — before the costs of errors caused by manual work.

Integration with modern tools is no longer possible

Virtually every business process today touches multiple systems: CRM, accounting software, e-commerce platform, logistics, communication tools. If your legacy system has no API, or only speaks an outdated protocol that modern tools don't support, you pay integration costs that are disproportionately high — or you accept information silos that obstruct better decision-making.

This point is especially critical when you are growing. A company of twenty people can perhaps live with manual synchronisation. A company of a hundred people cannot.

The vendor has abandoned the system

End-of-life software is an underestimated risk. If the vendor no longer releases security updates, you are running a system with known vulnerabilities that are not being patched. For systems that process customer data, this is also a GDPR risk. Insurers are starting to ask questions about end-of-life software in their cyber policies.

A system without active vendor support is technically speaking on its last legs. The only question is how long it will remain functional before something unexpected brings it down.

One person is the only one who understands it

This is colloquially known as "bus factor one": if that one person is hit by a bus, the system becomes incomprehensible. This is not a hypothetical risk — it is a continuity risk that is flagged by buyers and investors during due diligence.

Systems without documentation, with code that only the original builder can read, become harder and more expensive to maintain with each passing year. Every change costs more than the last.

Security problems are structurally unsolvable

Sometimes vulnerabilities are not software bugs but architectural problems. A system designed without an authentication layer, that stores plain text passwords, or that runs on an outdated server environment that does not support modern security standards: these are not problems you solve with a patch. These are problems that require a new design.

The signals that say: wait

The system works — just not beautifully

There is a difference between a system that causes problems and a system that is old but functional. An ugly dashboard is not a reason to replace a system. A slow but reliable workflow is not a reason to replace a system. The question is always: what does the system cost in its current state, and what does it cost to replace it? If the cost of the system is lower than the cost of migration plus the risks of a transition, waiting is the sensible choice.

The payback period exceeds three years

A software migration costs time, money, and operational disruption. If the annual saving of a new system is less than a third of the migration costs, the business case is weak. Three years is a rule of thumb — for fast-growing companies two years may be acceptable, for stable organisations four years may still be justifiable. But if the payback period is five years or longer, the chances are the organisation will have changed again before then.

There is no internal capacity for the transition

A migration is not just an IT project. It requires the involvement of the people who use the system daily, for defining requirements, testing the new solution, and enduring the initial discomforts. If the organisation is currently going through another major transition, if key employees are overloaded, or if internal ownership cannot be organised, the chance of a successful migration is low — regardless of how good the new system is.

The middle ground: wrapping the legacy system

There is a third option that is often overlooked: not replacing the existing system, but building a modern layer around it.

In the software architecture world this is called a "strangler fig" approach — after the fig tree that slowly grows around another tree and takes it over. You build new functionality in a modern system, and ensure that system communicates with the legacy system via an API. Over time, more and more functions move to the new layer, until the old system does so little that it can safely be switched off.

This is particularly useful when:

• The legacy system has stable core data models worth preserving
• Full replacement is operationally too risky
• You want to modernise step by step without a "big bang" migration

The downside: an API layer over a poorly designed legacy system is a temporary fix. It provides breathing room, but does not solve the underlying architectural problems.

Two migration strategies compared

Big bang: everything at once

You build a completely new system, migrate all data on a set date, and switch off the old system. Advantage: you don't pay for two systems running side by side for years. Disadvantage: the risk is high. If the new system is not working well on launch day, you have no fallback option.

Big bang migrations work best for smaller systems, well-documented processes, and organisations that can absorb the operational disruption.

Strangler fig: phased replacement

You replace the system module by module, with the new system gradually taking over functions from the old one. Advantage: lower risk per phase, continuous learning curve, earlier return on sub-systems. Disadvantage: higher total costs, longer lead time, complexity of running two systems side by side.

For large, business-critical systems, the strangler fig approach is almost always the wiser choice — even if the total costs come out higher.

The decision

Replacement is the right choice when two or more of the "replace it" signals are present and the business case over three years is positive. Waiting is the right choice when the operational pain is manageable and the organisation does not currently have the migration capacity.

What is never the right choice: deciding nothing because the decision is difficult. Every year that a problematic legacy system keeps running, the costs of technical debt accumulate. That debt will be paid eventually — the only question is when, and under what circumstances.