INSIGHTS / LEGACY MODERNISATION
Using LLMs to reverse-engineer the legacy system nobody documents
AI can map an undocumented legacy system in weeks instead of months — if you treat it as an analyst proposing theories, not an oracle. What it gets right, what it gets wrong, and how to check its work.
Every modernisation programme eventually hits the same wall: the system that runs the business has no trustworthy documentation, the people who built it are gone, and what everyone knows about it lives in the heads of the few engineers who keep it alive. The traditional answer — read the code, interview the veterans, draw diagrams — takes months and still misses things. AI-assisted discovery does not magically understand your systems, but it can compress the first 80% of the mapping work into weeks — provided you treat the model as an analyst proposing theories, not an oracle handing down facts.
What AI-assisted discovery is genuinely good at
Large language models are excellent at reading enormous amounts of code and summarising what it appears to do: how the system divides into parts, what business rules are buried in decades of if-statements, and how data flows from one process to the next. Pointed at database structures, overnight jobs, and system interfaces, they can produce a working glossary, a map of what seems to depend on what, and a shortlist of places where the system could be safely pulled apart — far faster than a team reading file by file.
They are also surprisingly useful for preparing better questions for the people who know the system. Instead of running a generic workshop, you walk in with specific puzzles: ‘This overnight job updates a table that nothing on the screen ever reads — is that dead code, or part of a reconciliation we don't know about?’ That is the moment discovery actually accelerates.
What it gets wrong — and how you catch it
The models' great weakness is confidence. Given code they only partly understand, they produce fluent, plausible, wrong explanations. They miss things that live outside the code: configuration applied at runtime, features switched on for a single customer, database procedures called indirectly, and the ‘temporary’ integration that has quietly been critical for a decade. They also cannot see operational folklore — the weekly file someone uploads by hand, the one client on a bespoke pricing arrangement.
So every claim gets checked. We cross-reference the model's output against automated code analysis, the actual database structure, production logs, and review by the people who run the system. The rule is simple: every claimed dependency must point to specific code or observed behaviour. If it cannot, it is a hypothesis — and it gets labelled that way in the plan, not quietly promoted to fact.
How the discovery loop works
In practice it is an iterative loop. Catalogue the codebases and data stores. Index them so every AI-generated claim can be traced back to its source. Generate summaries and dependency maps. Check those against what actually runs in production. Take the contradictions to the veterans and resolve them. Then publish the result as a living architecture pack: a glossary, diagrams, a risk register, and a list of seams where modernisation can safely begin.
Those documents should be versioned and maintained like code. As modernisation proceeds, the same pipeline keeps them current — instead of rotting in a shared drive folder last touched in 2019.
From maps to migration
Discovery only matters if it changes delivery risk. The maps tell you what order to modernise in, which behaviour needs tests written around it before anyone touches it, and which pieces are so entangled they must move together. AI can help accelerate the code changes later too — but without a validated understanding of how the system actually behaves, you are just automating guesswork.
The organisations that get the most from this treat AI as a force multiplier for senior engineers — not as a substitute for people who have seen what legacy systems do when you look away.