All major organisations have legacy technology. It is mistaken to believe that this is the result of simply buying technology in the past. Old technology is not legacy if it functions well with other technologies and still meets the needs of an organisation.

Legacy technology is when technology is outmoded, non or barely functional, expensive and a risk to your services and is entrenched within your organisation.

Controversially, I don’t believe this is the result of inaction – but rather the result of equal amounts of forces acting on the technology – inertia. Legacy technology sits in a nexus of relationships who all push against remediation and effectively cancel out the ability to change the technology.

The forces contributing to this inertia are systemic and often non-technical, below I will examine each of the main points here and what can be done about them.

Risk appetite

Senior management risk appetite can be a significant factor against change. If there is no reward for legacy remediation and more scrutiny on new projects, there is everything to gain from leaving things as they are.

Having the right management and incentives are key. Having a management team that understands risk and technology, or at least having one that does not obstruct those who do understand these things in the organisation is vital.

This includes having a more mature understanding of risk. Obviously, all change represents risk, but the threat of inaction means that ultimately full system failure (or data loss) is an increasing possibility. A failure to address long term risks means an increased risk in catastrophic failure and an impact on residents.

The fundamental shift is in incentives: there must be a change away from rewarding inertia towards rewarding action. You need to maintain a risk appetite for actively managing how technology fits your service model and if not, take responsibility for the loss when it comes on your watch.

Technology gaps

If an organisation believes they have unmapped dependencies within their systems. The risk of picking up a rock and finding something disturbing will be too great to try and change things.

If the technology teams have skills gaps – and this is especially the case where the technology function in an organisation are buyers rather than builders, then the fear of taking responsibility for running the technology will impede any attempt to remediate legacy technology.

Owning service patterns

If an organisation’s service patterns are dictated by the legacy software itself then it is likely they will not have service maps and be reliant on the software to make things work. Organisations wanting to move off legacy software will require service maps, technical maps and the vision and delivery expertise to make it happen. 

The skills to build these products may be absent within the organisation and are a prerequisite to leaving legacy software. Ultimately service teams take ownership of their service patterns and start to dictate to the market what software best supports what they want to do.

Having a fit for purpose commercial approach

Allowing the service team to own the service maps and dictate to the market will mean smaller contracts than legacy software allows.

If the organisation’s commercial approach is heavy handed for new projects, evaluation non-existent for legacy contracts and coupled with poor record keeping of what contracts exist and when they come to an end then the chances of moving to smaller short-term contracts that are actively managed will be slim to non-existent.

There needs to be good systems in place for the control of contracts. This means lightweight processes of governance and approval and systematically favoring smaller over bigger agreements.

The End of End-to-End Software?

From a technical point of view, Agentic AI can be a powerful tool for remediation. It can help us get on top of contracts, find the hidden incentives in management structures that reward inertia, map dependencies, and assist service teams in developing their own service patterns.

But Agentic AI can go even further: it could spell the end for legacy end-to-end software.

Today, most end-to-end software has a user interface, a data transformation layer, a database, and a secure transmission method between these layers. If Model Context Protocol (MCP) allows Agentic AI to access a database and perform data transformations securely, and the user no longer requires an interface, then what is left? You could have databases linked with an or many Agentic AIs to provide a service that was previously the domain of end-to-end services. A future that is probably much closer than one thinks.

For more information on our Agentic AI approach in council services, visit the project page.