Legacy systems are the unglamorous backbone of operations. They’re critical, complex and when it comes to modernisation, costly to change.
So at a time when every use case is being put under the AI microscope, legacy modernisation has got to be one of the most compelling.
As James Ross, CTO at SEEK, told me during a recent DiUS Tech Trajectory podcast: “There’s so much legacy code the world has basically been looking the other way.” Adding, “AI would get me excited about legacy modernisation again.”
He’s right. Not because anyone suddenly enjoys dealing with old systems, but because we finally have a practical way to reduce uncertainty. Less time piecing together what’s there, more time choosing a first move you can defend.
Why modernisation is harder than it looks
Modernisation is rarely blocked by technology. It’s blocked by the work you have to do before you can even choose an approach.
Most estates aren’t one tidy application. They overlap and drift:
- Duplicate apps that do similar things in slightly different ways
- Authentication that evolved over time (and is now inconsistent)
- APIs that grew without a clear boundary
- Repos full of dead code and “temporary” patches that became permanent
In plenty of estates, the bus factor is low: one or two people carry the mental model, everyone else is guessing.
You can’t modernise what you can’t see. And for years, getting that visibility meant weeks of senior engineer time.
Warner Godfrey, one of our Principal Consultants who has spent years in the trenches of modernisation, describes legacy discovery as an archaeological dig:
“The things you find are fragmented and fragile. You’ve got examples like code that doesn’t compile, or dependencies that are being archived… and then documentation sometimes reads like folklore.”
Therefore teams avoid discovery, compress it or outsource it, and then pay for it later in rework, incident, and programmes that stall halfway through.
What’s changed: faster clarity, earlier decisions
In our recent webinar with AWS on modernisation, the audience questions were telling:
- Do we start by rolling out tools, or do we do due diligence first?
- Will this work across different languages and stacks?
- What about security and confidentiality of source code?
- How do you measure success beyond “we shipped something”?
This is where today’s tooling has earned a place. Used properly, it can take a big chunk of the grunt work out of discovery by mapping dependencies, surfacing hotspots and drafting documentation, quickly enough that senior engineers can spend their time validating and deciding, not assembling a picture from scratch.
You can hand-roll discovery with AI tools like Claude Code. But platforms like AWS Transform make it easier to do the work consistently across an estate, with a shared workspace, repeatable steps and outputs teams can actually use.
“What excites me most about AI-assisted modernisation is the speed of it…how it unlocks business value quickly,” said Oliver Gibbs, Senior Partner Solution Architect at AWS. “It’s really hard to imagine these types of tools even two years ago.”
Transform provides a workspace-driven way to analyse systems and plan modernisation, and it automates repeatable steps like:
- Discovery and dependency mapping
- Documentation generation
- Transformation tasks (in supported pathways, such as .NET modernisation)
A messy .NET estate, and a discovery problem no one wanted
One client we worked with was running overlapping .NET applications alongside an ageing website repository full of dead front-end code, tangled APIs, proprietary components as well as inconsistent authentication and data access. Development was slow and change felt risky. They’d also been through traditional architecture reviews before, which meant weeks of senior engineering time, lots of detail and not enough clarity to move forward.
We ran an AI-assisted discovery approach using Claude Code on Amazon Bedrock, focused on their application code and website repositories. We mapped the architecture and key flows, probed for security/performance/complexity signals, and generated draft diagrams and summaries for engineers to validate.
The analysis surfaced insecure authentication paths, outdated payment dependencies, memory leaks and inefficient queries. It also matched long-standing incidents the team had been living with, and brought forward issues that earlier reviews hadn’t captured.
What mattered most was the response from the engineers – it reflected reality. The future-state options didn’t feel like a reinvention, they lined up with earlier instincts, but arrived with clearer evidence and in days rather than weeks.
The point is confidence, early
If you’re sitting on a modernisation backlog you’ve been avoiding, I wouldn’t start with a massive programme plan. I’d start by getting crisp answers to a few uncomfortable questions:
- What are the critical journeys and transaction paths we absolutely cannot break?
- Where do incidents and operational load keep clustering, and why?
- What’s duplicated, tightly coupled, or inconsistently governed?
- What’s the smallest end-to-end slice we can modernise safely and ship?
- What needs to change in testing, release, and ownership if we want this to scale?
Modernisation will always involve trade-offs. But the first phase doesn’t need to be months of fog.
With the right mix of tooling, engineering judgement, and a method that forces you into a shippable first step, you can move from “we know this is a problem” to “we know where to start”, without gambling with production.
