Reverse-engineering legacy ABAP into functional and technical specs

Every long-running SAP estate carries a layer of custom ABAP that nobody fully understands anymore. Reports, user exits, enhancements, function modules and includes written to solve a real problem a decade ago, then patched and re-patched by people who have since moved on. When a migration or a refactor comes around, that layer is where projects slow down, because you cannot safely move code whose intent you cannot state.

Why is documentation the hidden cost of migration?

Because it was never budgeted for. Teams plan for the technical adjustments a move to S/4HANA requires, but the real drag is working out what the custom code was supposed to do in the first place. That analysis is slow, and it usually surfaces mid-project rather than in the estimate.

The pattern is familiar. A custom program throws an exception in the new system, and the only way forward is to read it line by line, chase the includes it calls, trace the tables it touches, and reconstruct the business rule buried inside. Multiply that by hundreds of objects and the documentation gap, not the code itself, becomes the schedule risk. This is the same work a custom code assessment starts, and it feeds directly into a wider S/4HANA readiness assessment.

What does a good functional and technical spec actually capture?

A functional specification records business intent; a technical specification records how the code delivers it. Together they let a reviewer decide whether an object should be kept, rebuilt or retired, without reading every line themselves.

A functional spec (FS) worth having captures:

• Business intent. What the object is for, who relies on it, and the process it sits inside.
• Inputs and outputs. Selection parameters, source data, and what the object produces, prints or posts.
• Rules and logic. The calculations, validations and decisions the code applies, in business terms.
• Edge cases. The exceptions and special handling added over the years, which are usually where the risk hides.

A technical spec (TS) captures the how: the program structure and its includes, the function modules and classes it calls, the database tables it reads or updates, the BAdI and enhancement points it hooks into, and the dependencies that connect it to the rest of the system. Dependencies matter most. An object that looks isolated often feeds three others downstream, and that is exactly what breaks quietly after a change.

Why read the live object instead of interviewing people?

Because the code as it runs today is the only complete and current account of what the object does. People remember the original design, not the ten fixes layered on since, and the person who knew it best has often left the company.

Interviews are useful for context, but they drift. Someone recalls that a report "excludes intercompany", and the code actually excludes intercompany except for one plant added during a year-end scramble. That exception is invisible in conversation and decisive in a migration. The live object holds the truth, including the parts everyone forgot. Reading it recovers real behaviour rather than a half-remembered version of the intent. It also removes the dependency on whoever happens to still be around, which is a fragile foundation for a multi-month programme.

How does C16 help recover the intent?

C16 inspects your existing ABAP objects read-only and auto-generates structured functional and technical specs in hours rather than weeks. It reads the program, its includes, the function modules and enhancements it depends on, and the data it touches, then writes that up in a consistent FS and TS format your team can review.

The point is not to replace expert judgement. It is to hand the expert a complete first draft instead of a blank page. A developer or functional consultant reviews what C16 produced, corrects it where the business context adds nuance, and signs off. That Expert-in-the-Loop step is where the specification becomes trustworthy. What used to be weeks of archaeology per module becomes a review pass over a draft that is already grounded in the actual code.

The same understanding step pays off well beyond migration. A team that has recovered the intent of its custom code answers tickets faster and guesses less, which is why this analysis also underpins reducing AMS ticket effort. Understand the object once, and every future change against it gets cheaper.

The short version

Undocumented custom ABAP is the quiet cost that shows up mid-migration, not in the estimate. The fix is to recover intent as functional and technical specs before you move, and to recover it from the live object rather than from people who half-remember it. C16 does the first draft, read-only and in hours; your experts make it right.

That is the difference between discovering what your code does when it breaks and knowing what it does before you touch it.

See it read a real object. C16 inspects your existing ABAP and drafts the functional and technical spec for your team to review, on ECC or S/4HANA. Book a walkthrough.

C16 is read-only by default; any change it drafts ships only through your own change process. It queries the system on demand and does not retain your business data or use it to train models. Generated specifications are drafts for expert review, and a person stays in the loop. PEOL Technologies is an SAP Partner, ISO 27001 certified and SOC 2 Type II compliant.