How to Keep Enterprise Integrations Stable During an SAP S/4HANA Migration

An SAP migration is also an integration project. When connected systems talk to SAP through an integration layer, that layer can absorb much of the change. For most of the 30 existing interfaces (roughly 80%) adjusted mappings kept each interface exactly as it was, and the calling systems did not notice the switch.

An SAP S/4HANA migration is also an integration project because every system that exchanges data with SAP depends on its data structures and interfaces. Replace the ERP system, and each of those connections must be checked, adapted, or rebuilt.

In this project, 18 systems and external stakeholders exchanged data through Scheer PAS, including SAP S/4HANA itself, the enterprise data platform (formerly the data warehouse), databases, dealer systems, parent and national companies, agencies, public authorities, service providers, HR and user-management systems, blob storage, job scheduling, an online shop, banks, insurance companies, and mobility service providers.

Few of them can adapt to the migration’s schedule. A bank, an authority, or an external agency rarely adapts its interface because one of its partners migrates its ERP system.

For most of the 30 (roughly 80%) the team adjusted the mappings in Scheer PAS so that each interface behaved exactly as it had before the switch. The calling systems did not notice the migration at all. The interfaces to a bank within the group show why that mattered: the bank runs a large number of legacy applications, so its interfaces had to stay exactly as they were. For a few interfaces, fundamental changes to the SAP data structures made this impossible. There, the team first tried to work only the necessary changes into the existing interfaces and built completely new interfaces where even that was not possible.

That is the core argument for an integration layer during a migration. Each interface has a contract with the systems that use it. If the contract holds, the migration stays as an SAP project for those systems. If it breaks, every consumer becomes part of the migration. A stable structure does not remove the need for end-to-end tests, because values and meanings can still change with SAP S/4HANA. But it turns a rebuild into a regression test.

Many different technologies are easier to manage during an SAP migration when all of them connect through one integration layer. Each system keeps its own protocol and format. The integration layer translates between them, so the migration deals with one set of mappings, patterns, and monitoring instead of one per technology.

In this project, that covered five kinds of connections: modern APIs over REST and OData, established enterprise interfaces such as SOAP services and SAP Remote Function Calls (RFC), message-based communication over JMS, SQL access to databases, and file-based exchange. Data arrived as XML, JSON, or flat files, and UiPath was used for robotic process automation (RPA).

Recurring integration patterns and reusable libraries meant that the same kind of problem did not need a separate solution for every connection.

Logging, monitoring, and reusable design matter in an SAP migration because an interface that works on go-live day still has to keep working afterwards. The project established central, consistent logging and monitoring across the interfaces, providing a central place to observe and track interface activity, regardless of protocol.

Integration patterns and recurring designs were applied across connections, and common functions were bundled into reusable libraries. With 180 interfaces, that matters. A known pattern does not have to be reinvented for every connection, and a change to a library reaches every interface that uses it, which is also why library changes need versioning and regression tests.

Agentic orchestration needs a controlled integration layer because an AI agent working across SAP and connected systems should follow the same rules as every other caller. An agent that calls SAP directly bypasses the mappings, validation, and logging every other consumer relies on. It can write data in a form that a bank interface, a dealer system, or the enterprise data platform does not expect, without a central log entry showing where it came from.

The migration produced a foundation an agent could build on: defined interfaces, mappings, central logging, and reusable libraries. Agentic orchestration can coordinate tasks across several systems, while the integration layer handles the technical communication with them. Patterns and libraries like these can serve as controlled building blocks for agents, instead of each agent building its own connection. In Scheer PAS, agents built with PAS Code are a feature of a service: they have no endpoint of their own and can only be reached through that service.

No AI agents were used in this project. The integration foundation described here is a precondition for using them later.

AI agents working across SAP and connected systems need guardrails that protect interface contracts, because data an agent writes in the wrong form can reach every consumer of an interface. Three matter most here. 

Permission boundaries per system.

An agent should only call specific operations on specific systems. For example, an agent might be allowed to read order data from SAP S/4HANA, but not to write to the bank or insurance interfaces. 

Validation before the target system.

Data should be validated and transformed in the integration layer before it reaches SAP or any connected system, against the same structures the existing consumers expect. 

Approval for irreversible actions.

Postings, payments, or data sent to external parties should wait for human approval. 

How Scheer PAS defines which operations an agent may execute, and the general requirements for agent governance, are covered in AI Agent Governance: Why Agentic Orchestration Needs a Controlled Integration Layer.