Recovering Code Isn’t the Same as Recovering Knowledge
Why source code alone doesn’t prepare an application for modernization
When organizations discover that part of a legacy application has been lost or can no longer be maintained, recovering the source code naturally becomes the first priority. With a partially missing or mismatched codebase, even routine maintenance becomes difficult, aligning the application with the latest version of COBOL is impossible, and every production issue introduces additional operational risk.
Recovering the code is therefore an essential milestone. It restores the technical asset required to keep the application operational.
However, it rarely restores the knowledge required to modernize it.
Source code recovered from executables presents a very different picture from the one originally created by its developers. Meaningful variable names will be lost. Paragraph names, comments, and other contextual information is unavailable. Relationships between modules remain implicit, and the connection between technical implementation and business processes is still hidden inside thousands of lines of procedural logic.
From an engineering perspective, the application exists again.
From a business perspective, it is still largely undocumented.
This distinction explains why many modernization initiatives continue to struggle even after missing source code has been recovered. Development teams can compile and maintain the application, but architects still cannot answer fundamental questions. Which modules implement critical business rules? Which programs belong to the same business capability? Which dependencies could affect a modernization initiative? What data flows are implemented in the system?
Answering these questions requires more than source code recovery. It requires rebuilding the knowledge that gives the application its business meaning.
Once this knowledge has been reconstructed, it becomes possible to create a comprehensive digital twin of the application. Rather than working directly with millions of lines of legacy code, architects and developers can explore system behavior, analyze dependencies, evaluate modernization scenarios, and safely experiment with proposed changes before implementing them in production.
The same knowledge base can also power conversational AI capabilities. Instead of manually searching through technical documentation, source code, and architecture diagrams, engineers can ask questions in natural language and receive context-aware answers about business logic, module interactions, data flows, or application dependencies. This significantly accelerates onboarding, improves developer productivity, and makes institutional knowledge accessible long after the original experts have left the organization.
From Mainframe Code Recovery to Application Understanding
A practical approach to rebuilding application knowledge
Recovering application knowledge is best viewed as a progressive process rather than a single technical activity. Each stage addresses a different aspect of the problem and creates the foundation for the next.
The first step is to restore a complete, maintainable codebase. When source code is missing or no longer matches the production environment, maintenance becomes unreliable, audits become more difficult, and modernization cannot begin safely.
This stage includes identification and isolation of target CSECTs from system-level services, translation of binary representation to Basic Assembler Language (BAL), reconstruction of high-level COBOL source code (pattern matching, operands and internals analysis) and validation that the recovered source is functionally equivalent to the original program. At this stage, organizations regain the ability to maintain the application, support audits, and continue operating on supported compiler versions.
The second objective is to restore business semantics. This is where technical artifacts begin to regain meaning. Variables, paragraphs, sections, and routines are associated with the business concepts they represent. Existing documentation, copybooks, interface definitions, and domain knowledge are correlated with the recovered code to reconstruct the original intent behind the implementation. Instead of viewing the application as a collection of isolated programs, engineers begin to recognize business functions and business rules. According to the IBA Group solution, AI-assisted semantic recovery reduced the effort required for business context reconstruction by approximately 30%, while maintaining engineer validation throughout the process.
Only after these two stages does full application reverse engineering become possible.
At this point, the objective shifts from understanding individual programs to understanding the application as a whole. Dependencies between COBOL modules, JCL jobs and procedures, copybooks, databases, utility programs, and scheduler definitions are identified and connected. Active components are distinguished from obsolete artifacts. Cross-language relationships become visible. Business capabilities can be reconstructed from technical implementation rather than inferred from incomplete documentation.
The outcome is no longer simply a recovered application.
It is an application that can once again be understood.
This distinction is critical. Modernization decisions are not based on source code alone; they depend on understanding how technical components support business processes, where dependencies exist, and how change will propagate across the application landscape. By reconstructing that knowledge before modernization begins, organizations reduce uncertainty, improve planning accuracy, and create a significantly stronger foundation for future transformation.
Building a Foundation for Mainframe Modernization
Turning application knowledge into modernization readiness
Application knowledge has value far beyond understanding an existing system. Its primary purpose is to enable confident engineering decisions.
Once the relationships between programs, business rules, data structures, interfaces, and operational dependencies have been reconstructed, organizations can begin evaluating modernization options based on evidence rather than assumptions.
Architects can identify logical business domains that may be modernized independently. Development teams can estimate effort with greater confidence because application boundaries are clearly understood. Testing becomes more predictable because dependencies between components are visible before implementation begins. Business stakeholders gain traceability between technical implementation and the processes that support day-to-day operations.
This changes the nature of modernization projects.
Instead of starting with an unknown application and discovering its complexity during implementation, organizations begin with a structured understanding of the existing environment. Modernization planning becomes an engineering exercise rather than an investigation. This is the approach we apply in our mainframe modernization projects.
The same knowledge also continues to deliver value after transformation begins. It accelerates onboarding of new engineering teams, reduces the effort required to investigate production incidents, improves audit readiness, and creates a reusable knowledge base that supports future changes long after the initial modernization project has been completed.
For this reason, application knowledge recovery should not be viewed as a preliminary activity performed only before migration. It becomes a long-term engineering asset that reduces operational risk throughout the lifecycle of the application.
How AI Changes Mainframe Application Knowledge Recovery
Supporting engineers, not replacing them
For many years, comprehensive application reverse engineering was technically possible but economically difficult.
Recovering business knowledge from large enterprise applications required experienced specialists to analyze thousands of programs, compare implementation patterns, reconstruct documentation, identify dependencies, and validate business rules. While the value of this work was widely recognized, the time and cost involved often limited its practical application.
Artificial intelligence has fundamentally changed this equation.
Large language models are particularly effective at identifying recurring implementation patterns, suggesting meaningful names for variables and routines, generating technical documentation, and highlighting relationships that deserve further investigation. These activities do not replace engineering expertise, but they significantly reduce the amount of repetitive analysis required to reconstruct application knowledge.
- Pattern recognition
- Variable & routine naming
- Documentation generation
- Relationship discovery
- Functional correctness
- Business semantics
- Architecture relationships
- Final knowledge base
Within IBA Group’s solution, AI is applied after a reliable technical foundation has been established. Engineers first recover a functionally equivalent codebase and validate its correctness. AI is then used to accelerate semantic analysis, documentation, naming recommendations, and code interpretation. Every recommendation is reviewed by engineers before becoming part of the business-contextualized codebase.
As a next step, according to the IBA Group solution we can start with AI-driven reverse engineering to bridge the gap between technical implementation and business value of an application. The solution covers the following phases: pre and post-inventory collection, relationship mapping, gap analysis and artefacts identification, inventory refinement, multi-level business object documents generation and application knowledge base (aka digital twin) building and deployment.
AI does not eliminate the need for reverse engineering.
It significantly reduces the effort required to perform it.
As a result, projects that were previously considered too time-consuming or expensive become economically viable. Organizations can recover application knowledge earlier, reduce uncertainty before modernization begins, and establish a stronger foundation for transformation without proportionally increasing project cost.
Conclusion
Modernization begins with understanding
Legacy modernization is often discussed in terms of new platforms, programming languages, cloud architectures, or artificial intelligence. While these technologies shape the future state of enterprise applications, they do not solve the most immediate challenge facing many organizations: understanding the systems they already depend on.
Applications that have evolved over decades contain far more than source code. They embody business rules, operational practices, architectural decisions, and institutional knowledge accumulated through years of continuous change. When that knowledge is lost, modernization becomes significantly more complex—not because the technology is outdated, but because the organization no longer fully understands the application it intends to transform.
Recovering source code is an important milestone, but it is only the beginning. The real objective is to restore application knowledge: the relationships, semantics, dependencies, and business context that allow engineers and architects to make informed decisions with confidence.
Application reverse engineering, business semantic recovery, and AI-assisted analysis are all means to that end. Together, they enable organizations to transform undocumented legacy systems into understandable, maintainable, and modernization-ready assets.
Modernization is not about replacing legacy systems.
It is about recovering the knowledge they contain.
