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 trusted and explainable, through the Turnkey Data Migration Platform and Contextual Data Lineage. See what it surfaces inside your legacy code.