Ankur Kalohia.
Mainframe modernization is often described as a move from older infrastructure to cloud platforms, modern databases, and more flexible architectures. But for Ankur Kalohia, a Pittsburgh-based technology leader and Director of Delivery Management at EPAM Systems, one of the hardest parts of modernization comes before migration begins: understanding what the legacy system actually does.
For modernization leaders, that missing understanding creates a business problem as much as a technical one. A company cannot confidently estimate migration cost, design a target-state architecture, or sequence transition waves if it does not understand the business rules and dependencies embedded in the current system. A missed rule can affect system behavior; a hidden dependency can delay a cutover; incomplete lineage can create downstream reporting or compliance risk.
Asked why this phase is often underestimated, Kalohia pointed to the way enterprise systems evolve over time. In many large organizations, especially in finance, insurance, government, logistics, and other transaction-heavy sectors, critical business logic is scattered across COBOL programs, PL/I modules, JCL, copybooks, database calls, batch jobs, message queues, and inter-program dependencies. Requirements documents may be incomplete, original developers may no longer be available, and decades of exceptions or regulatory adjustments may exist only inside the code.
"After years or decades, the code becomes the living record of the business," Kalohia said. "Before you modernize, you have to recover that meaning."
It is the problem Kalohia says he kept encountering in modernization work. His related paper, Leveraging Generative AI for Extracting Business Requirements from Legacy COBOL and PL/I Code, was published as part of the ACL 2026 Industry Track Poster program and is identified by DOI: 10.2139/ssrn.6055934.
The work focuses on recovering business rules, requirements, dependencies, lineage, CRUD patterns, source-to-target mappings, and program behavior from complex legacy estates. These are the artifacts modernization teams need before they can make safe decisions about migration scope, sequencing, target architecture, integration, and operational risk.
"Knowing that a program exists is not enough," he said. "You need to know what business behavior it supports, which rules it enforces, lineage, what data it reads or updates, and how that knowledge should be carried into the target state."
One implementation of that approach is an AI-assisted reverse-engineering capability developed by him and his team for legacy modernization work. Rather than asking a large language model to interpret raw COBOL or PL/I code in isolation, the method first applies deterministic program analysis to parse and structure the source code. It extracts control flow, data flow, dependencies, database usage, external references, and program structure. AI is then used to translate that structured information into reviewable business and architecture artifacts.
"The goal is not to replace human experts," Kalohia said. "The goal is to give them a better starting point."
Kalohia is careful not to describe AI as a shortcut around modernization discipline. In his view, the technology is useful only when paired with deterministic analysis, human review, and governance controls. A useful AI output cannot merely sound convincing; it must be specific, reviewable, and connected to the underlying system behavior. In environments involving payments, trading, claims, logistics, customer records, or regulatory reporting, a missed rule or hidden dependency can create testing delays, rework, or transition risk.
The reported results give a sense of what the method is intended to improve. In evaluation work involving large COBOL portfolios, Kalohia said the approach was compared against expert-authored business rules and manual documentation work. The reported results included approximately 95 percent agreement with expert-authored rules, a roughly 70 percent reduction in documentation effort, and analysis throughput several times faster than manual review.
Across online, batch, CICS, and JCL workloads, analysis throughput increased from roughly 313 lines of code per hour in manual review to around 1,000 lines of code per hour through the automated pipeline.
The approach has also been applied in a regulated financial-services setting involving approximately five million lines of code, with local deployment considerations, customer-network restrictions, security review, grammar compliance, dead-code analysis, and customer-specific feature turnaround.
For Kalohia, those operational details are what separate enterprise AI from experimentation. Large organizations do not adopt AI simply because it is new. They adopt it when it can fit within security, governance, review, and delivery constraints.
In large modernization programs, that makes discovery more than an inventory exercise. Dependency graphs can influence sequencing. Lineage analysis can reveal unclear data ownership. CRUD views can show which applications control critical information. Business-rule extraction can help teams understand whether a modernization wave is moving a technical component or a business capability.
"Discovery is no longer just an inventory exercise," Kalohia said. "The information recovered from the legacy estate can affect transition planning, integration design, migration sequencing, and retirement decisions."
As more enterprises revisit mainframe modernization, the challenge is not only how to move away from older platforms. It is how to understand the institutional knowledge those platforms still contain.
For organizations with large legacy estates, the question is no longer only, "How do we move off the mainframe?" It is also, "How do we recover the business knowledge stored inside it before we move?"
For Kalohia, that is where modernization increasingly begins: not with the target platform, but with the effort to understand what the existing system already knows.
Author: Faizan Farooqui
