How do you inventory SAP interfaces before an S/4HANA migration?
Integration is the part of the migration you do not fully control. Evidence the list early, because every unknown interface is somebody else's schedule.
The short answer
You inventory SAP interfaces before an S/4HANA migration by deriving the list from the system itself — RFC destinations, IDoc partner profiles and message types, the ALE distribution model, released OData and SOAP services, file-based batch jobs, and the custom programs that call any of them — and then filtering that raw list down to the interfaces that actually carried traffic over a recent period. The step most programs skip is the second one: an aging ECC estate almost always declares far more integration points than it runs, and the gap between declared and executing is the difference between a defensible cutover plan and a spreadsheet nobody trusts. For each surviving interface, record five facts — technology, direction, counterparty system and its owner, the business process it serves, and its S/4HANA disposition (carries forward, needs rework, retires). That inventory is what sizes integration regression testing, sequences the cutover, and exposes the third-party dependencies that sit on somebody else's release calendar rather than yours. It is cheap to produce from a live system and expensive to reconstruct from memory halfway through the build.
Why the interface list is the risk nobody owns
Custom code has an owner. Master data has an owner. Interfaces frequently have neither, because each one is half yours and half somebody else's — a partner system, a bank, a 3PL, a tax engine, an acquired subsidiary's middleware. That split ownership is why integration is routinely the least-evidenced part of an S/4HANA estimate and disproportionately often the reason a cutover date moves.
The failure mode is specific and repeatable. The SAP side of an interface is visible and can be assessed by the program team. The counterparty side cannot: it needs a change window, a test partner, and a release slot from an organization that has its own roadmap. Discover that dependency in month two and it is a plan; discover it in month nine and it is a delay, because you are now asking a third party for an unscheduled change under time pressure.
So the value of an early interface inventory is not tidiness. It is lead time on the dependencies you cannot compress.
Where the real inventory lives inside the system
You do not need a workshop to produce a first-pass inventory. The system already holds it, spread across several places that are individually unremarkable and collectively complete. The task is to read all of them and join the results.
- RFC destinations (SM59) and the ABAP calls that use them — the synchronous surface, including connections to middleware, external engines, and other SAP systems.
- IDoc configuration: partner profiles (WE20), message types, process codes, and the ALE distribution model — plus actual IDoc volume by message type, which is where you learn which of them are still real.
- Released web services and OData services, and the consumers registered against them.
- Batch jobs that read or write files on the application server or an interfaced drive — the quiet, undocumented integration layer that predates every middleware decision the company ever made.
- Custom programs and enhancements whose source contains calls to any of the above. This is the join that matters, because it links an integration point to the business logic wrapped around it.
Declared is not the same as executing
A configuration scan gives you what was set up. Execution evidence gives you what is alive. In a twenty-year-old estate those two lists diverge sharply: partner profiles remain configured for counterparties the business stopped trading with, RFC destinations point at decommissioned hosts, and file jobs still run against directories nobody has read since a prior program.
Filtering on real traffic is the single largest reduction you can apply to integration scope, and it follows the same logic that governs custom code. On a reference estate — a live ECC system used to validate this method, not a specific customer's result — roughly 44% of 356 inventoried custom objects were assessed as retirable because standard S/4HANA already delivers the capability. A customer's numbers come from their own system, and the interface ratio is usually of a similar character: a meaningful share of the declared list is archaeology.
The discipline is to keep the retired entries in the inventory with the evidence attached, rather than deleting them. When someone asks in month six why an interface is not in scope, the answer should be a usage record, not a recollection.
Five facts per interface, then a disposition
An interface inventory is only useful if every row can drive a decision. Five fields do that work, and anything beyond them tends to be commentary.
- Technology and direction — IDoc, RFC, OData, SOAP, file; inbound, outbound, or bidirectional. This determines the test harness and who has to be in the room.
- Counterparty system and its owner, named as a person or team. An interface without a named counterparty owner is an unmanaged dependency, and that is a finding in itself.
- The business process and document type it serves, so integration scope maps onto the same process view as everything else — order-to-cash, procure-to-pay, record-to-report.
- Observed volume and frequency, which separates the interfaces that need a full regression suite from the ones that need a single confirmation run.
- S/4HANA disposition: carries forward unchanged, needs rework because an underlying object changed, or retires. Every row gets exactly one, with the reasoning attached.
What S/4HANA changes, and where agents genuinely help
The rework column is largely predictable, which means it can be planned rather than discovered. Interfaces that carry customer or vendor identifiers meet the business partner model. Interfaces tied to credit blocks and releases meet FSCM credit management. Output-related integrations meet the BRF+ based output framework. Anything reading ECC table structures directly — extracts, reporting feeds, custom RFCs returning table rows — meets a different underlying data model and a CDS view layer that is not the same shape. Those four categories account for most of the genuine interface rework in a typical conversion.
Agents are already useful at the front of this problem. Reading a live system, enumerating destinations and partner profiles, recovering which custom programs call them, checking usage, and mapping each interface onto a process stage is analytical work with verifiable output — and it is exactly the work that turns an assumed integration scope into an evidenced one. That capability exists today and is how the reference-estate figures above were produced.
Execution is a different maturity, and it is worth being precise about it. Our functional-testing agent, which would take an evidenced interface scope and drive the test cases, is in build and design preview — not shipped. Where configuration change is involved, the agent drafts a governed customizing transport and the customer's change board decides whether it lands; development systems only, never production on its own. SAP is pointing in the same broad direction, describing agent-led transformation with a claimed reduction of more than 35% in migration effort (SAP News, Sapphire 2026) — SAP's figure, worth tracking rather than banking.
Frequently asked
How many interfaces does a typical ECC system actually have?
There is no useful benchmark, and reaching for one is how integration scope gets mis-sized. Two companies of comparable revenue and headcount routinely differ by several multiples in live interface count, driven by acquisition history, middleware strategy, and how much file-based integration accumulated before a formal platform existed. Count yours from the system rather than comparing against a peer figure — the count is cheap to obtain and the assumption is expensive to be wrong about.
Do IDocs still work in S/4HANA?
Yes. IDoc remains supported in S/4HANA and a large share of existing IDoc integration carries forward with limited change. The rework is concentrated where the underlying data model moved — segments carrying customer or vendor numbers under the business partner model, and anything tied to classic credit management or output determination. The correct posture is per-message-type assessment, not a blanket assumption that IDocs are either fine or obsolete.
Who should own the interface inventory during the program?
A single named owner on the customer side, not the system integrator, and not a shared spreadsheet. The inventory is a living artifact that drives cutover sequencing and third-party scheduling, so it needs someone accountable for keeping dispositions current as decisions are made. Integrators can produce and maintain it, but the accountability for the third-party dependencies should sit with the organization that owns those commercial relationships.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading