Why Legacy Modernization Starts with Application Knowledge

At the GSE DACH Conference 2026, the IBA Group team presented a case that challenged one of the most common assumptions about legacy modernization.

Table of Content

The customer relied on a business-critical mainframe COBOL application, but part of the original codebase had been lost. With the missing source code, maintaining the application had become increasingly difficult, aligning the application with the latest version of COBOL was not feasible, and future modernization initiatives had effectively stalled.

Recovering the codebase was the customer’s immediate objective. However, as the project progressed, it became clear that restoring the source code would address only part of the problem.

Even with a fully reconstructed codebase, the application remained difficult to understand. Years of accumulated business logic, undocumented dependencies, and architectural decisions were still hidden inside thousands of lines of legacy code. The organization had recovered the software, but not the knowledge required to confidently maintain or modernize it.

This experience reinforced an observation we increasingly encounter in legacy modernization projects.

That realization changed the way we approached the engagement. Instead of treating source code recovery as the end goal, we treated it as the first step in rebuilding application knowledge—the foundation required for successful application reverse engineering, legacy application modernization, and long-term mainframe modernization.

The Real Challenge Behind Legacy Modernization

Why technology is rarely the biggest obstacle

Discussions about legacy modernization often focus on technology choices. Should the application be rehosted or replatformed? Is it better to refactor or rewrite? Would APIs extend the life of the existing system, or is cloud migration the better long-term strategy?

These are important questions, but they are rarely the first ones organizations need to answer.

Before deciding how to modernize an application, they need to understand what they are modernizing.

For business-critical systems, that understanding extends far beyond the source code. Enterprise applications are complex ecosystems which combine technical software assets — programs, copybooks, JCL jobs, procedures, and databases — with operational workflows, interfaces, and schedulers to power critical business processes. More importantly, they contain decades of accumulated business logic that reflects how the organization actually operates.

Much of this knowledge exists nowhere except inside the application itself.

As long as experienced engineers remain available, this hidden knowledge is often taken for granted. They know which modules implement specific business rules, which batch jobs must run in a particular sequence, and which interfaces cannot be modified without affecting downstream systems. Over time, however, that expertise becomes increasingly concentrated in a small number of individuals. When they retire or leave the organization, institutional knowledge disappears much faster than the software itself.

This is why many modernization programs struggle before a single line of new code is written. The challenge is not selecting the target architecture. It is reconstructing a reliable understanding of the current one.

Successful modernization starts with understanding how the application really works before deciding how to transform it. Organizations first need to identify what they have, how the components relate to one another, which business capabilities they support, and where the greatest technical and operational risks lie. Only then can they make informed decisions about modernization priorities and implementation approaches.

When Business Knowledge Disappears

How organizations gradually lose understanding of their applications

Legacy applications rarely become difficult to maintain overnight. The process is gradual and often goes unnoticed until a major transformation initiative begins.

A production issue exposes a dependency that nobody expected. A seemingly isolated change affects several unrelated business processes. A regulatory update takes months because engineers must first determine where the relevant business rules are implemented. During due diligence for a merger or cloud migration, architects discover that existing documentation no longer reflects the production environment.

These symptoms point to a common underlying problem: the erosion of application knowledge.

This erosion is not caused by poor engineering practices alone. It is a natural consequence of long-lived enterprise software. Over decades, applications outlive development methodologies, programming standards, organizational structures, and often multiple generations of engineers. Business knowledge becomes fragmented across code, documentation, operational procedures, and the experience of individuals. As each of these sources changes independently, the overall understanding of the application gradually declines.

In some environments, the situation becomes even more challenging when parts of the original source code have been lost or can no longer be rebuilt using modern compiler versions. At that point, organizations are no longer dealing only with undocumented software. They are attempting to modernize systems whose technical implementation and business intent must first be reconstructed.

This distinction is important. Modernization projects do not fail because organizations lack new technology. They fail because they lack sufficient understanding of the existing application to make confident engineering decisions.

Recovering that understanding is the objective of application reverse engineering. The goal is not simply to analyze source code or rebuild missing artifacts, but to restore the knowledge required to safely maintain, evolve, and modernize the application.

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.

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.

Looking for Mainframe Expertise?

Whether you’re modernizing legacy applications, recovering critical application knowledge, or looking for long-term support, IBA Group is ready to help.