Every legacy modernization starts with the same uncomfortable fact: nobody fully knows what the old system does. The people who wrote it have moved on. The documentation, where it exists, describes the system as it was designed decades ago, not as it runs today. So, programs either spend months on discovery before changing a line or skip it and find out in production.
Generative AI has changed the pitch. Vendors now promise to convert COBOL to Java, or a tangled monolith to modern services, in a fraction of the time. Conversion is the part that demos well. It is also where AI is least reliable, and it is worth little if nobody understands what is being converted.
Translating code you don't understand moves the mess into a new language.
This piece is part of our guide to how AI is changing software delivery. Let's cover where AI genuinely changes the economics of modernization, why understanding has to come before conversion, and what a discovery-first program should produce.
Discovery Was Always the Bottleneck
In most modernization programs, writing new code is not the slow part. Working out what the old code does is. Business rules sit inside programs nobody has opened in years. Dependencies run through shared files and overnight batch jobs. Whole modules survive only because no one is sure they can be switched off.
This is where AI changes the economics. A model can read millions of lines, explain each program in plain language and trace how data moves between them, far faster than any team of specialists. That is where AI legacy code modernization earns its keep.
The organizations reporting results use it that way. CIO Dive reports that Morgan Stanley has modernized more than 17 million lines of COBOL, Natural and Perl into Java and Python with its in-house DevGen.AI platform, saving developers more than a million hours. The bank describes the platform's core job as reverse engineering old code into a clear design that engineers then build from, with human oversight throughout. In the same report, AWS Transform's vice president makes a related point: AI-driven mainframe modernization depends on reverse engineering as much as forward engineering.
What AI Does Well, and Where It Still Needs People
The limits matter as much as the strengths. Gartner predicts that more than 70% of mainframe exit projects started in 2026 will fail to deliver their intended benefits because organizations overestimate what generative AI tooling can do. Coverage of the underlying research notes Gartner's view that the technology is genuinely useful for finding and describing technical debt, but limited when it comes to converting legacy code automatically.
Split the work into tasks and the pattern is clear.
| Task | What AI Does Well | Where People Still Decide |
|---|---|---|
| Documenting business logic | Reads each program and explains in plain language what it does and which rules it applies | Whether those rules are still the ones the business wants |
| Mapping dependencies | Traces calls, shared data, batch jobs and interfaces across the estate | Where to draw the boundaries between new services |
| Finding dead and duplicate code | Flags programs, paths and fields that nothing calls or reads | Confirming against production usage before anything is removed |
| Building a behavior baseline | Proposes characterization tests that pin down how the system behaves today | Which current behaviors are defects to fix rather than preserve |
| Converting code | Produces a first draft in the target language | Architecture, design quality, performance and sign-off |
The first four rows compress discovery from months to weeks. The last row is where most of the risk sits, and where expectations most often run ahead of results.
Why Translation Without Understanding Fails
Converting first and understanding later looks faster on a plan. In practice, it fails in predictable ways.
- Dead Code Gets Migrated: Large estates carry programs and paths that nothing uses. Convert them and you pay to test, run and maintain them in the new stack.
- Hidden Rules Break or Get Frozen: A rounding convention or an exception for one customer segment either fails silently or is carried forward without anyone asking whether it still applies.
- The Old Structure Survives: Line-by-line conversion keeps the monolith's shape. The result is often old procedural code written in a modern language, which is harder to work with than either.
- Nobody Can Prove Equivalence: Without a record of what the old system does, there is no baseline to test the new one against, and cutover becomes a leap of faith.
- Technical Debt Moves Instead of Shrinking: The debt is restated in a new language, often with fewer people who understand its quirks.
Modernization that avoids these traps starts with understanding. That is how our legacy modernization work is structured.
What a Discovery-First Program Produces
Discovery should produce evidence the whole program can rely on, not a slide summarizing the estate. AI does the heavy reading, and subject experts confirm what it finds.
- A System Map: Every program, job, data store and interface, with dependencies traced and actual usage measured.
- A Business Rules Catalog: Rules extracted in plain language, each linked to the code that implements it and confirmed by the people who own the process.
- A Retirement List: Dead and duplicate code identified and checked against production logs, so it can be switched off before anyone pays to move it.
- A Behavior Baseline: Characterization tests and captured production scenarios that define what "working the same" means at cutover.
- A Data Picture: Schemas, record layouts and job control read alongside the code, because the data usually outlives every application built on it.
On The Pivot, this is the Discover stage doing real work. Every later decision, from architecture to wave planning to testing, draws on what it finds.
Then Decide What Each System Needs
Once a system's behavior is documented, the path decision rests on evidence rather than assumption. Discovery often changes the plan.
Some components turn out to be unused and can be retired. Some are stable and better modernized where they run; Gartner itself suggests that for many mainframe customers, generative AI is more useful for modernizing in place than for speeding an exit. Some are rebuilt on a modern architecture from the extracted rules, rather than translated line by line. Some standard functions are better replaced by a product. For systems moving to the cloud, the same evidence feeds the migration plan.
Most of this application modernization can happen incrementally, replacing one capability at a time while the old system keeps the business running. The understanding built in discovery is what makes that safe.
Six Questions to Ask Before You Approve a Modernization Plan
These work for a plan written in-house or one proposed by a partner. Each is far cheaper to answer before conversion starts than after.
- Do We Know What the System Does Today, in Writing? Or is the plan based on documentation nobody has checked against the code?
- Have the Business Rules Been Extracted and Confirmed? By the people who own the processes, not just by the tool.
- How Much of the Estate Is Unused? And will it be retired before anyone pays to migrate it?
- What Is Our Baseline for "Working the Same"? Which tests and captured scenarios will prove equivalence at cutover?
- Is AI Being Used Mainly to Understand, or Mainly to Convert? If the plan leads with conversion speed, ask what happens to design and quality.
- Does the Target Architecture Come From Us or From the Tool? Conversion tools are often built to land you on their vendor's stack, which may not be where you want to be.
If a plan cannot answer the first two, it describes a translation project, not a modernization.
Read First, Then Rebuild
AI has made the hardest part of modernization, understanding what you already have, faster and cheaper than it has ever been. Use it there first. The conversion will go better, the architecture will be your own, and the business will know what it is getting before it pays for it.
If you are facing a legacy estate nobody fully understands, start with a code discovery. You get a system map, a business rules catalog and a retirement list before any decision on what to move or rebuild. Book a code discovery or see how we approach legacy modernization.
