Back to blog

At the Ministry of Justice, this was never about dressing up old systems with new language. The real job was to take a live estate with years of history behind it and move it onto foundations that teams could trust, extend, and operate properly.

Within the Legal Aid Agency, that meant tackling the things that quietly make delivery expensive: ageing deployment models, inconsistent engineering standards, heavyweight licensing, fragile release patterns, and too much effort spent simply keeping older platforms alive.

What had to change

We were working in an environment where delivery could not pause while modernisation happened. The systems were live, the services mattered, and the teams still had to ship.

So the problem was not “how do we rebuild everything?”

It was closer to this:

• how do we modernise without creating a long, risky freeze on change?
• how do we bring products up to modern engineering standards rather than just rehost them?
• how do we make releases safe enough that teams can change production regularly rather than nervously?
• how do we reduce the long-term cost of maintaining the estate?

That required a proper shift in engineering discipline, not just a hosting migration.

The line we took

We worked as part of a wider transformation effort to move products away from legacy deployment models and data-centre thinking into cloud-native services on AWS.

That meant modernising codebases, applying cleaner design and cleaner code principles, and reshaping older applications into services that could be packaged, deployed, and operated in a much more consistent way.

Just as importantly, we helped make delivery safer. Blue-green style deployment patterns and stronger pipelines changed the rhythm of release. Instead of change being something teams had to brace for, it became something they could do repeatedly and with far more confidence.

Alongside the application work, we also helped strengthen the shared engineering path around observability, security, onboarding patterns, and reusable platform components, so teams were not each solving the same infrastructure and deployment problems in isolation.

The less visible win: platform cost and future developer effort

A good modernisation programme does more than make architecture diagrams look cleaner.

One of the biggest wins here was reducing the future cost of change.

By moving away from older licensed platforms and reviewing where open-source alternatives made more sense, the organisation put itself on a far better footing commercially as well as technically. The licensing review alone created major savings, and the move towards Spring Boot, containers, and cloud-native services reduced the amount of specialist legacy knowledge needed to keep products moving.

That matters because the real cost of legacy systems is rarely just infrastructure. It is the developer effort they consume year after year.

What this unlocked

By the end of the journey, the conversation had changed.

The focus was no longer on how to nurse older estates through another cycle. The focus was on what product teams could deliver next.

The practical outcomes were significant:

• products within LAA moved onto AWS and out of data-centre dependency
• engineering teams gained safer, repeatable delivery pipelines
• codebases were brought closer to modern standards and cleaner service patterns
• cloud-native deployment became the norm rather than the exception
• licensing and platform choices were reshaped in a way that reduced future cost

Why this story matters

This is the kind of work we want Port60 to be known for.

Not a flashy rewrite presentation. Not a single heroic feature. A serious, multi-year modernisation that leaves a client in a stronger position technically, operationally, and commercially.

When organisations talk to us about legacy modernisation, this is the kind of end state they usually want: safer delivery, better code, lower drag, and a platform that is finally moving in the same direction as the business.