Across All Technologies

The application landscape of a large enterprise is rarely cast from a single mold: a mainframe running programs from the 1980s keeps the accounts, an ERP system with two decades of custom developments controls logistics and finance, and in between run custom applications in Java, Python, or JavaScript built by business units and service providers. Anyone who wants to modernize this landscape ends up with different specialists, different tools, and different documents for each technology. The fourth and final post of this series shows why agentic reverse engineering works with the same method across all technologies, what actually differs per technology, and why only a shared knowledge graph makes the landscape understandable as a whole.

Three technology worlds, one problem

In our projects we almost always encounter the same three worlds.

Mainframe. COBOL, PL/I, and JCL on IBM mainframes, IBM i, NATURAL with ADABAS: at banks, insurers, social insurance carriers, and transport operators, these systems still hold the core portfolios, that is, accounts, contracts, benefits, and billing. The people who wrote them have in many cases already retired or are about to.

ERP. Every large SAP landscape consists of two systems. The first is the SAP standard, documented and maintained by the vendor. The second is what the enterprise has built on top of it over twenty or thirty years: custom developments in the Z and Y namespaces, enhancements, modifications, user exits, BAdI implementations, interfaces to plants and partners, batch chains for period-end closing. According to the Sysparency whitepaper on the Legacy-Code Intelligence Platform (July 2026), in large industrial groups this second system frequently comprises tens of thousands of objects per instance, and that is exactly where the enterprise's differentiation lies.

Custom software. Applications in Java, C/C++, Python, or JavaScript, usually in several generations of frameworks, often developed by changing teams and service providers. Some exist as source code, others only as a running application, for instance when the service provider no longer exists or a standard product has been customized so heavily that the customizing itself has become custom software.

As different as the three worlds are technically, their condition is the same: documentation is incomplete, outdated, or lives in people's heads. That creates the same three risks, regardless of whether the logic is written in COBOL, ABAP, or Java: a transformation risk, because scope is estimated instead of counted; an operational risk, because every change can have unknown side effects; and a knowledge risk, because understanding leaves with the people. In the first post of this series I therefore described the legacy system as a knowledge archive. The question this post answers is: does each of these archives need its own tools and its own specialists?

Why the method does not depend on the technology

The answer is no, and the reason lies in the order of analysis. Agentic reverse engineering as we practice it with SLIP, the Sysparency Legacy-Code Intelligence Platform, works in three stages, and only the first of them knows the technology.

1. Symbolic analysis. A deterministic static analysis reads every component of the system and models its syntax and logic exactly: call and dependency graphs, data reads and writes, screen and process flows, interfaces and jobs. This is where the technology-specific knowledge sits: a COBOL program with its copybooks is parsed differently from an ABAP report with its selection screen or a Java service with its annotations. The result, however, is the same in every case: proven facts about the system, complete and reproducible.
2. Agentic interpretation. AI agents read the symbolic model and the source code and explain every component twice, in business terms for process owners and in technical terms for architecture and development. The agents do not invent a structure; they explain one that was proven in the first stage. This stage is identical for COBOL and Java.
3. Consolidation in the knowledge graph. Facts and explanations are stored as typed nodes and relationships, versioned per analysis run and cited down to program and line. This stage, too, is technology-neutral: a batch job is a batch job, whether it is defined in JCL or as an SAP job chain.

The ontology of the graph, which I described in the third post, is thus the real reason for technology independence. Programs, tables, interfaces, screens, jobs, and business rules are the same entity types regardless of the language they come from. What differs is the path there, not the destination.

The syntax differs. The question is always the same: what does this system do, and what breaks if we change it?

Where no source code is available, the second path applies, which I described in the second post: App2Spec observes the application from the users' point of view and stores screens, data fields, business rules, and processes in the same ontology. So the blackbox, too, ends up in the same graph.

What actually differs per technology

Technology-independent does not mean the analysis has the same focus everywhere. Each world has places where its knowledge concentrates.

Mainframe: the logic runs at night

Anyone who knows a mainframe system only through its screens knows half of it. The other half is the batch chains: jobs defined in JCL that run in a fixed order, produce files that the next job reads, and in the end deliver the daily close or the billing run. The analysis must capture these chains as a whole, with every dependency between job, program, and file. Then there are the shared data structures: a copybook included by many programs is the place where a small change has a large effect. The graph shows which programs read a structure and which write it.

ERP: the second system behind the standard

In SAP landscapes the first task is separation: what is standard, what is custom, and where does custom code reach into the standard? The analysis follows custom code across the five layers described in the Sysparency whitepaper: from the user interface (Fiori apps, Dynpro and selection screens) through business logic (custom programs, enhancements, user exits, BAdIs) and data access (tables, views, read and write paths) to integration (RFC, IDoc, APIs) and operations (jobs, job chains, period-end closing). For S/4HANA programs and clean core strategies, this is the fact base that makes scope countable: which custom developments are still called, which write to standard tables, which can be replaced by standard functionality? Without this base, planning follows estimates; with it, planning follows inventory.

Custom software: many generations, sometimes no code

Custom applications are technically the most familiar world and organizationally often the least transparent. Over the years, several teams have built with several frameworks; business rules are spread across services, database procedures, and the user interface. Here the analysis must above all separate layers and interfaces cleanly and find rules where they are actually implemented, not where the architecture intended them to be. If no source code is available, App2Spec takes over: an AI agent operates the application or records the work of real users, and the as-is specification emerges from screenshots and event logs. In practice this is where we most often combine both paths.

One graph for the entire landscape

The real benefit of technology independence shows not within a system but between systems. Business processes do not respect technology boundaries. A typical flow: a COBOL batch produces a transaction file overnight, an SAP interface reads it and posts, and a Java portal shows the business unit the result in the morning. Anyone who wants to retire the interface or change the format has to know all three sides. As long as each technology has its own documentation, nobody answers this question completely, and change windows are planned with safety buffers against unknown side effects.

When all systems land in the same graph, with relationships across system boundaries, the weeks-long investigation becomes a query: which objects in which systems depend on this interface, which jobs wait for its completion, which tables are written as a result? The agentic assistant answers in seconds, citing every source location, and the experts review the answer instead of assembling it. The same applies to agents: through the Model Context Protocol, the graph becomes the reliable context source for every agentic implementation on legacy systems, regardless of the technology the target system is built in.

Three properties of the graph make this hold across technologies:

• One standard. Every system runs through the same pipeline, so results are comparable: divisions, regions, and legal entities are documented to one standard, and portfolio decisions rest on inventory rather than surveys.
• Versioning. Each analysis run is a version. Documentation can be repeated after every release, so the baseline does not go stale in the middle of a program.
• Citations. Every statement leads to the line in the code or to the screenshot. Trust is verifiable, not assumed.

What this means for modernization programs

Four practical consequences follow from our projects.

• Start with one system, not with the landscape. We start with a representative, business-critical system, ideally one with a concrete transformation question currently open. Based on our experience from ReqPOOL projects, the analysis of one system is available in days, not months; the figures can be validated per project. The client's experts test documentation and assistant against their hardest current questions. Only then does the rollout follow, wave by wave.
• The technology of the legacy system does not determine the technology of the target. Because the as-is specification in the graph is technology-neutral, the target system can be built in any technology. From the graph we carry the as-is specification into the ReqPOOL Requirements Manager, develop it with the business unit into the target specification, and hand it over as a machine-readable build order to reqCoder, our complete, fully automated agentic Software Development Lifecycle, which is already in use internally at ReqPOOL. This is "Own the Spec, not the Code" in its most consistent form: the COBOL code becomes history, the specification becomes the future.
• Decisions per module, not per technology. Continued operation, modernization, or replacement are not questions one answers for "the mainframe." Transformation recommendations arise at system, module, and component level, aligned with the project goal. Some modules keep running stably, some are rebuilt, some are replaced by standard functionality.
• People validate where business truth matters. The code knows every rule but not its intent. Whether a rounding rule is intended or an error that became habit is decided by the business unit together with our consultants. The tools relieve people of the assembling, not of the deciding.

For regulated industries the same holds across all technologies: source code extraction reads code and metadata, not business data; the platforms are hosted in the EU; client data and source code are never used to train AI models; and in ReqPOOL consulting projects there are no license costs for the tools used. You pay for expertise and effort; documentation, knowledge graph, and assistant stay with you.

The next step

This post concludes the series on agentic reverse engineering: from the legacy system as a knowledge archive through the reconstruction of the specification and the knowledge graph to the landscape as a whole. If mainframe, ERP, and custom software run side by side in your organization and a modernization is coming up, the technology-spanning as-is capture is the first step. How we go about it is described in our service Reverse Engineering; the whitebox platform in detail is on the SLIP page. In an expert conversation we clarify which system is the right one to start with.