Legacy Code Modernization With AI: What a Six-Week Assessment Actually Tells You

The most quoted number in this field is that AI made experienced developers 19% slower while they believed it made them 20% faster. It is a real finding from a randomized trial, and the research group behind it has since moved on from it. In a February 2026 update, METR reported speedup estimates for developers in its follow-up study, while cautioning that selection effects make those new numbers unreliable. What survived the reversal is the part that matters for anyone planning a modernization project: developers cannot accurately estimate their own productivity, and AI widened that gap in both directions. This is legacy modernization meets genAI, and the first casualty is the estimate.

Which is the whole argument for assessing before committing. This article covers what a six-week code assessment produces, why AI changed what is possible at the analysis stage more than at the rewrite stage, how to read a legacy codebase you did not write, and what a defensible plan to modernize contains. It is written around AI-assisted analysis as it actually works, not as it demos. Written for the CTO or VP Engineering who has been asked for a number and does not want to invent one.

Why does every modernization estimate turn out wrong?

Because the estimate is built on the parts of the system people remember. Ask a team to scope a legacy application rewrite and they will describe the parts they touched recently. The parts nobody has opened in six years, the integration nobody documented, the batch job that runs at 3am and quietly feeds three downstream systems, none of that is in the estimate because none of it is in anyone's head.

The evidence on developer self-assessment is unflattering and now fairly robust. MIT Technology Review's summary of the research covers the METR trial alongside GitClear's finding that code quality measures declined even as output rose, and Stack Overflow's survey showing developer trust in AI tools falling for the first time. The perception gap is the durable result. The direction of the productivity effect is not.

So the purpose of an assessment is to replace intuition with measurement. Not to produce a plan, at first, but to produce the facts a plan needs: what exists, what depends on what, what still runs, and what nobody understands. Everything else in a modernization journey follows from that inventory. An AI legacy system assessment is the cheapest way to get it, and the modernization process should not start before you have one.

What has AI actually changed about legacy code modernization?

Analysis, far more than generation. Reading code has always been the expensive part of modernizing legacy estates, and it is the part where language models genuinely excel. A model can work through millions of lines of undocumented code and produce a description of what a program does in hours rather than the weeks a human archaeologist would need. Lines of code processed is one of the few AI metrics that means something here, because a million lines of legacy code is a scale no human team reads.

Code generation is the noisier half of the story and the weaker one. GitClear's analysis found duplication rising sharply while refactoring collapsed as a share of code changes, with copy-paste exceeding reused code for the first time in their measurement history. Applied carelessly to a legacy application, AI accelerates the accumulation of technical debt rather than reducing it, because generated code solves the immediate problem without abstracting anything. Writing code faster is not the constraint in software modernization; understanding old code is.

The tooling reflects this split. IBM built watsonx Code Assistant for Z around a sequence of understand, refactor, transform, and validate, with the understanding stage first for a reason. AWS Transform for mainframe starts with assessment and business-logic extraction before any code is refactored, and Amazon Q Developer's code transformation handles Java version upgrades as a bounded, mechanical migration. The pattern across every serious vendor is the same: comprehension before code conversion.

What do you get in week one and two: inventory and dependency mapping?

A complete picture of what exists, which most organizations have never had. Every repository, every deployed artifact, every scheduled job, every database, every integration point. Automated AI code analysis does the first pass across the delivery pipeline and every workflow that touches production, and the surprises are consistent: repositories nobody can attribute, services running from a build nobody can reproduce, and a dependency graph far denser than the architecture diagram suggests.

Dependency work is the highest-value output of this phase. You need internal dependencies between modules, external library dependencies with their support status, and runtime dependencies on services and data. Third-party dependency risk belongs here too, and the provenance discipline in NIST's supply chain risk management guidance is the right standard for deciding what is safe to carry forward.

Unreachable code identification lands in the same fortnight and is usually the first piece of good news. In most legacy software a meaningful fraction of the source code is unreachable, and a modernization effort that carries it forward is paying to migrate something nobody executes. Finding it early shrinks the scope of everything downstream and reduces the code work in every later phase.

Week three and four: how do you recover business logic nobody documented?

By reading the code and asking the model to explain it, then having a human check the explanation against behavior. This is where AI-powered legacy analysis earns its place. A model reading COBOL code or twenty-year-old Java can articulate the business rules embedded in it, including the special cases that were added for one customer in 2011 and never written down.

Treat every AI output as a hypothesis. The model will confidently describe logic that does not match production behavior, particularly where the real rule lives in configuration, data, or an operator's habit rather than in the program. Your engineering teams verify AI findings against logs, test data, and the people who still remember. What comes out is documented logic, which is an asset regardless of whether you modernize at all. It is also the input you need to modernize legacy systems safely rather than optimistically.

Prioritize by consequence. Pricing, eligibility, billing, and regulatory calculations get exhaustive treatment; a reporting routine gets a summary. Modernization of legacy systems fails most often on a business rule nobody knew existed, discovered after cutover, and the point of this phase is to move that discovery forward by two years.

Week five and six: what does the modernization roadmap contain?

Options with numbers attached, not a recommendation. For each component, a decision: leave it, wrap it behind an API, refactor in place, rewrite, or replace with a product. Each specific modernization option carries an effort range, a risk rating, and an explicit dependency order, because sequencing constraints are what turn a tidy plan into an eighteen-month surprise.

The plan should be honest about what a rewrite costs. Full rewrites of a large legacy system have a poor track record, and the strangler pattern of incremental replacement behind a stable interface is usually the better modernization path even though it looks slower on paper. Where a plan calls for a big-bang replacement, the assessment should say why that case is different.

It also needs a cost of doing nothing. Support expiry dates, unpatchable dependencies, recruitment difficulty for the language, and the specific operational risks you are carrying. Those numbers are what turn the modernization decision into a business conversation rather than an engineering preference. Boards approve a case to modernize; they rarely approve a case to refactor. Our code modernization practice runs this as a documentation-first sequence for that reason, and the full method sits in our pillar on legacy application modernization.

Why six weeks rather than two, or six months?

Two weeks buys an inventory and nothing else. You will know what exists and have no idea what it does, which produces a plan built on file counts. That is how organizations end up estimating a program by lines of code, a metric that correlates with almost nothing useful. Existing code volume tells you about effort only after you know which parts still run.

Six months is a different failure. Assessments that run half a year produce documents describing a system that has since changed, and they consume the budget and patience that the actual work needs. There is also a political cost: a long assessment reads as avoidance, and the engineering teams being assessed start to disengage.

Six weeks is roughly the point where AI-assisted analysis has processed the codebase, humans have verified the high-consequence findings, and the options are concrete enough to price. It also fits inside a quarter, which matters more than it should when you are trying to get approval to modernize anything at all.

What does AI-assisted code migration realistically deliver?

Useful acceleration on bounded, mechanical work. Version upgrades, framework migrations, translating code between languages where the semantics map cleanly, and test generation are all areas where automated code transformations save real time. IBM says its tooling produces high-quality Java from COBOL, and the tooling has improved considerably. Modernizing Java legacy applications through version upgrades is now close to routine, with minimal code written by hand.

Where it disappoints is anything requiring judgment about what the code should do rather than what it does. A faithful translation of a badly designed component produces a badly designed component in a new language, and you have spent the migration budget without improving anything. That is the trap in COBOL modernization specifically: converting to Java without redesigning gets you the same monolith with a larger talent pool, and a new system that inherits every constraint of the old one.

Production-safe AI-generated code needs the same controls as any other. Code reviews do not get shorter because a model wrote it, and the evidence suggests they should get longer, since AI-assisted pull requests carry around 1.7 times as many issues as human-only ones and wait far longer to be picked up for review. Budget for verification proportional to consequence, not to how quickly the new code appeared.

How do you handle systems where nobody understands the business logic?

Start with observed behavior rather than intent. Instrument the running system, capture inputs and outputs across each workflow, and build a behavioral specification from what it actually does. That specification becomes your acceptance test for anything replacing it, and it is valid even where the original intent is permanently lost.

Then use the model for archaeology against that baseline. Asking AI to analyze code and explain a module is far more reliable when you can check the answer against recorded behavior. This combination, behavioral capture plus AI explanation plus human verification, is the most effective approach we have found for genuinely undocumented systems.

Accept that some logic will stay opaque. A pragmatic strategy wraps what you cannot understand behind a stable interface, freezes it, and modernizes around it. Working effectively with legacy code sometimes means deciding not to touch a module for another five years, and saying so explicitly is better than pretending a full enterprise modernization is achievable in one pass.

What should a modernization assessment cost and produce?

The deliverables are what to judge it on. A system inventory with ownership. A dependency map. A documented set of business rules for high-consequence components. A quality and risk profile. A set of options with effort ranges and sequencing. And a cost of inaction. If a proposal does not name those artifacts, it is selling a discovery workshop.

Relative to the program it scopes, an assessment is small. It is a fraction of the cost of the modernization work itself and a much smaller fraction of the cost of getting the scope wrong, which is the failure mode that turns a twelve-month program into a thirty-month one. Organizations that rush to modernize usually skip it because assessment feels like delay, and then spend the saved time discovering the same facts under deadline pressure.

The same discipline applies when the application is heading to the cloud rather than staying put, which we cover in our cloud migration guide. Insist on portability. The output should be usable by any implementation partner, including your own team, rather than structured so only the assessor can act on it. That is a reasonable thing to ask for in the contract and a useful test of who you are dealing with.

Where does agentic modernization fit?

At the edges, carefully. Agentic systems that can read a repository, propose changes, run tests, and iterate are genuinely useful for mechanical work at scale: dependency upgrades across many repositories, consistent modernization patterns applied to refactor legacy code at scale, and test backfill. That is real value and it is arriving quickly.

What they are not yet suited to is autonomous decision-making about architecture in a system with poorly understood behavior. An agent optimizing for passing tests in a codebase with thin test coverage will produce changes that pass and break things nobody tested. The constraint is not AI capability, it is the quality of your verification, which is exactly what the assessment establishes.

The sensible sequence is assessment, then behavioral test coverage, then agentic work inside that safety net. Teams that invert it get speed without confidence. We work through the broader governance question in our framework guide for governing AI, and the same logic applies to agents operating on production code.

What separates a successful modernization from a stalled one?

Knowing what you have before deciding what to do. That is the entire thesis, and it sounds obvious until you count how many legacy modernization programs begin with a target architecture and work backward. Starting from the destination produces an enterprise application modernization strategy that fits the slide and not the system. System modernization has to begin with the system.

Incremental delivery is the second factor. Modernization efforts that ship value every quarter survive leadership changes and budget cycles; ones that promise a big reveal in year two usually do not get to year two. Sequence the work so each phase is independently useful, even if the total takes longer.

The third is honesty about the parts you will not fix. Every large estate has components that are not worth modernizing, and a plan that quietly assumes otherwise will miss its dates. Naming them early is what makes the rest of the modernization plan credible, and credibility is what keeps it funded.

Find out what you are actually dealing with

Our Hotspot Analysis is the six-week assessment described above, delivered as an inventory, a dependency map, documented business rules for your highest-consequence components, and a costed set of options. You get artifacts your own team can act on, whoever does the implementation.

If you have been asked to put a number on a modernization program and you do not yet have one you would defend, that is the conversation to have before the number gets quoted. For the raise-adjacent version of this problem, see our companion piece on modernizing fintech platforms before a funding round.

Key things to remember

• Developer estimates are unreliable, and AI made them more so. The perception gap in the research is more durable than any specific productivity figure, including the widely quoted 19% slowdown, which the same group has since revisited.
• AI changed analysis more than it changed generation. Reading a legacy codebase is where models genuinely help; writing replacement code is where they add debt if unsupervised.
• Every serious vendor sequences understanding before transformation. IBM, AWS, and the rest all put comprehension first.
• Weeks one and two produce the inventory and dependency map, including dead code you can stop paying to migrate.
• Weeks three and four recover business rules. Treat every AI explanation as a hypothesis to verify against production behavior, not as documentation.
• Weeks five and six produce options with effort, risk, and sequencing, plus an explicit cost of doing nothing.
• Six weeks is the sweet spot. Two produces a file count; six months produces a document about a system that has changed.
• AI-assisted migration works on mechanical, bounded transformations. A faithful translation of a bad design is still a bad design.
• Where behavior is undocumented, capture it by instrumenting the running system. That specification is your acceptance test regardless of what you build.
• Assessments should be portable. If only the assessor can act on the output, that is a commercial choice, not a technical necessity.