Legacy modernisation with AI: read the code before you rewrite it

Every few years a new tool arrives that makes rewriting a legacy system look easy. Code generators, low-code platforms, offshore factories. This time it is AI, and this time the tools are genuinely good. A model can translate a few thousand lines of COBOL or Visual Basic into tidy Java or C# in the time it takes to read this memo.

So the pitch writes itself: point the model at the old codebase, get a new one back, retire the mainframe. Some version of it comes up in most first conversations about modernisation.

The trouble is that the typing was never the expensive part.

What the old system knows

A system that has run a business for twenty years is not just code. It is a record of every decision anyone made about how the business works, including the ones nobody wrote down. The rounding rule finance agreed years ago. The customer type that skips a credit check because of a deal with one large client. The batch job that runs twice at month end because the first run sometimes misses late transactions, and nobody ever fixed the cause.

None of this is in the requirements document, if there is one. Most of it is not in anyone's head any more either. It lives in the code, often in the parts that look like mistakes.

Translate that code line by line and you carry the mistakes across with the rules, with no way to tell them apart. Rewrite it from a fresh spec and you lose the rules nobody remembered to put in the spec. Either way, you find out in production, usually from a customer.

Use AI to read before you use it to write

The same models that make rewriting fast are even more useful for reading. They are patient with old code in a way people are not. They will trace a field through forty programs, summarise what a 3,000-line procedure does, and list every place a date gets calculated slightly differently.

That changes the order of the work. Before anyone writes new code, the first few weeks should go on three things:

• Map what is actually used. Old systems carry a lot of dead code. Knowing which half nobody calls cuts the job down before it starts.
• Pull out the business rules. Every calculation, validation and exception, written as a plain statement a business owner can confirm or reject: “Orders over $10,000 from new customers are held for review.”
• Pin down the behaviour with tests. Characterisation tests record what the system does today, right or wrong, so you can prove later that the new system does the same thing, or that every difference is one you chose.

AI speeds up all three. It does not replace the moment when someone who knows the business reads the rule list and says: that one is a bug, that one is load-bearing, and nobody knows why that one exists. That conversation is the real work, and it is the part most modernisation projects skip.

A plain test: rewrite, refactor, or leave it alone

Once you can see the rules and have tests around them, the big decision gets much easier. Three questions do most of the work.

Can you state what it does? If the rule list is short, clear and agreed, a rewrite on a modern stack is realistic, and AI will make it faster than it would have been five years ago. If the list is long and half of it says “not sure”, you are not ready to rewrite anything.

What is actually hurting? Old technology is not a problem by itself. The real problems are usually that changes take too long, a few people hold all the knowledge, or the platform is going out of support. Each points to a different fix. Slow change often calls for refactoring in place, behind tests. A support deadline might only need a move to a new runtime with the code largely as it is.

Can you run old and new side by side? The safest migrations replace a system one piece at a time, with both versions running on the same inputs until the outputs match. If the architecture makes that impossible, the plan needs to change before the code does.

Sometimes the honest answer is to leave the system where it is, put tests and documentation around it, and spend the money somewhere that matters more. That is a legitimate outcome of a modernisation assessment, and a good adviser should be willing to say so.

If you are about to start

If someone is proposing to rewrite a core system with AI, ask them three things. How will you find out what the current system actually does? How will you prove the new one does the same? What happens to the rules nobody can explain?

If the answers are vague, the timeline is fiction. If they are specific, and they start with reading rather than writing, you are probably talking to the right people.

AI has made the writing cheaper. It has made the reading cheaper too, and that is the better news. Spend the savings on reading.