Old systems cost more every year because nothing changes

A system that does not change still sits on platforms, contracts and people that do

Most IT directors have one: a business system built years ago, doing the job it always did, left alone, and costing more to run each year than the last. The usual explanation is that it is legacy, and legacy is expensive.

That is the wrong diagnosis, and it leads to the wrong cure.

The code is not what is getting dearer. Everything around it is. The platform reaches the end of vendor support, so the organisation pays for extended security updates or keeps an old licence alive. The server was sized for a load that never came and nobody has dared shrink it. The support renewal goes up regardless of what was delivered. Staff find ways round faults nobody fixes, until the way round is simply how the job is done, paid for in time that never reaches an invoice. If one person holds the knowledge, every absence is a risk and every emergency is charged at the rate they choose.

No single line is big enough to trigger a review, and each lands in a different budget, so nobody sees the total. A system that does not change still sits on platforms, contracts and people that do, and all of them drift the same way. I have set out the usual cost lines; the point here is the order of attack.

The wrong cure

Because the system is old, the instinct is to modernise it: a rebuild or a move to the cloud, with the rising cost as justification. I think that is usually the wrong first move. The organisation does not know what the system costs, so it cannot know what modernising would save.

The order I would argue for is measure, stabilise, consolidate, then modernise. Most organisations do the last step first and the third step last, if at all.

Measure first. Put every contract and invoice the system generates in one list: support, hosting, licences, hardware maintenance, extended updates. Add an honest estimate of staff time spent on workarounds. Then ask what the support spend bought in the last twelve months: not what the contract promised, but what was changed and fixed. An IT leader can do this without a developer, and in my view it is the step most often skipped, because the answer is sometimes embarrassing.

Stabilise second. Take the faults that keep coming back and fix their causes, most frequent first. Put the source code where more than one person can reach it and prove it builds and releases from there. Restore a backup and check it works. This costs money before it saves any, which is why it gets postponed, but a system that falls over every month-end needs more support hours than one that does not.

Consolidate third, and this is where the money usually is. Organisations that have grown by acquisition, or simply by time, run overlapping systems: two holding the same customer records, three producing the same report, each with its own licence, hosting and support. Retiring one is unglamorous: move the data, move the users, switch it off, and resist keeping it "just in case" with the licence still running. It removes a whole line of cost rather than trimming one.

Modernise last, and only where it pays. Taking the database onto a supported version ends the extended-update bill. Rewriting the one module behind most of the support tickets takes those tickets away. Each is a single spend justified by a number that exists only because the measuring was done first.

Why the order goes wrong

A typical case, and I mean typical rather than any one organisation, looks like this:

The board sees the rising cost and asks for a plan. A modernisation programme is the visible answer. Some way in, the new system is partly built, the old one is still running because nobody could switch it off, and the organisation is paying for both. The overlap consolidation would have removed has been doubled.

Modernise too early and the money goes into a system nobody has costed, so no saving can be shown. Consolidate too late and the overlap survives the whole programme. Skip stabilising because the system is about to be replaced, and the faults are lived with for years when the replacement runs late.

There is a coming date that makes this concrete: Windows Server 2016 stops receiving free security fixes on 12^th January 2027. If a line-of-business system still runs on it, the question is not, "when is the rebuild" but, "what does this server cost, what depends on it, and can the application move to a supported version as it stands?" Often it can, with no change to the application. Extended security updates buy time for that move; they are not somewhere to settle.

Nothing changing is not a reason for the cost to stay flat. It is the reason it rises. The system stands still while its platforms, contracts and people move on, and the gap is what you pay for. Close it in the right order and much of the cost comes out before anyone writes a line of new code.

Graham Church is the founder of CodeFirst, a UK software company that takes over, supports and modernises business software built by others.