Most legacy modernisation programmes do not fail on the new platform. They fail on the old one. Nobody fully knows what the existing system does, so the replacement either misses behaviour the business depends on or copies decades of accidental logic into a modern stack.
Mainframe batch jobs, COBOL copybooks, stored procedures and ten-year-old monoliths carry rules that live nowhere else. The people who wrote them have often moved on. Documentation, where it exists, describes intent from a long time ago.
AI-assisted code understanding changes the economics of that first problem. It does not remove the need for engineering judgement.
Understanding before rewriting
The useful first output of a modernisation effort is not new code. It is a map:
- Which programs, jobs and services exist, and which are still called
- How data moves between them — files, tables, queues, screens
- Where business rules sit, and which ones are duplicated
- What runs on a schedule, and what depends on that schedule
- Which interfaces other systems rely on
Language models are good at reading unfamiliar code at volume, summarising what a module does, tracing a field through copybooks and suggesting where a rule is implemented. That turns weeks of manual archaeology into a review exercise. Engineers check the map rather than drawing it from scratch.
Treat AI output as a hypothesis
A model’s explanation of a COBOL paragraph is a claim, not a fact. It can be confidently wrong about edge cases, packed decimal handling, implicit file ordering or behaviour that only shows up at month-end.
Practical safeguards:
- Link every generated summary back to the source lines it describes
- Have subject matter experts confirm the rules that matter most
- Record unknowns explicitly rather than smoothing them over
- Validate understanding against real production inputs and outputs
The goal is a shared, reviewable understanding of behaviour that the business signs off — not a pile of generated documentation nobody trusts.
Characterisation tests are the safety net
Before changing anything, capture what the system does today. Characterisation tests record current outputs for known inputs, including the odd ones. AI can help generate candidate test cases from code paths and historical data, but humans decide which behaviour is correct and which is a bug the business has learned to live with.
These tests become the contract the new system must meet. Without them, “it works the same” is an opinion.
Choose the modernisation pattern per component
Not everything needs a rewrite. Once behaviour is mapped, each component can take its own path:
- Retain — stable, low-change code that works and costs little to run
- Wrap — expose existing logic through APIs so new channels can use it
- Refactor — restructure in place where the platform is fine but the code is not
- Replace — rebuild where the platform or the logic is the real constraint
A strangler approach usually beats a big-bang cutover. New services take over one capability at a time, with traffic routed gradually and the old path kept available until the new one has proved itself.
AI-assisted translation, carefully
Models can translate COBOL or legacy Java into modern languages faster than people can. The output tends to be literal: correct-looking code that preserves the old structure and its quirks. That may be acceptable for a first pass, but it is rarely the design you want to maintain for the next decade.
Use generated translation to accelerate, then refactor towards a clear domain model. Run the characterisation tests at every step. Review generated code with the same rigour as human code, because it will be owned by humans.
Data is the hard part
Code migrates; data has to be reconciled. Legacy data formats, encodings, implicit defaults and historical corrections all need explicit handling. Plan parallel runs where old and new systems process the same inputs and differences are investigated, not ignored.
Where to start
- Pick one bounded domain with clear business ownership, not the whole estate
- Build the code and data map first, with AI doing the reading and engineers doing the checking
- Write characterisation tests before any change
- Decide retain, wrap, refactor or replace per component
- Plan cutover and rollback before the first new service goes live
Incubics helps teams map legacy behaviour and modernise it in increments that the business can verify.