Where AI Actually Belongs in Legacy Modernization

TL;DR

• IT leaders under board pressure to "just use AI" for mainframe modernization are walking toward Gartner's 70% failure rate.
• The failure point isn't AI itself, it's using AI as the whole strategy instead of the right tool for the right phase.
• Too much context, too much legacy code, and thin test coverage turn AI-only conversions into expensive guesswork.
• Discovery benefits from AI's pattern-finding at scale; forward engineering, whether into custom code or packaged platforms, needs a deterministic, repeatable specification to work from.
• OpenLegacy pairs both, one validated business process at a time, so modernization stays fast without gambling the core system.

Your board wants a modernization plan built on AI. Gartner just published a number that should make you pause: more than 70% of mainframe exit projects started in 2026 will fail to deliver what they promised, and overestimating GenAI tooling is the named cause.

That's not an argument against AI. It's an argument for knowing exactly where AI belongs in a legacy modernization program, and where a different kind of engineering takes over.

What Gartner's 70% Failure Prediction Means for Your Modernization Program

More than 70% of mainframe exit projects started in 2026 will fail to deliver what they promised. Gartner puts the blame on one specific cause: teams overestimating what generative AI tooling can actually do (Gartner, June 2026).

That's not a small miss. It's the difference between a modernization program that ships and one that quietly stalls eighteen months in, after the budget is spent and the board has already been told it's working.

The prediction isn't a case against using AI. It's a case against treating AI as the entire modernization strategy, then discovering the gap between demo and production only after the project is already underway.

The teams in the 70% aren't failing because they used AI. They're failing because they asked one tool to do every job in the project, including the ones it's not built for, with no deterministic backstop when it came up short.

That distinction, between AI as one part of the plan versus AI as the whole plan, is where the next section picks up. Because the real question isn't whether GenAI belongs in your modernization program. It's where.

Why "Let AI Handle the Migration" Sounds Like a Plan, and Isn't

A full AI-driven migration is an appealing pitch. Point the model at the COBOL, get modern code back, done. In practice, that pitch skips over what actually breaks first.

Around 80% of core-banking migration projects fail, and the most common cause isn't the technology doing the converting. It's incomplete or incorrect data going in (Karl im Brahm, CEO DACH, Objectway). AI tooling doesn't fix that problem. It inherits it.

A mainframe program built over twenty or thirty years carries business rules that were never written down anywhere except the code itself. Ask an AI model to convert that code without first validating what the code actually does in production, and it will confidently convert the rules as written, gaps, quirks, and all, along with everything the team never noticed was undocumented in the first place.

So the failure point isn't the AI's ability to generate code. It's asking it to generate the right code before anyone has validated what "right" means for this specific business process.

That's a sequencing problem, not an AI-capability problem. And it's exactly why the next question matters: what happens when the thing you're migrating isn't a clean, well-documented function, but the actual mess of a decades-old mainframe estate.

Too Much Code, Too Much Context, and the Costs That Come With It

A single mainframe application can run to millions of lines of COBOL, PL/I, or RPG, built up over three or four decades by hundreds of different developers. That scale is exactly where GenAI tooling starts to strain.

Large language models (LLMs) work by holding relevant context in a window and reasoning across it. Feed in one well-scoped module or business process, and results are often strong. Feed in an entire legacy estate, with cross-program calls, shared copybooks, and business rules that live three layers deep in nested logic, and accuracy tends to drop as the context grows.

That strain shows up in three concrete costs:

• Time. A well-scoped module or business process converts in a predictable window. An entire legacy estate doesn't scale the same way, and without a clear stopping point, an AI-only conversion can run far longer than planned, with no guarantee it ever reaches a finished, verified state.
• Token burn. Converting one well-scoped module or business process might cost a few dollars in model usage. Multiply that across a legacy estate with millions of lines and heavy cross-program dependencies, and the AI-only approach can turn into a very different budget line by the time the project reaches full scope.
• Testing gaps. Many mainframe systems were built before automated testing was standard practice, so there's often no reliable safety net to catch what an AI-driven conversion gets wrong. A model can generate code that runs without errors and still silently changes what the business logic actually does, and nothing in the existing test suite will flag it. Someone still has to verify the logic, program by program, edge case by edge case.

None of this means the tooling is unreliable in general. It means time, scale, cost, and verification, not model quality, are the real constraints once a modernization program moves past a single business process and into the full estate.

That's a different problem than most AI-only migration plans account for, and it points straight at what AI is genuinely built to handle well, and where that job ends.

Where AI Actually Earns Its Place: Discovery at Scale

Discovery is where GenAI genuinely delivers. Before any code moves, someone has to answer a basic question: what does this mainframe estate actually do? Across thousands of programs built over decades, with the people who wrote the original logic long since retired, that question used to take months of manual documentation work, some call it analysis paralysis.

This is exactly the kind of problem AI's pattern-recognition is built for. Across a large legacy estate, the ambiguity isn't in one program, it's in how thousands of them connect, overlap, and depend on each other. AI can scan that scale far faster than a manual review, surfacing business flow, dependencies, and risk areas that would otherwise stay buried in undocumented code.

That's not a small convenience. It's the difference between guessing at what a business process does and having an actual, validated map of it before forward engineering ever begins. Skip this step, or rush it, and every decision downstream, what to migrate first, what's safe to decommission, what still needs a human review, gets built on an incomplete picture.

So the case for AI in a modernization program isn't "use it everywhere" or "avoid it entirely." It's "use it where ambiguity and scale are the actual problem," and discovery is that problem.

Once that validated picture exists, though, the job changes. Turning a confirmed business process into working code or a packaged platform isn't an ambiguity problem anymore, it's a consistency problem. And that calls for a different kind of engineering.

Where Deterministic Logic Earns Its Place: Forward Engineering You Can Trust

Once discovery produces a validated business-process specification, the job changes. The question isn't "what might this code mean," it's "turn this confirmed logic into working output, the same way, every time." That's a consistency problem, and consistency is exactly what deterministic, rule-based engineering is built for.

Deterministic generation runs on a fixed specification and fixed rules, not open-ended reasoning. Feed it the same validated input twice, and it produces the same correct output twice. There's no token cost that scales with ambiguity, because there's no ambiguity left to resolve. There's no drift between one run and the next, because there's nothing left to interpret.

That matters most in forward engineering, whether the target is a packaged platform like Salesforce or Pega, or custom code. When forward engineering is grounded in a validated specification rather than open-ended prompting, output stays repeatable and auditable, run after run.

For a risk-averse infrastructure leader, that's the difference between a migration you can explain to a regulator and one you can only hope worked. "It ran correctly last time" isn't an audit trail. "It runs the same correct way every time, and here's the spec that proves it" is.

Deterministic logic isn't the safer choice because it avoids AI. It's the right choice because forward engineering is a repeatable problem, and repeatable problems deserve engineering that's quicker, cheaper, and consistent, not a fresh guess every run.

That pairing, AI where ambiguity and scale are the problem, deterministic logic where consistency is the goal, is the actual answer to Gartner's prediction.

Deterministic Accuracy, AI Velocity: How OpenLegacy Pairs Both, One Business Process at a Time

That pairing, AI where ambiguity and scale are the problem, deterministic logic where consistency is the goal, is exactly how OpenLegacy approaches legacy modernization: one business process at a time, not one bet on AI for the whole estate.

Discovery uses AI-driven pattern-finding to map a legacy estate that's too large and too undocumented for manual review, business flow, dependencies, and risk, surfaced across thousands of programs instead of guessed at. We also narrow the problem down to a more manageable size, one business process at a time. That's what turns discovery into something actionable, not just a map, but a validated, self-contained unit of work someone can actually plan and act on.

Actionable discovery also helps us identify parts that should stay on the mainframe, and expose them as governed APIs, so legacy and modern can run side by side instead of forcing a full cutover on components that don't need one.

Once a business process is validated, forward engineering takes over, and here the approach shifts to deterministic, repeatable logic. For packaged platforms like Salesforce, Pega, or ServiceNow, generation runs on fixed, rule-based logic. For custom code targets, generation is grounded in that same validated specification rather than open-ended prompting. Either way, the output is repeatable and auditable, not a fresh guess every run.

Migrating one validated business process at a time, instead of attempting a big-bang rewrite of the whole estate, is also what keeps the risk profile sane for a regulated infrastructure leader. Each process is a self-contained slice you can plan, estimate, test, and cut over independently, with the legacy system still running underneath until you're ready.

That's the actual answer to Gartner's prediction. Not "avoid AI," and not "avoid deterministic engineering." Use each where it earns its place, and migrate one business process at a time.

Where AI Actually Belongs in Legacy Modernization

Gartner's prediction isn't a reason to slow down. It's a reason to be precise about where AI and deterministic engineering each do their job.

You don't have to resolve that for your entire estate on day one. Start with one validated business process, one with clear boundaries and manageable risk, and run it through actionable discovery, smart integration, and deterministic forward engineering. See the pairing work at a scale you can fully verify before you scale it up.

That's a very different bet than "let AI handle the migration" and hope the budget holds. It's a plan you can explain to your board, your regulator, and your team, with a validated process map, a governed API layer, and repeatable, auditable output to show for it.

One business process, done right, is worth more than a full estate rewritten on a guess.

FAQ

Why do most mainframe exit projects fail? Gartner predicts more than 70% of mainframe exit projects started in 2026 will fail to deliver their intended benefits, largely because teams overestimate what generative AI tooling can do on its own across a full legacy estate, rather than pairing it with deterministic engineering where consistency matters most.

Can generative AI fully automate a mainframe migration on its own? Not reliably at full estate scale. AI is strong at discovery, mapping business logic across thousands of undocumented programs, but forward engineering into working code or packaged platforms needs deterministic, repeatable logic to stay accurate, auditable, and cost-predictable.

What is token burn, and why does it matter in AI-driven code migration? Token burn is the model-usage cost of processing code with AI. A single well-scoped business process is cheap to convert. An entire legacy estate with millions of lines and heavy dependencies can turn AI-only conversion into a much larger, less predictable budget line.

What's the difference between AI-driven and deterministic modernization approaches? AI-driven approaches reason across ambiguous, large-scale context, well suited to discovery. Deterministic approaches run on fixed specifications and rules, producing the same correct output every run, which is what forward engineering into production systems needs.

How does OpenLegacy combine AI and deterministic methods in one project? OpenLegacy uses AI-driven discovery to map a validated business process, then applies deterministic, spec-grounded forward engineering for both packaged platforms and custom code, one business process at a time, so legacy and modern systems can coexist rather than forcing a full cutover.

Is legacy modernization possible without betting everything on AI? Yes. A risk-averse approach validates one business process at a time, using AI where discovery genuinely benefits from it and deterministic engineering where consistency and auditability matter, rather than treating AI as the entire migration strategy.