Modernising legacy systems with AI as an archaeologist

Every legacy system still running has one thing in common: it works. It may be ugly, expensive to maintain and frightening to newcomers, but somebody depends on it every day. That is why modernisation is a risk problem before it is a code problem.

The bottleneck is understanding, not writing

Anyone who has been through a modernisation project knows the slow part is not typing the new code. It is finding out why the old code does what it does.

That odd condition in the shipping calculation probably handles a real case nobody documented. The field that looks dead feeds a report someone on the board opens once a quarter. The rule that contradicts the specification was written after an incident.

That is the dominant cost, and it is exactly where AI changes the economics of the work.

AI as an archaeologist

The use of AI that pays off best on legacy is not generating the new system. It is rebuilding the understanding of the old one.

Four tasks work well today:

• Explaining a dense section in plain language, which gives a starting point to someone who has never seen that module.
• Mapping dependencies and showing who calls what, including in languages the current team does not know.
• Extracting candidate business rules from long procedural code, producing a list for the domain expert to confirm or reject.
• Generating characterisation tests, which describe current behaviour rather than desired behaviour.

The last item is the most underrated. Characterisation tests are what turn risky refactoring into verifiable refactoring, and writing them by hand for a large module is tedious enough that teams always postpone it.

Where it gets things wrong and you pay dearly

The characteristic failure mode is the plausible, wrong explanation. The model reads the structure of the code and produces a coherent narrative that may ignore the real historical reason.

It also cannot see what is not in the repository: the stored procedure in the database, the job scheduled on the server, the integration that exists only in a config file, the verbal agreement with the operations team.

So the practical rule is: treat AI output as a hypothesis, never as documentation. Every extracted rule needs confirmation from someone in the domain, or a test that exercises it against the running system.

The strangler fig is still the pattern

Martin Fowler described the strangler fig pattern from a literal image: the plant grows around the host tree until it replaces it, without ever felling it in one go.

Applied to software, it means putting a routing layer in front of the old system and moving functionality to the new one in slices, one at a time, with the option to back out of each slice. AWS publishes prescriptive guidance for the same pattern with implementation detail, for teams that need a concrete path.

AI does not replace the pattern, it accelerates it. It helps decide which slice is least coupled, generates the adapter code between the two worlds and keeps both versions in parity during the transition.

A full rewrite is still a bad idea

The temptation is obvious. If AI writes code fast, why not rewrite everything?

Because what makes a full rewrite dangerous was never typing speed. It is the loss of knowledge accumulated over years of fixes, the feature freeze during the transition and the inability to validate equivalence across one large jump.

Thoughtworks' Technology Radar has been recording this caveat about large-scale code generation: high volume without proportional review creates a new system nobody understands, which is the same problem as legacy, only without the years of stability.

Refactoring is still the discipline that holds the result

Martin Fowler's refactoring catalogue describes small behaviour-preserving moves, each one verifiable.

That step size is not fussiness. It exists because a mistake in a small step is found in minutes, and a mistake in a large step is found in production. With AI the temptation is to enlarge the step, since generating five hundred lines costs the same as generating fifty. The cost shows up in review and in the incident, not in the generation.

What this means for your team

Start with archaeology, not with the rewrite. Pick the module that scares people most and use AI to produce an understanding document plus a characterisation test suite. Validate both with whoever knows the domain.

Then pick one small slice and strangle it, with routing in front and rollback available.

If after three months the team understands the legacy better than it did and has replaced two slices without an incident, modernisation is going well. If it replaced ten and nobody can explain the rules, the problem has only moved.