Can AI Migrate Legacy Code? An Honest Answer

Part 1 drew the map; this part answers the question every technical leader asks first. “Can AI migrate our legacy code?” It is the right question, and it has a precise answer that the marketing around it tends to flatten into a yes or a no. The truth is both, and which one applies depends entirely on which half of the work you mean.

Here is the answer in one line, before the detail: yes, AI converts code — and no, it cannot run your migration. Holding both of those at once is the difference between using AI well and getting burned by it.

What “migrate legacy code” actually involves

The phrase hides a lot of distinct work. Migrating a legacy system means, at minimum: understanding what it currently does; deciding what the replacement should do; translating logic into a modern language and architecture; proving the new behavior matches the old; and cutting production traffic over without breaking the business. Five different kinds of work, and AI is not equally good at any two of them.

When someone asks “can AI do this,” they usually picture the translation step — feed in COBOL, get out clean Java. That step is real and AI helps with it. But it is one link in a chain, and a migration is only as safe as its weakest link. So the useful version of the question is not “can AI translate code” but “can AI carry the whole chain unsupervised.” Those have different answers.

What AI genuinely can do

Start with the honest yes, because it is substantial. AI is genuinely capable at:

• Reading the system. It analyzes large, undocumented codebases end to end and recovers the behavior and business rules nobody wrote down — the part of migration that is slowest by hand.
• Drafting the target. It proposes a modern architecture and a migration plan grounded in your actual code, informed by patterns from many real transformations.
• Translating logic. It produces first-pass equivalents in a modern language, handling the mechanical bulk of converting routines that would otherwise be typed out by hand.
• Generating tests. It drafts the tests that pin a slice’s behavior, accelerating the scaffolding around each conversion.

None of this is hype. On the reading side especially, the gain is large and measurable — AI-accelerated discovery is about 10× faster than manual review, turning a typical 12-week analysis into roughly two weeks. That is an analysis-time gain, scoped to comprehension, not a claim about the whole program. If your mental model of AI migration stops at “it can’t really do anything yet,” it is out of date.

What AI cannot reliably do

Now the honest no. A migration turns on decisions AI cannot make reliably, because they require understanding the business rather than the code:

• What to preserve versus fix. A legacy system is full of behavior that looks like a bug and is actually load-bearing, and behavior that looks intentional and is actually a defect everyone has worked around. Telling them apart is a judgment call about the business, not a pattern in the source.
• Where the boundaries go. Drawing service boundaries that match the domain — not just the current code structure — shapes everything downstream. Get it wrong and you have modernized the mess.
• What to retire. Some of the old system should not be rebuilt at all. Knowing which parts is strategy, not translation.

And there is the failure mode that makes the “no” non-negotiable: AI-generated code is confidently plausible. It compiles, reads cleanly, and can still diverge from the legacy on exactly the undocumented edge cases the migration was meant to preserve. A migration that trusts that output because “the AI wrote it” has not adopted a faster process — it has removed the one check that made the speed safe.

The judgment gap also varies by source stack, which is worth knowing before you assume “modern source language” means “easy for AI.” A self-contained PL/SQL package with clear inputs and outputs is relatively tractable — the behavior is mostly in the code AI can read. A COBOL batch program whose correctness depends on JCL job ordering, VSAM file layouts, and an operator runbook nobody digitized is far harder, because the behavior that matters lives partly outside the source entirely. AI converts the code it can see; the part of the system that was never in the code is the part it cannot migrate, regardless of how capable the model is. That is not a COBOL problem — it is a “decades of context” problem, and the oldest systems have the most of it.

Where AI helps and where it fails, step by step

Put the two answers side by side and the pattern is clear. AI is strong wherever the work is reading or drafting, and weak wherever the work is deciding or proving. Mapped across the five kinds of work a migration actually involves:

Migration step	Where AI helps	What still needs a human	Risk if left to AI alone
Understand the system	Reads the whole codebase and recovers undocumented rules far faster than manual review	Confirming which recovered behaviors are still intended versus accidental	Reads a load-bearing quirk as noise, or a defect as a feature
Decide the target	Proposes architectures and a migration plan grounded in your actual code	Choosing boundaries, and what to preserve, fix, or retire	Faithfully modernizes the mess instead of the domain
Translate the logic	Drafts first-pass equivalents in the modern language, handling the mechanical bulk	Verifying the draft is genuinely equivalent, not just plausible	Confidently plausible code that diverges on the edge cases
Prove parity	Drafts the test scaffolding that pins each slice	Deciding what “identical behavior” means and judging every divergence	Ships unverified, and the divergence surfaces in production
Cut traffic over	Little to offer here	Owning the go-live, the rollback plan, and the live-traffic risk	A big-bang cutover with no fallback when a slice misbehaves

The rule underneath the table is simple. The further right a column reads, the less you want AI acting unsupervised, because the cost of a wrong answer stops being a wasted draft and starts being a production incident.

Why fully autonomous migration fails twice

An end-to-end autonomous rewrite fails for two reasons stacked on top of each other. The first is the judgment gap above — no one is deciding what should be true, so the system faithfully reproduces whatever the model inferred, mistakes included. The second is older than AI: an autonomous rewrite is a big-bang by another name. It is one large, untested bet, proven only at a distant cutover — the single most reliable way modernization programs fail, and the subject of its own article in our legacy-modernization series. Pointing a faster tool at a broken shape just gets you to the failure sooner.

The shape of the honest yes

So AI converts legacy code — under two conditions that turn the dangerous version into the safe one.

First, a human owns the judgment. A senior engineer decides scope, boundaries, and what to preserve; AI accelerates the reading and drafts the building. This is the human-in-the-loop model that Part 6 is devoted to.

Second, every generated slice clears a parity gate before it carries live traffic. The new slice runs against mirrored production traffic, its outputs are compared against the legacy, and any divergence becomes a ticket to resolve — not a surprise in production. Combine that with slice-by-slice delivery behind a strangler facade, where legacy and modern run side by side and any slice can roll back, and the autonomous big-bang becomes a sequence of small, reversible, validated steps. AI supplies the speed; the human and the gate supply the safety.

How to spot the dangerous version

When a tool or vendor pitches AI migration, a few claims separate the safe shape from the one that gets teams burned. Each of these is a signal that the judgment and the validation have been quietly removed:

• “It migrates end to end, hands-off.” This is the autonomous claim in plain words. If no senior engineer owns scope and boundaries, no one is making the calls the migration turns on.
• “It’s 90% automated.” An automation percentage measures typing saved, not risk removed. The fraction it cannot touch is usually the fraction that decides whether the system stays up.
• A speed number quoted for the whole program. The discovery speedup is real and large, but it applies to reading, not to deciding, validating, and cutting over. A whole-migration figure built on it is the easy half sold as the whole.
• No parity gate in the process. If nothing in the pitch compares the new behavior against the legacy on real traffic before cutover, the speed has no safety underneath it.
• One dated go-live with no rollback. That is a big-bang by another name, one untested bet proven only at the switch. AI makes reaching that bet faster, not safer.

If a proposal avoids all five, it is describing the supervised, gated version, which is the one that actually works.

Where this “yes” still has edges

Two caveats keep this answer honest. First, the line between “AI drafts” and “AI decides” is not fixed — models are getting better at the judgment-adjacent work, and some of it will become safely automatable over time. The durable rule is not a list of things AI can’t do this year; it is that nothing ships without validation against the real system. Second, “AI can convert your code” is not the same as “AI will make your migration cheap and fast overall.” The reading gets dramatically faster; the deciding, validating, and cutting-over stay deliberate, because that is where safety lives. Anyone quoting the discovery speedup as the whole-program number is selling you the easy half.

Where this leads

The clearest “yes” in this whole answer was the first one — AI reading the system. That is where the economics genuinely shift, and it deserves a full treatment. Part 3, AI Code Documentation & Reverse Engineering, goes inside the comprehension step: how AI reads a system it has never seen, recovers the rules nobody wrote down, and turns them into living specs the team can actually own.