SAP Integration Suite: Clean-Core Shop Link 2026

Discussion around the ECC end of maintenance usually centres on financials, logistics and master data -- the online shop rarely features. That is exactly the problem. In many mid-market landscapes the shop hangs off the ERP through an interface that has grown over the years: a PI/PO scenario here, a direct RFC call there, plus bespoke Z-code that transforms article, stock and order data. As long as ECC is running, this works. The move to S/4HANA, however, changes data models, tables and function modules -- and the very places where custom code reaches into the core become the brake on migration.

The time pressure is real. According to Gartner, around two-thirds of ECC customers were still in the planning stage of their migration at the end of 2024, with a further eight percent intending to stay on ECC beyond 2027 (Gartner, via The Register, 2026) -- anyone who starts late is unlikely to finish cleanly before the deadline. A typical brownfield project takes 9 to 15 months, a greenfield project 12 to 24 months (Basis Admin, 2026). At the same time, the Horvath Study 2025 found that around 60 percent of migration projects to date have exceeded budget, timeline or both (Horvath, 2025). A shop connection that only surfaces as a blocker at go-live makes precisely this risk worse. Thinking about the cut early and lifting the integration onto a future-proof platform removes a whole stack of surprises from the project.

Some context matters here: SAP has indicated an extension of maintenance to 2033 for on-premise ERP customers under certain conditions (Forrester, 2025). That does not move the date for everyone, however, and changes nothing about the fundamental direction -- the innovation path leads to S/4HANA and the platform layer. Extended maintenance buys time; it does not replace a strategy. That is exactly why it pays to build the shop connection in a future-proof way regardless of the specific ERP date: it is, after all, the part most visible to customers and the least tolerant of downtime. A frozen or faultily migrated shop hits revenue immediately, whereas internal modules can absorb a bumpy cutover more easily.

Clean core is SAP's guiding principle for S/4HANA: the application core stays unchanged -- no directly modified SAP tables, no overridden standard programs, no calls to internal, unreleased objects from your own code. Extensions and integrations instead run through published interfaces: released OData services or event-based integration via the SAP Integration Suite. The benefit: as long as the core stays clean, upgrades can be applied quickly and predictably, instead of touching custom code every time.

For the shop connection this is a paradigm shift. Instead of maintaining Z-logic in the SAP core that prepares product and order data for the shop, that logic moves into the platform layer: into Cloud Integration flows (iFlows), into managed APIs and into event subscriptions. The scale of the lever is clear from the starting point: 91 percent of SAP users rely on custom code for business-critical processes, and at 57 percent of organisations up to half of those critical processes hang off such custom code (ASUG, 2021). The more of this logic moves into the platform layer rather than the core, the lower the depth of modification -- and the cheaper development, maintenance and support become. Organisations that adopted BTP extensions early spend 30 to 40 percent less on annual system maintenance, according to industry analyses (ERP Implementation EU, 2026).

Economically, clean core shifts cost away from ongoing maintenance towards a one-off, predictable changeover. As long as Z-logic sits in the core, every release change incurs regression effort: adaptations have to be checked, tested and reapplied. When the same logic sits in an iFlow, it is decoupled from the ERP's release cycle. This not only lowers annual maintenance cost but also makes resource planning more predictable -- a factor that weighs increasingly heavily given scarce SAP capacity. Industry analyses also report that around half of SAP customers now actively use BTP services, with a clearly rising trend (ERP Implementation EU, 2026); the platform layer is therefore no longer a niche path but the established standard route.

The SAP Integration Suite is the recommended successor integration platform on the SAP Business Technology Platform (BTP). It bundles several capabilities into one iPaaS environment -- including Cloud Integration, API Management, Event Mesh, Open Connectors and the Integration Advisor (SAP Learning, 2026). Three of these are central to an event-driven shop connection.

The core of a clean-core-compliant shop connection is the event-based architecture. Instead of polling the shop at fixed intervals to see whether something has changed, S/4HANA publishes an event as soon as it occurs -- a stock movement, a price change or a new business partner, for example. The Integration Suite receives this event via the Event Mesh, transforms it in the iFlow and delivers it to the shop through its API. How this differs technically from cyclical polling is examined in detail in our article on webhooks and polling in shop integration.

The decisive point: all of this happens through the platform layer, not in the SAP core. The transformation logic sits in the iFlow, endpoint security in API Management, decoupling in the Event Mesh. As a result, the connection does not have to be reinvented when moving from ECC to S/4HANA -- at most the source objects change, not the entire integration route. For a deeper look, our article on event-driven architecture with message queues covers the patterns for decoupling and buffering.

For an event-driven route to stay reliable, observability and error handling belong in from the start. The Event Mesh decouples source and sink, so a briefly unreachable shop API does not swallow an event -- the message is buffered and delivered later. If a message remains permanently undeliverable, it lands in a dedicated store and triggers a notification instead of being lost silently. How to monitor such routes and design them for idempotency, so that a repeated delivery does not create an order twice, is explored in the article on observability and monitoring of interfaces. It is precisely this central view that replaces the tedious search through scattered log files of individual Z-programs.

Years of in-house development -- Z-objects, BAdI implementations, overrides of standard programs -- have left deep marks in virtually every ECC system; the path to clean core thus becomes a remediation programme that SAP addresses specifically through its Custom Code Migration Guide (SAP, 2025). It is precisely these interventions that are expensive in migration: every modification has to be checked, assessed and adapted in the Simplification Item Check. The Simplification Item Check is regarded as the single most common source of budget overruns in brownfield projects (Basis Admin, 2026).

The second brake is the data model change itself. S/4HANA merges tables, introduces the Universal Journal and renames fields. If a shop connection accesses ECC tables or internal function modules directly, those very reference points shift beneath the interface -- often unnoticed until incorrect or missing data surfaces in testing. A connection built on published OData services and events is largely shielded from such internal rebuilds, because SAP keeps the released interfaces stable across version changes. The connection then follows a contract, not an internal implementation.

On top of this comes the resource bottleneck. SAP counted around 35,000 ECC customers worldwide at the end of 2024, most of which still face the migration (Gartner, via The Register, 2026), and Europe faces a growing shortage of S/4HANA specialists (Computer Weekly, 2025). Anyone who throws their shop connection at a thin staffing base only shortly before go-live competes with everyone else for the same scarce profiles. Industry analyses also show that classic ABAP knowledge is no longer enough today -- experience with BTP, Fiori and API integration is in demand (Rimini Street, 2026). A connection built on the Integration Suite from the outset rests on exactly these future-proof skills.

An existing shop connection can usually be lifted onto the Integration Suite step by step, without interrupting live operations. A proven approach first decouples the interface and pulls the business logic out of the core before the ERP itself is migrated.

The parallel run is more than a precaution here -- it is the actual lever for keeping the migration cut low-risk. As long as the old and new routes run simultaneously, the results can be reconciled record by record: if stock, price and order status match on both paths, the new connection is dependable. Only once this reconciliation is stable over several days does the switchover happen. This method decouples the shop migration in time from the ERP migration: the integration layer can already be clean-core-compliant while the ERP is still being converted in the background -- or vice versa. The shop stays reachable throughout.

A frequent special case is e-invoicing: with the stage of the e-invoicing obligation taking effect from 2027, ERP and shop must exchange structured invoice data. How this embeds into the interface is explored in the article on the 2027 e-invoicing obligation at the ERP-shop interface. If you come from a different ERP world, the article on the Dynamics 365 BC connection via API v2 provides the counterpart for the Microsoft side.

Regardless of the source system, the goal stays the same: a connection that follows the published contract rather than internal implementation details. Anchoring this principle early yields robustness not only for the upcoming S/4HANA migration but also for the future release changes that follow. The investment in a platform-based shop integration therefore pays into every further modernisation beyond the 2027 deadline -- and takes online sales out of the role of an uncertain appendage that has to be renegotiated at every ERP step.