LLM Code Analysis vs. Data Lineage: Choosing the Right Tool for Legacy System Modernization

On June 18, 2026 Gartner published a prediction that should make every CIO sponsoring a mainframe exit pause:

“More than 70% of mainframe exit projects initiated in 2026 will fail to produce the intended benefits due to an overestimation of generative AI (GenAI) tooling capabilities.”

I agree with Gartner. We see it every week.

Gartner’s recommendation underneath the headline

It’s worth clarifying what Gartner means. Mainframe modernization encompasses both migrating off the platform and modernizing in place. The 70% failure figure applies specifically to full exits. For most workloads, Gartner is recommending in-place modernization instead.

The 70% figure will generate most of the talk, but the body of the release is making a sharper point.

“For many mainframe customers, GenAI can be more effectively used to enable modernization in place rather than accelerate migration off the platform.” — Alessandro Galimberti, VP Analyst at Gartner

Gartner is recommending a platform-smart approach – evaluating workloads individually and placing them in the right environments, rather than chasing a wholesale exit. Organizations should balance strategies focused on optimizing existing mainframe investments while limiting full platform exits to select, case-by-case scenarios – efforts that, in Gartner’s words, require high-risk transformation and often result in suboptimal outcomes.

That isn’t a story about better migration tooling. It’s a story about asking better questions and a fact-based assessment before the migration question is even on the table.

What GenAI can and can’t do in a mainframe exit

Gartner contends that the high failure rate is due to the expectation that generative AI will fix complex legacy code easily. Based on my experience with multiple transformation initiatives involving mainframes, I’ve observed and dealt with what generative AI can and cannot do well.

What GenAI can do well: read code at scale, surface technical debt, summarize what a module appears to be doing, generate first-pass documentation. It’s useful and time-saving work.

What GenAI can’t do, at least not reliably, in a mission-critical mainframe environment:

• Tell you why a calculation produces the result it does today.
• Provide reliably consistent and complete explanation, especially when functional threads traverse nested modules.
• Tell you what a branching condition in a COBOL module is actually checking against, and what business rule that condition encodes.
• Tell you whether a hard-coded value in a 1998 program was a temporary patch or a deliberate business decision that downstream systems now depend on.

These gaps – between code description and business meaning – are where mainframe exit projects fail. And it’s these gaps that a generative model, however capable, can’t close on its own.

The cost of not understanding what’s there – today

The Gartner finding focuses on exits – but the cost of not understanding your mainframe shows up long before any exit project starts.

Every time a business requirement changes – a new regulation requires a different calculation methodology, a product team needs to update how interest is accrued, an auditor asks where a number came from – someone has to go into the mainframe and answer the question. Before they can change a single line of code, they need to trace what the change will affect: which modules read the variable, which tables get updated, which downstream processes depend on the output, which conditional branches treat it differently.

In a typical environment, that investigation can take weeks or months – and it depends on a shrinking pool of mainframe specialists who are simultaneously running the system. The risk of getting it wrong is real: unintended consequences that show up weeks later in a reconciliation break or a misstated customer statement.

This is the recurring cost the modernization conversation usually skips over. It’s the cost of operating the mainframe without visibility into it – every quarter, every change request, every audit cycle. The 70% of exits that will fail isn’t the only story. The other story is the daily tax that organizations are paying for systems they can’t fully explain.

Explainability is the precondition

Explainability is what makes data AI-ready in a regulated environment. The same principle applies to legacy systems: a system is decision-ready – for modernization, for regulators, for the next code change – when you can explain, with traceable evidence, how it produces what it produces.

Gartner’s framing is correct: AI is being asked to do work it cannot reliably do. But the deeper lesson in the 70% failure number is that the work AI is being asked to skip is the strategic work that determines whether the right path was chosen in the first place. And that work pays for itself long before modernization day – it pays for itself every time the business asks a question the mainframe is supposed to answer.

What the teams who get this right are doing

The mainframe programs that succeed – whether the answer is a full exit, modernization in place, a hybrid, or just running the system safely for the next several years – share a pattern. They treat understanding the legacy environment as a first-order capability, not a one-time pre-migration task.

They invest in surfacing the actual business logic embedded in mainframe code – the calculation logic, the conditional branches, the field-level relationships, the cross-module dependencies – before they decide what to replicate, retire, redesign, or leave alone. That investment doesn’t just serve the eventual migration. It makes today’s mainframe safer to manage, today’s regulatory questions faster to answer, and today’s code changes less risky to make.

At one Fortune 100 financial institution where Zengines Contextual Data Lineage is used every day, the team’s question started with “For each module that touches a regulated calculation, what does it actually do, and what depends on it?” That question scopes an honest mainframe modernization program – what to exit, what to modernize in place, what to leave alone, and how to operate the mainframe safely in the meantime.

The difference isn’t only faster code conversion. The difference is that they know what they have – every day, not just on modernization day.

Mainframes aren’t going anywhere

Despite the industry’s push toward cloud migration and modernization, many financial institutions still rely on mainframe systems to process millions of daily transactions, calculate interest accruals, manage account records, and run core business operations. And they will for years to come.

Modernization is the eventual reality for most organizations still running on mainframes. For many financial institutions, a full modernization effort is on the roadmap but years away – dependent on budget cycles, vendor timelines, regulatory considerations, and a hundred other competing priorities. For others – and this is increasingly what Gartner is pointing toward – modernization will mean working with the mainframe, not off of it.

Either way, the system runs every day in between. And every day, it has to be safely managed, changed, audited, reconciled, and explained.

How Zengines bridges today and tomorrow

This is the bridge Zengines was built to be.

Zengines Contextual Data Lineage parses COBOL, RPG, and PL/1 at scale and surfaces what is actually inside legacy code: the data paths, calculation logic, conditional branches, hard-coded values, and module-to-module dependencies that determine how a legacy system produces what it produces. Analysts get the answer to a reverse-engineering question in minutes – in plain English, with business context – instead of waiting weeks for a mainframe SME to dig through code by hand.

That visibility pays off on two timelines. Today, it makes the mainframe safer to manage: business requirement changes get scoped accurately, regulators get answers in hours instead of months, and engineers can make code changes with confidence about the blast radius. Tomorrow, whenever modernization day arrives – whether that means a full exit, modernization in place, or a workload-by-workload approach – the team isn’t starting from scratch. The understanding is already there.

The mainframe isn’t the problem. The lack of visibility into it is.

If you are managing a mainframe today, planning to modernize tomorrow, or – as Gartner is increasingly suggesting – deciding whether modernization should mean staying on the platform and changing how you work with it, we’d like to show you what Contextual Data Lineage surfaces in your environment.

Get a demo →

In this episode of the Finovate Podcast, host Greg Palmer sits down with Caitlyn Truong, CEO and Co-founder of Zengines, fresh off the company's Best of Show win at FinovateSpring 2026.

Caitlyn traces her path from hardware and software engineering in telecom to financial services consulting, where she and her co-founders kept running into the same gap: critical business logic locked inside legacy core applications written in COBOL, RPG, and PL/1. With 92 of the top 100 banks running COBOL mainframe cores and over half of credit unions and regional banks operating on RPG cores, that black box isn't an edge case — it's the industry norm.

Key points from their discussion

• Beyond pathway tracking: Traditional lineage tools show where data travels. Zengines Contextual Data Lineage ingests entire legacy codebases to reveal not just what happens to data, but why and how — the calculations, conditions, and business rules embedded in the code itself.
• Answers in seconds, not months: Business analysts, data analysts, compliance teams, and technical staff get self-service answers to questions that previously required waiting on scarce subject matter experts.
• Three use cases driving urgency: Meeting regulatory compliance requirements, de-risking modernization and transformation programs, and making legacy data AI-ready with the trust and traceability regulated institutions need.
• The Finovate experience: Caitlyn shares how the Sherlock Holmes-themed demo brought "shining a light into the black box" to life on stage — and her advice for first-time demoers on using seven minutes to plant hooks that turn into real booth conversations.

Listen to the full episode

Watch the demo replay

There is a rule that has been on the books for over a decade, and almost nobody outside of risk and compliance teams has ever heard of it: BCBS 239. It is not a catchy name. But the idea behind it is one of the more sensible things to come out of the post-2008 regulatory response: banks should be able to explain where their risk numbers come from.

Not approximate. Not eventually. Be able to trace a number back to its source, on demand, and show the path it took to get there.

That standard came into force for the world’s largest banks in January 2016. Almost ten years later, only a handful of the 31 global systemically important banks (G-SIBs) have reported full compliance. And the cost of falling short is no longer theoretical: the penalties for BCBS 239 failures now run into the billions. The ECB’s RDARR Guide, published in May 2024, named data lineage as one of seven priority areas still holding institutions back, and said it expects remediation work to continue through 2027.

I want to make the case that this isn’t a story about banks dragging their feet, or regulators failing to enforce something. It’s a story about a rule that was right, running into a technical wall that was real.

The wall was real

If you’ve spent time around a bank’s core systems, you already know what the wall looks like. Decades of COBOL or RPG, written and rewritten by people who retired years ago, running calculations that nobody currently on staff can fully explain. Ask a team to trace how a specific risk figure was derived, and the honest answer is often: we’d need a few months, and a few of our most senior mainframe engineers — who are also the people we can least afford to pull onto this.

That’s not a compliance excuse. It’s a real description of how these systems work. Logic gets buried inside modules that branch into other modules, which branch into more, written in a language most engineering schools stopped teaching in the 1990s.

So banks have been stuck between a standard they understand and largely agree with, and infrastructure that makes meeting it genuinely hard. Regulators have been patient about this — I think correctly — because the alternative, demanding visibility into systems that were close to a black box, wasn’t realistic.

What’s changed

I run a company called Zengines. We built technology specifically to deal with this wall: parsing legacy code at scale, tracing how data moves through mainframes and AS/400 applications, and surfacing the business logic that’s been buried inside them for decades — with the context needed to make it usable.

At one Fortune 100 financial institution, we’re currently working through hundreds of thousands of COBOL modules, some of them tens of thousands of lines deep, netting out to tens of millions of lines of code. Questions that used to take a mainframe specialist months to answer — tracing a variable by hand through branch after branch — can now be answered in seconds. An analyst can ask the system directly where a number came from, instead of opening a ticket and waiting. That same self-service access lets teams build their own understanding, and answer questions from regulators and transformation programs directly.

I’m not suggesting this solves everything BCBS 239 asks for. Governance, and the behavioral discipline of actually using data management tools once you have them — those still take sustained organizational effort, and always will.

But the specific claim that legacy mainframes are too opaque to document fully? That claim is no longer true, at least not in the way it used to be.

Why this matters beyond one regulation

I’d guess most people reading this don’t work in regulatory compliance.

If you’re a CDO, a CIO, or a risk leader at a bank with a mainframe at its core, BCBS 239 is probably one item on a long list. But the underlying question — can we actually explain how our own systems work? — isn’t a regulatory question. It’s a basic operational one. It’s the same question that determines whether you can trust the data going into a new AI initiative, whether you can defend a number in front of your own board, and whether the next system migration breaks something nobody saw coming.

Lineage has quietly become a prerequisite for almost everything banks are now trying to do with their data. Most executives don’t ask for it directly, because they don’t think to ask — they ask for the AI use case, or the modernization roadmap, or the faster reporting cycle, and lineage turns out to be the thing standing between them and any of it.

Where I land

I don’t think this is a story that needs villains. The standard was right. The barrier was real. What’s changed is narrower, and more hopeful: the wall that made the standard so hard to meet has a way through it now.

If you’re a regulator, I’d offer this as something worth knowing: the technical excuse has less weight than it used to. If you’re an executive at a bank still living with this problem, I’d offer something more direct — this is more solvable, and more quickly, than you’ve been told.

Either way, the goal was never the regulation itself. It was being able to look at your own systems and actually understand them. That’s now a lot closer than it’s been in years.

Sincerely,

Caitlyn Truong

CEO, Zengines