Legacy application support: what good looks like
There is a particular kind of software that keeps British businesses running. It was built years ago, it does its job every day, and nobody thinks about it until something goes wrong. When something does go wrong, the question that matters is simple. Who picks up the phone, and do they actually know the system?
A surprising number of businesses cannot answer that question well. The support arrangement is a developer who moved on years ago and still helps out of goodwill. Or an agency that technically holds the contract but has nobody left who worked on the code. Or nothing at all, which at least has the honesty of being obvious.
None of this means the software is bad. As we argued in our piece on ageing software, a system that has run your business for seven years is an asset. It just deserves support that matches what it does for you.
What support actually covers
Legacy application support is often sold as a phone number and a promise. A proper arrangement is wider than that, and most of it happens when nothing is on fire.
Monitoring
Someone should know your system is struggling before your staff do. Uptime checks, error alerts and disk space warnings are unglamorous, and they turn most emergencies into quiet fixes.
Security patching
Frameworks, libraries and operating systems all publish security fixes on their own schedules. Applying them promptly is the single cheapest thing that keeps an older system safe to run.
Bug fixes and small changes
The report that breaks at year end. The field the new supplier needs. Support should include the steady flow of small development work that keeps the system matched to the business, not just restarts when it falls over.
Knowledge that lives somewhere
Good support leaves a trail: documentation, tested backups, a record of what changed and why. If everything lives in one person's head, you have a dependency, not an arrangement.
Signs your arrangement is wearing out
Support tends to decay slowly, then suddenly. These are the signals we hear most often from businesses who call us, usually later than they would have liked.
Response times have stretched from hours to weeks. Invoices arrive but updates do not. The person who built it answers on their own schedule, because favours have no service level. Every request comes back with a warning that a change might break something, so changes quietly stop being asked for. And nobody can tell you when the last security update was applied.
One of these is a niggle. Three of them mean the safety net has more holes than net, and it is worth sorting out before the next big failure rather than after it.
Taking over a system without drama
The common objection is that nobody else can support the system because nobody else understands it. In our experience that is rarely true. Picking up an unfamiliar codebase is a normal part of engineering work, and there is a well trodden path: read the code, map how it is deployed, get it running somewhere safe, verify the backups, write down what we find. From there the system has a team again, and decisions about its future can be made calmly.
A takeover does not commit you to a rebuild, and it should never start with one. It starts with the boring things done properly, because the boring things are what keep you trading. Where a system genuinely has deeper problems, support is also the safest seat from which to plan incremental modernisation, one careful step at a time.