Modernizing Legacy Code With AI: What Works and What Goes Wrong

The greatest value of AI for legacy systems lies not in rewriting but in understanding. A model can explain undocumented code, make dependencies visible, and write tests for existing behavior: exactly the three things that make modernization plannable in the first place. Automatically translating code into a new language or framework, by contrast, is the riskiest use case.

What Is Legacy Code?

The most useful definition comes from Michael Feathers: legacy code is code without tests. Not old code, not badly written code, but code where you cannot verify whether a change broke something.

This definition is so useful because it names the actual problem. An old system that is well tested can be changed safely. Freshly generated code without tests is, by this definition, legacy immediately, on the day it was created.

Where Does AI Really Help With Legacy Systems?

With three tasks that come before any modernization and that have so far been the most expensive.

• Understanding. A model can summarize a 900-line procedure, list its branches, and name which special cases are handled. That does not replace a review, but it shortens onboarding from days to hours.
• Documenting. Generating a description of the current state from existing code, with the explicit note that it is the current state, not the target state.
• Safeguarding. Writing tests that capture the current behavior. That is the prerequisite for every further change, and the work nobody enjoys doing.

The third point has a catch everyone needs to know: such tests also cement the existing bugs in place. That is intentional, you are securing the behavior, not its correctness, but it has to be clear to everyone involved, or a green test run later gets mistaken for proof of correctness.

Why Is Automatic Rewriting So Risky?

Because the knowledge embedded in old code is not written in the code itself. A condition that looks nonsensical at first glance is often the trace of a real special case: a customer with a different contract, a public holiday, a quirk in legacy data.

A model translating the code into a new language sees this condition as an oddity and will likely simplify it away. The result is more readable, compiles, and passes the tests, and behaves differently in the one case the condition existed for. That case typically only surfaces in production, and the cause is then hard to find because the new code looks correct.

How Do I Approach a Modernization With AI Support?

In four phases, with the first two delivering most of the value.

• Phase 1, mapping. What exists, what depends on what, and what is actually used? AI is strong here and the risk is zero, because nothing is changed.
• Phase 2, safeguarding. Tests for the current behavior of the areas that are about to be touched. Not for everything, just for what is up next.
• Phase 3, encircling. Encapsulate the old part behind an interface and replace it piece by piece instead of swapping it out in one go. The old system stays operational until the very end.
• Phase 4, replacing. Now a model may translate, one building block at a time, with the tests from phase 2 as the yardstick and a human who questions every simplification.

Anyone who starts at phase 4 skips exactly the work that makes the difference between a modernization and an expensive rebuild with unknown behavior.

How Do I Know a Modernization Is Worth It?

By the cost of the changes, not the age of the code. A twelve-year-old system that gets a minor change twice a year is not a problem; it is a fully depreciated investment.

The signals that matter: changes take disproportionately long; bug fixes create new bugs; nobody dares touch certain areas; a requirement can no longer be implemented technically; security updates for the libraries in use are no longer available. The last point is gaining weight, because the reporting obligations of the EU Cyber Resilience Act take effect on September 11, 2026: anyone who must report actively exploited vulnerabilities within 24 hours needs a system in which vulnerabilities can be closed at all.

If you would like support along this path: that is exactly what our SaaS and software development team works on.

Frequently Asked Questions About Legacy Code

At What Point Does Code Count as Legacy?

According to Michael Feathers, from the moment it has no tests. Age plays no role in this definition: code generated yesterday and left without safeguards falls under it too.

Can AI Completely Rebuild an Old Application?

It can build an application that appears to do the same thing. Whether it handles the same special cases is decided by the tests from phase 2; without them you have no yardstick, only a hope.

What About COBOL, ABAP, and Similar Legacy Languages?

For explaining and documenting, models work reasonably well there too. For translation, the same applies as elsewhere, only more so: the more specialized the language, the less training material exists, and the more likely quirks get simplified away.

How Long Does a Modernization Like This Take?

It depends almost entirely on how much needs to be safeguarded in phase 2, and that can only be estimated reliably after phase 1, not before. Any estimate made before mapping is a guess.

In phase 4, everything hinges on whether every simplification gets noticed. Code Guardian checks changes against the existing codebase instead of against the task description: a cold look at the diff that asks what actually disappeared here.

Sources

• Michael Feathers, Working Effectively with Legacy Code (definition: code without tests).
• Regulation (EU) 2024/2847 (Cyber Resilience Act): reporting obligations from September 11, 2026, main obligations from December 11, 2027.

As of July 27, 2026. General professional context, not legal advice.