Every new government IT system will become legacy. So why do we keep replacing them?

'Legacy' has become a bit of a dirty word in government IT. Call a system “legacy” and you've pretty much made the argument for replacing it and the tender process gets on its way. It might be old, people complain about it and there's probably a collection of spreadsheets keeping things running behind the scenes. But every system we build today will become legacy too - often sooner than we'd like. Policies change and people need information nobody thought to collect when the system was designed. And with AI accelerating how quickly technology changes - that cycle is only getting shorter. 

So are we really going to keep replacing everything? 

Is the system actually the problem? 

We've all seen how this happens, things change, spreadsheets get created and eventually nobody knows which numbers are correct and getting a simple answer involves asking three different people.  

And of course: the tool gets the blame. 

Which is understandable. Nobody wants to spend their day copy/pasting information. But the question is: is the software really incapable of supporting the service? Or has just nobody properly looked at how information is collected and shared? 

When a replacement gets the go ahead, requirements are gathered and documented - except those requirements often reflect how people work right now, including years of workarounds. The danger here is that complicated processes are simply recreated and any new system ends up doing much the same thing as the old one, maybe faster and with a slightly different set of fields or interface and a rather large implementation bill.  

The example: sometimes the systems just need to talk to each other 

A university commercialisation organisation had an established specialist system for managing intellectual property. It looked clunky, but did its job - but other teams needed access to the information and their own workflows around it. Additional licences were expensive and the access controls didn't suit how people needed to work. Replacing the specialist software would have meant rebuilding functionality that already worked. Instead, we connected it to a more flexible platform, so other teams could work with the information they needed without duplicating it or changing the specialist system. 

The complicated part wasn't necessarily the technology. It was deciding which system should be responsible for which information and what should happen when different teams changed the same records. Most of this work was planning the process and documenting it so it was visible to everyone. 

So when should we actually replace something? 

Yes, there will always be some systems that just need replacing. They're insecure or unsupported, or so difficult to change that even a small tweak would be an expensive project in itself. But before committing to replacement, I'd want to understand what's actually stopping people from doing their jobs. This is an even more important exercise with AI in the mix. If the information is unreliable or nobody knows how a process should actually work, adding AI or automation isn't going to fix anything. But AI-assisted development for example is making small, very specific tools or extensions much more feasible. An unusual approval process or a missing connection between two systems might finally be worth building as an add-on rather than forcing people to live with yet another spreadsheet. 

Whatever we build today will eventually become “old” - but maybe we can keep improving it as the organisation changes, without having to start from scratch again every few years.