How AI Helps Modernise Old Software

Most established software is not the system its owners think they run. It is the accreted version: the original design, plus years of patches, integrations, exceptions and month-end fixes, layered on by people who have largely moved on. It works — until you need to change it. At that point the real problem surfaces, and it is rarely the new platform. It is that nobody can fully say what the old system does, the rules that matter live in the code rather than in any document, and there is no test suite to tell you whether a change broke something. That is the gap AI is genuinely good at closing — and the place where it is most dangerous if you let it off the lead.

So this is a piece about what AI actually does well in a modernisation, where it quietly misleads you, and the discipline that lets you keep the speed without inheriting the risk. The short version: AI does the labour; the discipline does the assurance. Everything else follows from that one sentence.

Where AI earns its place

The strongest, lowest-risk use is comprehension. Large undocumented codebases suffer from what one industry analysis calls “code blindness” — scattered files, tangled dependencies and logic that was never written down. AI is good at turning that into a navigable map far faster than manual reading: summarising what a module does, explaining an unfamiliar idiom, and lifting low-level implementation detail up into higher-level intent. The vendor evidence is consistent. In AWS’s Toyota mainframe programme, AWS reports that application discovery and planning were accelerated by roughly 75%, and that detailed documentation of hundreds of COBOL modules was generated “in less than a day”. Those are AWS’s figures, on AWS’s programme — but the direction is clear.

From there, the same capability extends across the slow, manual phases of a modernisation:

• Dependency mapping — tracing what calls what, and what would break if you moved it, across a codebase too large to hold in one head.
• Documentation — turning undocumented behaviour into readable, reviewable descriptions of what the system currently does.
• Test generation — backfilling a test suite onto a system that has none, which is the single most valuable thing you can do before you change anything.
• Refactoring — the mechanical bulk of decomposing, migrating idioms and modernising patterns, at a scale no team would attempt by hand.

Notice the shape of that list. None of it is “let the AI write the new system”. It is the unglamorous, error-prone, expensive groundwork — the part that, done by hand, turns modernisation into a two-year programme nobody finishes. This is where the acceleration is real and the risk is lowest.

Locally correct, globally wrong

Now the honest part, because it is also the credible part. The recurring failure mode of AI on real code is that it is locally correct but globally wrong. It produces output that compiles, passes its own tests and reads convincingly — while being subtly wrong against the architecture or the real-world workload. As one analysis puts it plainly, “LLMs output plausible code, not correct code” — code that looks architecturally sound “but may still fail real-world workloads in subtle or catastrophic ways”, and the model’s own tidy comments and READMEs “reinforce the illusion of correctness”. A summary that sounds authoritative is not evidence; a confident answer about where a piece of logic lives can simply be wrong, sending engineers down the wrong path.

The AI can write a perfect little piece of code, but it can’t see the entire system. It just can’t see the big picture.

The productivity picture is more sobering than the demos suggest, too. In a randomised controlled trial, METR found that experienced developers working on mature codebases they knew well were actually 19% slower using early-2025 AI tooling — even though they believed they were around 20% faster. Speed you can feel is not the same as speed you can measure. This is exactly why we attribute every productivity figure to its named source and never present any of them as our own result: the honest numbers are mixed, and pretending otherwise is the first symptom of the problem we position against.

The discipline that makes it safe

If AI is locally correct but globally wrong, then the engineering is no longer in the generation — it is in keeping the truth. Two things do that work, and neither is optional.

The first is human architectural judgement. AI optimises the token in front of it, not the system around it. Deciding what to lift-and-shift, what to re-platform and what genuinely needs redesigning; reading whether a generated change respects a boundary an experienced engineer would never cross; choosing which captured behaviours are intended versus bugs to be fixed — all of that stays human. AWS bakes this into its own workflow: transformation proceeds “in a sequence defined by the human-in-the-loop”, and only once a human confirms the plan. The human is not a rubber stamp at the end. The human is the architecture.

The second is equivalence testing — the practice that turns speed into safety. Before you change anything, you capture the system’s current behaviour as tests (the oldest, simplest version is the characterisation test: run the program, record the output, change something, run it again, check the output is identical). That frozen behaviour becomes the oracle. A change then ships only when it is provably behaviour-preserving against it — or when a divergence is a deliberate, signed-off fix. There is a sharp trap here that AI makes worse: because AI writes test assertions by reading the implementation, it will happily certify a bug as intended behaviour. So humans decide what to test, and the safety net is judged on whether it can actually catch a regression, not on a coverage percentage. A suite at 91% coverage with a 34% mutation score is a green dashboard over live bugs.

Let the AI drive the car, keep one hand on the wheel — trust but verify. There should be a human in the loop, but that doesn’t mean the human is driving.

This is what “beyond vibe coding” means in practice. Vibe coding optimises generation — the step that just became cheap — and starves the steps that became scarce: judgement and proof. We do the opposite. AI does an enormous amount of the labour; the equivalence net and the human at the gate carry the assurance. The speed is real. We just refuse to spend it on shipping things we cannot prove are correct.

What this means for your modernisation

The practical upshot for an owner weighing up a modernisation is straightforward. AI does not let you skip the disciplines — if anything, the harder your reliability or compliance reality, the more the discipline matters. What it does change is the economics of the groundwork: reading and documenting a large, undocumented estate, building the test safety net it never had, and making incremental changes behind equivalence gates becomes faster and more reliable than a hand-cranked project, with senior engineers owning every decision. You get to the modernised system sooner, and you get there without it becoming the two-year programme that quietly never finishes.

If you have an older system that works but feels risky to change, the first step is not a rebuild — it is an honest read of where it stands. Our free assessment looks at exactly that. Start it at /application-modernisation/free-assessment.