This post is part of our Delivering Public Safety Outcomes at Pace series.
Spend any time inside a policing or justice organisation and you start to see the same patterns. People switch between systems, copy information from one place to another, and rely on spreadsheets just to build a complete picture. None of it feels deliberate, but it has quietly become the way work gets done.
That is what technical debt looks like in practice. It is not an abstract IT issue, but something that shapes the working day and slows people down. In already stretched environments, that friction quickly becomes a real problem.
The instinct, when things get this tangled, is to start again. Replace the systems, wipe the slate clean, and build something new. It sounds decisive, but it is rarely the safest or most effective option.
In many cases, the better approach is more measured. Modernisation does not have to mean starting from scratch, and new does not automatically mean better. The organisations seeing the most success are often the ones improving what they already have, rather than replacing it wholesale.
What technical debt really looks like
Ask people to define technical debt and you will get a range of answers, but Ben Pirt, Principal Technologist at Made Tech, puts it simply. “It ultimately just looks like code that you can’t really maintain. Once systems reach that point, everything becomes harder, from making small changes to finding people who understand how things work.”
Ben adds: “What is often overlooked is that age is not the only factor. Some systems have been running for decades, while others are only a few years old but already difficult to work with.
“I think the issue comes from neglect, whether that’s over a long or short timescale. Most systems were built with good intentions, but as standards move on and expectations change, they are not always updated to keep pace. Over time, they drift further away from what users actually need.”
Where legacy systems hit hardest
That gap tends to show up most clearly in frontline roles. Geraldine Mathews, Made Tech’s Client Partner, describes environments where caseworkers move constantly between systems that were never designed to work together. Each system does its own job, but there is no single view, so people are forced to piece information together themselves.
“If you wanted to know one thing, you logged into that system. For something else, you logged into another, and never the two should meet. The result is duplication, repetition and a steady loss of time. Users just want IT to work for them, be intuitive and solve the whole problem, often in difficult and complex situations.”
Geraldine continues: “They really just want to be sitting down, looking someone in the eye. IT should support that work, not take time away from it.”
Part of the reason this situation develops is structural. In the commercial world, products improve because organisations compete for users. In government, internal systems do not face that same pressure, so once they are delivered, they can remain unchanged for years.
“They’ve got to be maintained,” Ben explains. “Without that natural incentive to evolve, systems tend to stagnate. Over time, workarounds build up and the gap between what the system does and what users need continues to grow.”
Why evolution beats replacement
At that point, a full rewrite can seem like the obvious answer. It offers the promise of a clean start and a chance to fix everything in one go. In reality, it introduces significant risk, especially when the existing system is still handling critical work.
There is also the challenge of understanding what the system actually does. In many cases, documentation is limited and knowledge has moved on. Switching everything off and replacing it in one step leaves very little room for learning or adjustment.
A more practical approach is to evolve the system in place. That does not mean preserving everything, but it does mean understanding it properly before making changes. As Ben puts it, “It’s not a legacy IT problem,” and starting with technology alone misses the point.
The first step is to understand how people use the system today and where it causes friction. That means combining technical analysis with user research and service design. Only then does it make sense to decide what needs to change and how to change it.
Reducing risk without stopping the service
Risk is always part of the conversation, especially in services that handle large volumes of sensitive data. The way change is delivered makes a big difference here. Incremental approaches allow teams to test, learn and adjust before committing fully.
Ben describes work on a system where the team analysed existing behaviour, then tested a new version against real data. They ran both systems in parallel and gradually shifted usage across, monitoring the results as they went.
“We compared it against millions of real examples,” he says. “In some cases, we even discovered issues in the original system that had gone unnoticed.” The transition itself was so smooth that “no one noticed”, which is often the best possible outcome.
This approach also brings users into the process earlier. Instead of delivering something new at the end of a long project, teams can show progress as they go and gather feedback along the way. That creates a stronger sense of ownership and improves adoption.
For people who have used the same systems for years without being consulted, being involved makes a real difference. It turns change into something they are part of, rather than something that happens to them.
Dealing with uncertainty
One of the challenges with this kind of work is uncertainty. Legacy systems often contain hidden dependencies and behaviours that only become visible once you start digging into them. That can make it difficult to define exact timelines and costs upfront.
“There are huge amounts of unknowns,” Ben says. “The most effective projects tend to acknowledge that reality rather than trying to plan around it. They rely on experienced teams who can adapt as new information emerges.”
There is also a growing recognition that technical debt is not just an operational issue. As systems age, they can introduce security risks as well. The longer technical debt is ignored, the harder it becomes to address. What starts as an inconvenience can gradually turn into a barrier to change and, in some cases, a source of real risk.
This all points towards a more balanced view of modernisation. It is not about defending legacy systems, but it is not about discarding them either. The goal is to improve what exists in a way that is controlled, sustainable and grounded in real needs.
That approach can reduce costs by extending the life of existing systems, while improving performance where it matters most. It also lowers risk by avoiding disruptive, all-or-nothing change.
For organisations working in policing, justice and across government, that is often the more responsible path. It delivers progress without unnecessary upheaval, and it keeps the focus where it belongs, which is on the people using these systems every day.
Learn more about our public safety and defence expertise and how Made Tech can help your organisation.
About the Authors
Geraldine Mathews
Client Partner
Ben Pirt
Principal Software Engineer
