Mainframe Modernization Case Study: How a Fortune 100 Financial Institution De-Risked Legacy Migration with Contextual Data Lineage

The short answer: a Fortune 100 financial institution moved its core portfolio accounting systems off the mainframe – not as a technical lift and shift, but as a business-led redesign. The scale made manual analysis a non-starter: six people spent nine months decoding just nine COBOL modules, against an estate of more than 80,000 modules. With Zengines Contextual Data Lineage, the team got self-service answers in minutes rather than months, and cut unresolved reconciliation breaks from over 40% to 0.4%.

About the client

The client is a Fortune 100 financial services institution providing wealth management, asset servicing, asset management, and banking to corporations, institutions, and individuals across North America, Europe, the Middle East, and Asia-Pacific.

The division at the center of this program manages core systems supporting custody accounting, portfolio accounting, investment book of record operations, and critical reporting infrastructure. These systems are the backbone of client-facing operations and must deliver absolute accuracy and reliability. At the heart of the estate is the firm’s transaction core – the system that receives or originates transactions, including inbound information, and feeds critical downstream systems including accounting and reporting.

The challenge

After multiple years of robust growth, the business initiated an operations and technology transformation, including a modernization program to migrate its core portfolio accounting and data services infrastructure from legacy mainframe to cloud-based SaaS applications – positioning the firm for continued competitive advantage and growth.

The technical scope was substantial. The full estate had over 60M lines of COBOL code that had evolved and been enhanced across three decades of business operations. The program covered multiple legacy systems, the largest containing over 8M lines of COBOL code.

From a modernization perspective, these systems were “black boxes.” They worked well, but like most mainframe applications of that era, the business logic existed only in the code itself. Understanding exactly what calculations and rules to preserve meant analyzing that code directly.

— Senior Vice President and Implementation Manager

As with many long-running mainframe environments, institutional knowledge of these systems resided with a small group of experienced developers – a common industry pattern that creates execution risk in large-scale transformation programs. The original architects had moved on. Decades of changes had been made by engineers who did not document their work clearly, and the functional footprint covered so many business areas that no single person could hold all of its intricacies.

The knowledge concentration highlighted a key question: how do we de-risk this transformation and accelerate our timeline?

— Senior Vice President and Implementation Manager

The team didn’t know what it needed to know

This is what made the problem structural rather than merely large. Had the scope been “research this area, or those modules,” the work could have been assigned to a small group and finished. But this was a logic and systems conversion spanning customer variation, product variation, operational variation, and logic variation. The team needed comprehensive coverage of any scenario it might encounter – not a targeted read of a known subset.

The arithmetic settled it. In an early attempt, six people spent nearly nine months decoding lineage and dependency information for nine COBOL modules. Against an estate of more than 80,000 modules, traditional documentation approaches would have extended the program timeline well beyond acceptable limits.

Meanwhile, unresolved data and logic reconciliation breaks sat above 40% and stayed on the program dashboard.

The fundamental challenge wasn’t simply migrating data – it was rapidly establishing a comprehensive blueprint and understanding of what the legacy systems actually did. That understanding was what would allow the team to make informed decisions about what to preserve, optimize, or eliminate in the new architecture.

The solution: Contextual Data Lineage

The firm was explicit about what this program was not. It was not a lift and shift, and it was not a project to replicate decades-old logic inside a new architecture and call it modernization.

I don’t want to simply replicate what’s there. I want to redesign it.

— Senior Vice President and Implementation Manager

That distinction changed what the program needed from day one. A pure technical migration treats the legacy system as a black box to be copied field for field. A redesign requires knowing what is inside the box: which calculations are load bearing, which variations are intentional business logic versus accumulated workaround, and where the system could be simplified rather than carried forward as-is. Blind replication would have moved decades of operational and technical debt onto the new platform. Intelligent redesign required the team to understand it first.

That requirement is what Zengines was built to answer. Its capability in schema ingestion, metadata management, and code parsing extends into the legacy code itself, extracting and mapping the business logic embedded in COBOL, RPG, and PL/1 so the team could make redesign decisions based on what the system actually does, not just what it outputs.

What I love about working with organizations like this one is their commitment to solving the real problem, not just the surface one. The client’s team was willing to invest in building the right capability together rather than taking shortcuts. That upfront collaboration created a solution that delivered significant acceleration across the entire program.

— Caitlyn Truong, CEO, Zengines

What Zengines ingests

• Legacy codebases (COBOL, RPG and RPG variants, PL/1)
• Schemas and metadata
• Job schedulers and scheduler information
• External files, inputs and outputs

The result is a comprehensive, navigable information base that changed how the firm’s teams interact with their legacy systems. Instead of waiting for subject matter expert availability to answer questions about code logic, analysts could independently explore the lineage and trace relationships through the system.

One information base, five kinds of analyst

What made the capability compound was that the same information base served several different roles, each of which arrived at the legacy environment with a different question.

• The business analyst. Analysts don’t always know exactly what they’re looking for. They start somewhere and explore before the real question comes into focus. A point-and-click experience lets them navigate every element of the application through its code structure, with profiling information – lines of code, statements, conditional logic and branching – giving an immediate feel for what they’re dealing with. Clicking into any element returns both a deterministic view and a plain-language summary of what it does.
• The compliance and data analyst. For an analyst looking for evidence of connected pathways and proximity impact, lineage is exposed through logic graphs showing how elements connect and interconnect. From any code element they can visually drill up, down, left, or right to understand its relationship along that path or an adjacent one – which is what makes it possible to expose lineage and share evidence with auditors.
• The technology analyst. Technology teams use the same base to understand the system and support test case development – an impact and dependency view of what needs to be understood or tested before any change is made.
• The new teammate. Applications written in languages new engineers have never used are difficult to hand over. A visual and code-based footprint makes it straightforward to show someone how to navigate the system.
• The helpdesk and support analyst. Support teams triaging inquiries against a legacy application can answer directly rather than escalating – resolving questions at the right level instead of pulling scarce SME resources into them.

The results

Once the team could fully understand the existing code and logic, they could make confident, informed decisions about what to migrate, deprecate, or redesign.

My number one goal was to de-risk the program by getting visibility into what was inside these legacy systems before we tried to rebuild them. Zengines gave us that visibility. Everything else – acceleration, optimization – flows from that.

— Senior Vice President and Implementation Manager

Data and logic reconciliation

The team ran data through the legacy systems and the new platform concurrently and compared results. Where breaks appeared, analysts had to understand why the break occurred, where it originated, and how material it was. That work had previously taken weeks or months; with Zengines the answers came back in minutes.

The program’s most visible risk metric followed. Unresolved reconciliation breaks – which had persisted above 40% on the dashboard – fell to 0.4%.

When there’s a data difference or question, we’ve been able to use Zengines to identify what logic was missed. Previously I would have had to go back to the coder and say, “tell me what this code does.” Now I can reference the lineage directly to answer these questions.

— Senior Vice President and Implementation Manager

From tribal knowledge to on-demand knowledge

The shift let analysts investigate discrepancies independently, putting the right people on the right work. Business analysts conduct research, explore functionality, and discover system behavior through lineage analysis, while mainframe SMEs focus their specialized expertise on engineering challenges rather than code archaeology and business translation.

What once required weeks or months of subject matter expert time now happens in hours or days, and business inquiries that used to take months come back in minutes or seconds. The value isn’t in removing the need for expertise – it’s in making that expertise far more efficient.

The result did not stay contained to one team. As other groups inside the transformation program saw the visibility, accuracy, and access their peers now had, they asked for the same, and the capability expanded to further applications across the estate.

Beyond migration

Legacy modernization traditionally requires brute force – teams manually interpreting hundreds of thousands of lines of code. Comprehensive lineage changed the equation. Teams don’t need to analyze everything manually, but complete information is available on demand, enabling more confident decisions about what to preserve, optimize, or rebuild.

We’re starting to think creatively about what else we can leverage this platform for. It’s more than just migration. It’s an enabler for smarter, faster modernization.

— Senior Vice President and Implementation Manager

What this program has proven is that having comprehensive legacy system and data information available on demand isn’t optional – it’s essential for confident modernization decisions. And it’s a model that’s going to help countless other financial institutions approach their own transformations with clarity.

— Caitlyn Truong, CEO, Zengines

Learn more about Zengines

Zengines makes financial services data usable and explainable – through the Turnkey Data Migration Platform and Contextual Data Lineage. See what it surfaces inside your legacy code.

Get a demo →

The short answer: in M&A, value realization waits on the data. Two companies become one legally at close – their systems do not. Until the combined numbers can be trusted, reporting, decommissioning, and synergy capture all stall. The lower-risk path is to run the merge as fast, repeatable dry runs early, so the future-state design gets refined by evidence rather than rebuilt late.

The deal closed.

Now comes the work of bringing it to life: making two organizations operate as one, and realizing the value, benefits, and synergies the M&A deal was built on. A large part of that work is data: the workstream to migrate and bring together everything sitting in each company’s systems.

In M&A, that workstream is the bedrock where value realization grows – the active foundation that powers and adds confidence to all future value growth. The deal thesis assumes you can bring customers, accounts, and operations into a single view. The timeline assumes the systems, processes and data will be ready when the milestones say so. Every week the combined numbers cannot be trusted is a week of delayed reporting, deferred decommissioning, and synergy that stays on the slide instead of landing in the P&L.

Under that pressure, the instinct is to design one source-of-truth destination – one chart of accounts, one customer master, one data model – and migrate the various entities into it. It feels like the shortest line to a single system. The instinct is right; the trap is treating the first version of that destination as final. When the future-state design cannot be refined as the data work uncovers what is really there, the assumptions baked into it tend to surface late: in reconciliations that do not tie, in numbers leadership will not sign off on, in a model quietly rebuilt while the integration clock keeps running.

There is a lower-risk way to run it, built on the mantra “early, fast, and often.” Treat the first migration runs not as the final cutover, but as dry runs: fast, low-stakes passes at combining the two data sets that show you how they actually behave together, what reconciles and what does not, and what the integration will really cost. Each dry run refines the future-state design instead of forcing a rebuild. Ultimately, the data still has to merge. The only question is whether you find out what that takes early, when the design can still flex, or late, when it cannot.

Why the future-state design for merged data needs room to iterate

Every integration needs a starting point — a chart of accounts, a customer master, a data model — to run anything against in the first place. The two systems feeding this merged data set were built by different companies, for different reasons, with their own definitions and their own business rules baked in. Until someone has put those sources side by side and worked through what happens when they meet, the first design is, by definition, a set of educated guesses about how they will actually combine.

If treated as a draft and refined as the data work surfaces what is really there, those guesses do their job – they give you something to test against, and each dry run sharpens the design. If treated as the final answer, they get expensive. The chart of accounts that looked clean does not map one to one. Records that seemed like duplicates turn out to be different entities, or the reverse. A figure that reconciled on its own no longer ties once the two ledgers sit together. When the design has already been signed off, each of these surfaces late, and fixing it means reworking the model and resetting every milestone that depended on it. It is part of why migrations are rarely as tidy as the integration plan assumes.

There is also a decision hiding inside that blueprint that deserves its own scrutiny: whether you are genuinely migrating both companies onto one system and retiring the other, or quietly keeping both alive behind an integration layer. That choice changes the data work entirely, and the difference between migrating and integrating is one of the more consequential calls in the program – better made deliberately than backed into because the model forced the question.

“Early, fast and often” – what the “early” tells you

The alternative is not to skip the model – it is to earn it. Before committing to a design, put the two data sets through migration as if you were combining them for real: not once, but in fast, repeatable dry runs. Each dry run produces a combined output you can actually look at, and each one settles a question the design would otherwise rest on assumption.

Together, the dry runs replace the guesses in the blueprint with evidence – drawn from real data in days, rather than argued over a whiteboard for months.

Knowing the real cost before you commit

For an integration leader, the most valuable thing those data iterations produce may not be the data at all – it is the estimate confidence. Combining the two sets for real, even roughly, shows you how big the job actually is: how much maps cleanly, how much needs work, where the genuinely hard reconciliations live. That turns the integration’s cost and timeline from a number someone guessed during diligence into something grounded in the data itself.

And because the dry runs are fast, the cost of finding out is low. You can test a consolidation approach, see what it produces, adjust, and run it again – well before you have committed the budget, set leadership’s expectations, or told the board when the synergy lands. Testing the assumptions against real data first is simply a safer bet than committing to a design and discovering the surprises afterward, when every change is also a change to the plan.

How Zengines de-risks the integration

This is the work our Turnkey Data Migration Platform was built for. You point the product at both companies’ data, and it runs the combination as a fast, AI-assisted dry run rather than a manual project:

• profiling and classifying each source,
• predicting how the two sets of fields map together,
• surfacing where master data overlaps or conflicts, and
• reconciling the numbers across the two ledgers so you can see exactly where they tie and where they do not.

What comes out is a real combined data set you can put in front of leadership – not a forecast of what a merge might look like, but what it actually produces today.

And because each dry run takes hours rather than weeks, you can run the integration as a series of fast experiments: test a way to combine the two sets, see the result, adjust, and run it again – work an analyst on the integration team can drive without waiting on scarce engineering time.

When either side of the deal brings a legacy estate with it – a mainframe or AS/400 running core operations – the logic that shapes those numbers sits inside COBOL, RPG, or PL/1 that nobody on the deal team wrote. Contextual Data Lineage reads that code directly, so the reconciliations you run against it are grounded in how the acquired business actually calculates, not how the integration plan assumed it did.

Each dry run sharpens both the design and the estimate: how much maps cleanly, how much needs work, what the integration will truly cost and how long it will take. For a team accountable to a timeline and a value-realization target, that turns the riskiest work stream in the integration into the most predictable one.

Find out early, not late

None of this is unique to mergers. It is the same idea behind letting the data shape the model – that the final model should come last, after the work that tells you what it should be. In an integration, the idea just has sharper teeth, because a rebuilt model is not only rework; it is stalled value realization and a timeline that no longer holds.

If you are running an integration – or advising the team that is – the lowest-risk move is not to wait for the perfect design. It is to put the two data sets together early, see what the merge actually takes, and let what you learn shape the future state. That is exactly what we built Zengines to do. If you would like to see what your combined data looks like before you commit to a model, let's talk.

Get a demo →

Frequently asked questions

What is value realization in M&A?
Value realization is the point at which the synergies and benefits a deal was underwritten on actually show up in the combined company's results – cost savings from decommissioned systems, revenue from a single customer view, efficiency from consolidated operations. It depends on the data: until the combined numbers can be trusted, the value stays on the slide rather than landing in the P&L.

Why do merger integrations stall in the data?
Because the future-state design is usually locked before anyone has seen the two data sets combined. The chart of accounts does not map one to one, apparent duplicates turn out to be distinct entities, and figures that reconciled separately stop tying once the ledgers sit together. Discovered late, each of those means reworking the model and resetting every milestone that depended on it.

How long does post-merger data integration take?
It depends on the number of systems and how far apart their definitions sit, but the timeline is driven less by data volume than by how early the hard problems surface. Running fast, repeatable dry runs at the start – rather than one cutover at the end – converts the estimate from a diligence guess into a number grounded in the actual data.

What does the integration management office need from the data workstream?
Estimate confidence, above all: how much data maps cleanly, how much needs remediation, where the genuinely hard reconciliations live, and which systems can realistically be retired on schedule. Those answers come from combining the data for real, even roughly, rather than from a design review.

A merger brings together two general ledgers and two definitions of “customer.” A private equity portfolio multiplies that across every portfolio company. Either way, the messiness is expected. What decides whether the value gets realized is what happens next.

It usually begins well. The team profiles the data – what exists, how complete it is, where the obvious problems are – and comes away with a clear, shared picture of what they are dealing with. That is the right first move.

The trouble is the decision that tends to follow it. Once profiling is done, the instinct in almost every post-merger integration is the same: design the data model, lock it in, then move everything into it. It feels like the disciplined, sequential way to run the program.

After years of this work alongside financial institutions, the acquirers and private equity firms reshaping them, and the consulting teams that advise both sides of a deal, I have come to believe that instinct is backwards. Locking the model in before the data has had a chance to inform it is exactly what makes the model fragile.

Here is what I would want any deal team to hear: when you are consolidating data from multiple systems, treat your first data model as a working draft – something to run against, not something to commit to. The work that happens between that draft and the final model is not a delay. It is what makes the model hold up.

What data profiling shows you, and what it hides

Data profiling reveals a first picture is real, and it is worth having. What it cannot show you is where the real risk lives.

Profiling describes your data at face value, and face value is rarely the whole story. It will not tell you whether the “customer” in one system is the same thing as the “customer” in another. It will not tell you whether two numbers that are supposed to match actually reconcile. And it certainly will not tell you how each system arrived at the figures it shows – the business logic that quietly shapes every number is invisible in a profile. It is part of why data migrations are almost always messier than teams expect.

So if you build a model on the profile alone, you are building on a description of the data, not an understanding of it. The assumptions you could not see become the assumptions baked into the model. And they surface later – when the data sets are combined, during reconciliation, during the first reporting cycle when a number comes out wrong – at the most expensive possible moment to fix them.

The work in between is the model's foundation

The steps between profiling and finalizing the model each answer a question the model depends on. None of them require the model to be locked first. In fact, they are what tell you what the model should ultimately be.

Each of these either confirms an assumption or replaces it with evidence. By the time you have worked through them, the model is no longer a design exercise built on what you hoped was true. It reflects what the data actually is: what entities exist, how they relate, what logic governs them, and where the gaps are. That is a model you only have to build once.

Of those six, business logic is the one deal teams are least equipped to answer – because in an acquired company the logic was written by people who do not work for you, in systems you have never operated. When the acquired estate includes a mainframe or AS/400, that logic sits inside COBOL, RPG, or PL/1 that may not have been documented in decades. Contextual Data Lineage reads that code directly and surfaces the calculations, conditional branches, and dependencies behind each number, so the model reflects how the acquired business actually works rather than how the deal team assumed it did. It is the same gap that causes most mainframe exit projects to fail: code that can be described but not explained.

In private equity, the problem repeats – and compounds

A single acquisition is one version of this problem. A private equity portfolio is the same problem many times over, with a reporting obligation stretched across all of it.

Each platform investment and every add-on arrives with its own chart of accounts, its own customer definitions, its own operational history. The instinct to standardize is right – portfolio-level visibility is the entire point. But a model locked around the first platform company becomes the model every subsequent add-on has to be forced into, and the forcing is where the reporting breaks. What looked like a clean standard turns into a growing pile of exceptions nobody wants to own.

Carve-outs invert the same problem. Instead of combining data that was never designed to be combined, you are separating data that was never designed to come apart – shared reference data, allocations that assume a parent structure, logic that silently depends on entities that will not exist after close. Either way, the working-draft principle matters more in a portfolio than in a single deal, not less: the model has to survive contact with the next acquisition, and the one after that.

How Zengines accelerates post-merger integration work

This is the work our Turnkey Data Migration Platform was built for. It runs the stages above as fast, AI-assisted dry runs rather than manual projects: it profiles and classifies each source automatically, predicts how the fields in one system line up with another, flags the reference-data and quality conflicts that would otherwise surface late, and reconciles the numbers across systems so you can see exactly where they diverge. Much of that work – the mapping, the fixes, the reconciliation – can be driven by a business analyst rather than scarce engineering resources, which matters when a deal team is moving fast. And because the platform keeps active metadata tying every step together, a decision you make in one place stays visible everywhere it matters.

Because each pass takes hours instead of weeks, you can run the work as a series of fast experiments: see what the combined data actually looks like today, test an assumption against it, adjust, and run it again. Every pass teaches you something the model will eventually need to reflect.

Why this matters more in the age of AI

Combining systems used to be about reporting and operational efficiency. Increasingly it is also about whether your data can support what comes next. A combined data set built on assumptions is not just risky for a financial report – it is not a foundation you can trust for AI, or for any other decision system you put on top of it. Data you can explain is data you can rely on. The investigation work is what earns that trust; the model is simply where it gets recorded.

So when the instinct is to lock the model in and march toward it, I would gently push the other way. The fastest path to a model you can trust runs straight through the work everyone is tempted to defer.

Let the data refine the model

If you are leading an integration after an acquisition or across a portfolio – or advising a client through one – the lowest-risk move is not to lock the model in and hope it holds. It is to start running the data through it early and let what you learn refine it. That is exactly what we built Zengines to do. If you would like to see what your combined data actually looks like before you finalize the model, let's talk.

Get a demo →

Frequently asked questions

What is post-merger integration?
Post-merger integration is the work of combining two organizations after a deal closes – systems, processes, people, and data – so the combined entity operates as one and delivers the value the deal was built on. The data workstream is usually the longest pole: until the two data sets can be combined and trusted, reporting, system decommissioning, and synergy capture all wait on it.

How do acquirers integrate automation with legacy platforms post-merger?
The obstacle is rarely the automation itself – it is that the acquired platform's business logic is undocumented. Before automating anything against a legacy system, an acquirer needs to know how that system calculates what it calculates. Reading the logic directly out of the code (COBOL, RPG, PL/1) turns an opaque platform into one that automated mapping, transformation, and reconciliation can safely run against.

What is a post-merger integration tool?
In the data workstream, it is a platform that profiles both companies' source systems, predicts how their fields map together, surfaces master-data and quality conflicts, and reconciles the combined numbers – so the integration can be run as fast, repeatable dry runs rather than a single manual project with one chance to get it right.

When should the final data model be locked?
After the investigation work, not before it. Profiling, master-data alignment, reconciliation, schema conformance, and business-logic comparison each replace an assumption in the model with evidence. Locking the model first means those assumptions surface during reconciliation or the first reporting cycle instead – the most expensive moment to change them.