Agentic Reverse Engineering: Legacy as a Knowledge Archive

In many large organizations, the generation that built today's core systems is retiring. Their knowledge is not written down in any document; it lives in custom code: in-house developments, enhancements, interfaces, and batch chains that have recorded, over decades, how the company actually works. With this post we open a series on agentic reverse engineering and show why legacy systems should be treated as a knowledge archive, how AI agents make that archive readable, and what an organization gains from it.

Two systems, only one of them documented

Every large application landscape consists of two systems. The first is the standard: the ERP software, the database, the operating system, documented and maintained by the vendor. The second is what the organization has built on top of it over twenty or thirty years: its own programs and reports, enhancements and modifications, user exits, interfaces to plants, partners, and legacy applications, nightly batch chains that close the books and move the goods. In large industrial groups this second part often comprises tens of thousands of objects per SAP system (experience values from Sysparency analyses of large SAP landscapes). It carries the company's differentiation, and it is the part for which no documentation exists.

More precisely: it exists, but it is outdated or lives in people's heads. The functional specifications describe what was once meant to be built, not what runs in production today. In between lie hundreds of change requests, special cases, and workarounds known only to the people who have looked after the system for years. Anyone who started as a developer in the early nineties is approaching retirement age. With every farewell, the organization loses not just an employee but access to part of its archive.

Every transformation leader knows the consequences: replacement projects are sized on estimates instead of facts, change windows are padded against unknown side effects, auditors record the missing documentation as a finding, and the S/4HANA transformation stalls in the analysis phase. Regulation (EU) 2022/2554 (DORA), applicable since January 2025, additionally requires financial entities to identify and document all ICT-supported business functions. The knowledge is there. Access to it has been lost.

Legacy code is not ballast. It is the most complete archive of how a company actually works.

Why interviews and workshops do not open the archive

The classic way to recover this knowledge is interviews with the remaining experts, workshops with the business departments, and manual review of the source code. All three share the same weakness: they do not scale with the size of the system. Our practice shows that with manual documentation, even after five years only a fraction of a large legacy system has been described. In an anonymized case from our consulting practice, the core system of a bank, the analysis and documentation of the actual system behavior alone was estimated at around three years for a complete development team, close to one third of the entire replacement budget.

There is a structural problem on top of that. The retirees know the why: why a rule was introduced in 2009, which works agreement stands behind a special treatment, why a batch runs at two in the morning and not at four. The code knows every path, but not the why. Interviews deliver the why without completeness, code reading delivers completeness without the why, and both are already outdated on the day they are finished, because the system keeps running. Reverse engineering that truly opens this archive has to be complete, evidenced, and repeatable, and it has to connect the why from people's heads with the how from the code.

What "agentic" changes about reverse engineering

Within a few years, AI systems in software development have evolved from autocompletion to agents that plan and complete multi-step tasks on their own. For reverse engineering this means: agents read every program component of a system, not a sample; they operate an application screen by screen like a user; and they explain what they find in business and in technical language. What used to be a major project becomes a repeatable analysis run.

One principle is decisive here, and we adhere to it in every project: the facts are established first; only then does an AI write a sentence. A language model never invents the structure of a system. It explains a structure that has previously been proven by deterministic analysis. That is the quality bar architects, internal audit, and business departments can accept. In practice, two paths lead into the archive.

Whitebox: from the source code

SLIP, the Sysparency Legacy-Code Intelligence Platform of our partner company Sysparency, reads the complete source code and the existing documentation of a system, regardless of technology: SAP/ABAP, IBM mainframe with COBOL, PL/I, and JCL, IBM i, NATURAL/ADABAS, as well as Java, Python, C/C++, or JavaScript. Static analysis establishes the facts: call and dependency graphs, data reads and writes, screen flows, interfaces, and jobs. On top of that, AI agents explain every component twice, once for process owners and once for developers, and every statement is cited down to program and line. The result is a navigable documentation application from the system dashboard through business and technical modules down to the individual component, a queryable knowledge graph, and an assistant that answers questions such as "What does this system do, and what breaks if I change it?" in seconds, with sources.

Blackbox: from observed usage

App2Spec, our own agentic consulting platform, works without source code. An AI agent operates the target software on its own like a user, or the platform records the work of a real user, every screen and every event including a screenshot. From this emerge standardized entities of a knowledge graph, that is, screens, controls, navigation paths, data fields, derived business rules, and end-to-end processes, and from those an as-is specification that is published online and exported to Word, PDF, and Markdown. This path is valuable wherever the source code is not accessible: with standard software carrying extensive customizing, or with applications run by external providers.

The two paths complement each other. SLIP delivers the inside view, App2Spec the outside view; where both are available, observation reveals what the code does not show, and the code explains what observation cannot see.

Evidence first: the archive becomes verifiable

Documentation is worth as much as the trust it enjoys. That is why, on both paths, every statement is traceable to its evidence: to program and line in the source code, or to screenshot and event log. Anyone who doubts a business rule sees with one click where it is written or where it was observed. Because the code analysis is deterministic, it is reproducible, and because both paths run automatically, the run can be repeated after every release. The snapshot becomes living documentation that keeps pace with the system instead of trailing behind it.

The figure "days" is an experience value from Sysparency and ReqPOOL projects, validatable per project and dependent on the size and scope of the system. It changes the economics of replacement: the first step, which in the bank case above was estimated at a third of the budget, becomes preparation.

From archive to working tool

An archive that can be read is only the beginning. The value arises when the organization works with the opened archive. In our projects we see four situations in which that happens immediately:

• Replacement and tendering. The evidenced as-is specification is the fact base for target architecture, tender, and migration planning. Vendors, internal audit, and business departments work with the same traceable description.
• SAP transformation. Ahead of an S/4HANA migration it becomes visible which custom developments are actually used, which rules they carry, and which can be dropped. Scoping rests on an inventory, not on a survey.
• Knowledge preservation before departure. Mainframe and core system portfolios are documented while the knowledge holders are still in the building and can add the why. Their knowledge is captured as a comment on an evidenced fact, not as a loose interview transcript.
• Impact analysis in operations. The question of which programs, data flows, and interfaces a change touches becomes a query. The expert reviews the answer instead of assembling it over weeks.

What matters is that documentation, knowledge graph, and assistant remain with the client. Afterward, knowledge about the system no longer depends on individual people, and not on us either. And for the first time it exists in a form that not only humans can read: a typed, evidenced knowledge graph is the context AI agents need to work safely on legacy systems at all, in maintenance as much as in agentic redevelopment under the principle "Own the Spec, not the Code". How the target specification emerges from the as-is specification, and what role the knowledge graph plays in that, are the subjects of the following posts in this series.

The commitments that apply to all our platforms apply here too: they are part of the consulting service, there are no license costs, they are hosted in the EU, and client data and source code are never used to train AI models.

The next step

The question is not whether the retirees' knowledge lives in the custom code. The question is whether your organization can read it before it needs it. How we analyze and document legacy systems is described in our service Reverse Engineering; the two paths are described on the pages SLIP and App2Spec. In an expert consultation we clarify which of your systems is suited for a first analysis run and which questions that run should answer.