How a Knowledge Graph Helped Map a 35-Million-Line Mainframe

Stephen Chin says modern banking apps often sit on old mainframes with nightly batch jobs, business rules and data contracts. Changing a single line can be risky when the surrounding dependencies are poorly understood.

Chin recalls migrating COBOL to Java decades ago: projects took years, and incomplete tests left corner cases undiscovered. He introduces Blitzy’s Neeraj Deshmukh to explain a different approach.

Deshmukh uses the public AWS CardDemo system and an interest calculation as an example. A batch job calls a program, which uses copybooks and layouts and writes VSAM data; the result depends on all of those relationships, not just a formula.

An AI asked to translate the COBOL formula to Java might produce plausible code while missing record precision, account updates, transaction output and batch contracts. The problem is missing system context rather than merely syntax conversion.

Chin argues that a larger context window or similarity search does not necessarily recover all the dependencies needed for a change. A graph can retrieve connected information across multiple relationships; the speakers present it as a complement to the model.

He says models may use only part of their advertised context effectively, so the application should supply precise, relevant evidence. His numerical estimates are observations from the talk, not a universal limit for every model or task.

Deshmukh maps jobs, programs, copybooks, fields and data stores into a knowledge graph. Each relationship retains its repository, revision, symbol and source evidence; the graph is refreshed as code changes.

Each agent receives a task-specific context packet containing the relevant source slice, constraints, evidence and unanswered questions. The goal is access to the right information when needed, not putting the entire codebase in one prompt.

Blitzy describes its process as an enterprise compiler: reverse engineer the system, extract workflows and business logic, combine those with the user’s requirements, and create an agent action plan. A human reviews the plan before generation.

The agents generate code with validation throughout, producing a pull request and documentation of the evidence. Deshmukh says access to the repository and build environment also lets the system observe runtime behavior rather than rely only on static analysis.

The proposed architecture combines a shared plan for thousands of agents with continuous testing. Deshmukh says Blitzy spends more compute on tests than code generation, while humans retain decisions at important checkpoints.

The action plan defines the transformation’s scope and the behavior that must be preserved. The speakers identify system context, continuous validation, security and governance guardrails, and human oversight as the controls.

Parity includes monetary precision and rounding, balances, transaction records, failures and operational behavior. Existing defects also need explicit decisions: silently changing them can change a business outcome.

The team compares the old and new systems on the same inputs, returned values, persisted state, transaction outputs and errors. Deshmukh says validation is layered through unit, integration, data and end-to-end tests rather than left until the end.

A rounding example shows why: a Java translation can compile and look correct but differ by one cent from COBOL behavior. The speaker says a parity test caught the difference; at scale, small discrepancies can accumulate.

Deshmukh presents a bank trade-posting case in which a monolith was converted into six modules using PostgreSQL and several languages. He reports 18 days and over 4,000 tests, compared with the customer’s original estimate of 18 engineer-weeks.

He says Blitzy mapped a roughly 35-million-line mainframe in four days after an earlier systems-integration effort had taken months. This is the vendor’s case-study claim; mapping the estate is distinct from migrating every line.

For another 25-million-line insurance platform, Deshmukh reports a ninefold speed improvement and gives figures for autonomous completion and production acceptance. The presentation does not independently establish whether those results generalize.

The speakers say the same knowledge layer can support new features, security work and compliance evidence after modernization. A promotional interest rate, for example, can reuse the updated graph, governance rules and expanded tests.

Chin closes by describing a knowledge layer connecting business rules and processes to the system. He sees potential uses in regulatory compliance and fraud analysis, in addition to the original modernization task.

The speakers point listeners to knowledge-graph sessions and a sandbox containing the public CardDemo example, inviting teams to investigate the approach with their own code.