When your old software is worth keeping

Key takeaways

The industry treats old software as a problem waiting to be replaced. After thirty years, the case for keeping it, how to modernise around it, and the honest signs it really is time to let go.

There is an assumption in this industry that old software is a problem waiting to be replaced. Sometimes it is. But after thirty years of looking at systems businesses depend on, I think the assumption is wrong more often than it is right, and it is wrong in an expensive direction.

Here is the case for keeping old software, and the honest signs that it really is time to let it go.

What old software knows

A system that has run a business for fifteen years contains fifteen years of decisions. Every odd rule about how a particular customer is invoiced. Every edge case that caused a complaint once and was quietly fixed. Every compliance requirement somebody had to build in after an audit.

Almost none of that is written down anywhere else. It lives in the code.

A brand new system starts with none of it. Most rebuilds spend their first year rediscovering, one problem at a time, rules the old system already knew. The business pays for each of those twice: once when it was first built, and again when it is relearned.

When keeping it is right

The logic is still correct. If the system still does what the business needs, and the complaints are about how it looks or how slow it is rather than what it does, the valuable part is fine.

The problems are around the edges. It does not talk to the new accounts package. It cannot be reached from a phone. Reports take too long. Each of those can usually be solved by building around the old system rather than through it.

It is understood. If somebody can explain what it does and can change it safely, it is not a mystery, it is an asset with known costs.

The replacement is not clearly better. Not "more modern". Better at the specific things this business needs.

What "modernising around it" means

Keeping old software does not mean leaving it untouched. It usually means one or more of these:

  • Connecting it to newer tools, so information flows to the accounts package or the website instead of being retyped.
  • Putting a modern screen in front of it for the jobs people do most, while the old system carries on underneath.
  • Making it faster, which is often a handful of specific fixes rather than a rewrite.
  • Moving it onto supported hosting, so the risk of the underlying technology going out of support is dealt with directly.

Each of those is a contained job with a clear price. Together they often get a business most of what a rebuild promised, for a fraction of the cost and almost none of the risk.

When it really is time to replace it

Honesty matters here, because the case above can be overstated.

Nobody can safely change it. If every change is a risk because nothing is tested and nobody understands it, the cost of keeping it rises every year.

The technology underneath is gone. A system built on a platform that no longer receives security updates, with no realistic way to move it, is a liability that grows.

It cannot do what the business now does. If the business has changed shape and the system has not, workarounds pile up until they are most of the job.

The cost of keeping it exceeds the cost of moving. Measured, not felt. Licences, workarounds, time lost and risk, set against a replacement priced properly, including the year of relearning.

When those are true, replacing it is right, and we will say so in writing.

Find out what it actually does first

Whichever way the decision goes, the first job is the same: somebody reads the system and writes down what it really does, which rules matter and where the risks are. That document is useful whether you keep the system, modernise around it, or replace it, because a replacement built without it will relearn every rule the hard way.

What we do

Older systems are ordinary work here. Nothing we haven't already seen: .NET, Python, PHP, Access databases and desktop applications that have outlived their authors.

You describe the system and what is going wrong. It gets graded by size, you get a price in writing before anything starts, and nothing begins until you approve it. The written assessment is yours to take elsewhere.

Boring and correct beats shiny and new. We will tell you which one your system is.

The price changes with the size of the job. The standard never does.

Matt Houldsworth, Founder, Software Delivered

Matt Houldsworth

Founder, Software Delivered

Matt has spent thirty years building software that has to work, from systems handling a hundred million database transactions an hour to ecommerce platforms turning over millions of pounds a month. He founded Software Delivered to price development honestly and to rescue the projects other people walked away from.

Software that needs rescuing?

Tell us what is going wrong and we will price the fix up front. No hourly billing, no commitment.