On 31 December 2027, mainstream maintenance for SAP ECC 6.0 ends (SAP), and with the ERP every shop connector coupled to it goes onto the workbench. Anyone synchronizing items, prices, stock and orders between SAP and the online shop today usually runs that interface against ECC technology such as IDoc, BAPI or RFC, building blocks that no longer exist in the same form in SAP S/4HANA. The time pressure is real: by the end of 2024, only 39 percent of ECC customers had moved to S/4HANA (Gartner, via Computerwoche), while around 50 percent still have the entire move ahead of them (DSAG Investment Report 2026). This article shows B2B shop operators what actually happens to the ECC connector, what migration path for the SAP integration exists for existing interfaces, and how to make the switch without the shop losing its ability to sell.
Key takeaways
- Mainstream maintenance for SAP ECC 6.0 ends on 31 December 2027 (SAP). Paid extended maintenance shifts the end to the end of 2030 (SAP) for many systems, but that is a postponement at a premium, not a solution.
- By the end of 2024 only 39 percent (Gartner, via Computerwoche) of ECC customers had moved to S/4HANA, while around 50 percent (DSAG Investment Report 2026) still have the entire move ahead of them.
- What is affected is above all the SAP-side layer of the connector: IDoc, BAPI and RFC give way to released OData and REST services, while transformation and shop side survive if the architecture is decoupled.
- Greenfield, brownfield and the selective approach each affect the interface differently, so the choice has to be settled early. Across all paths clean core applies: extensions live in separate modules instead of in the ERP core.
- The migration path runs through an inventory of all data flows, a decoupled target architecture, the assignment of released standard APIs, a re-adjusted mapping and parallel operation with a fallback plan instead of a hard cutover date.
Why the ECC End of Maintenance Affects Every Coupled Shop
SAP ECC and SAP S/4HANA are not simply two versions of the same program, but two different data models. S/4HANA runs exclusively on the in-memory database SAP HANA, consolidates tables that were once separate, and prefers to expose data through modern OData interfaces. This is exactly where the problem for the shop integration lies: a connector that reads customers, material and documents from the grown ECC tables and exchanges them via IDoc or RFC no longer finds the same structures unchanged in S/4HANA. The interface does not break abruptly on the day maintenance ends, but it loses its technical foundation as soon as the ERP is migrated, and then has to be rebuilt.
The urgency comes from the figures. SAP counts around 35,000 ECC customers, of which only about 14,000 had switched to S/4HANA by the end of 2024 (Gartner, via Computerwoche). Roughly 37 percent of companies plan the move only for the end of 2027 (DSAG Investment Report 2026), right at the maintenance deadline, which further tightens the available project capacity on the market. A paid extended maintenance does shift the end to the end of 2030 for many systems (SAP), but that is a postponement at a premium, not a solution. The trade publication Computerwoche aptly describes the situation as a stalling migration (Computerwoche), in which many companies have so far deferred the interface question.
Behind the deadline sits a data problem. 61 percent (Bitkom, Digitalisation of the Economy 2025) of companies cannot fully exploit their data potential because information sits in unconnected systems. This very separation intensifies when an old ECC connector and a new S/4HANA connector run side by side for a while during the switch. That makes it all the more important to plan the move as a clean transition, in which it is clear at every moment which system leads for which record, rather than letting two competing truths arise. Anyone who settles this question early saves in live operation exactly the reconciliation work that costs the most under time pressure.
Hard Deadline 2027
With maintenance ending on 31 Dec 2027 (SAP), the ECC connector loses its technical foundation as soon as the ERP moves.
IDoc and BAPI Fade Out
S/4HANA relies on OData and REST APIs. Classic IDoc, BAPI and RFC calls are phased out step by step.
New Data Model
Tables and field structures change, for example for customers, material and documents. The field mapping has to be re-adjusted.
Real Time, Not Nightly Run
Where batch runs once synchronized, events and webhooks now enable an integration in real time.
Clean Core as a Rule
Extensions move out of the core into separate extensions so that future updates do not break the interface.
No Stop in Sales
A planned parallel run keeps the shop able to sell while the integration is switched over step by step.
What Technically Happens to Your ECC Connector
A typical ECC shop connector consists of three layers: reading from and writing to SAP, transforming the data, and handing it over to the shop. The middle and shop-side layers remain largely usable in a migration, because your cart, your pricing logic and your product data in the shop do not change through the ERP switch. Affected above all is the SAP-side layer: which tables and function modules are read, over which technology documents flow back, and how number ranges, tax codes and conditions are mapped. This layer is rebuilt against S/4HANA, while the middleware remains as a stable hub.
So the migration is no reason to throw away the entire integration. Anyone who has cleanly decoupled their interface through an intermediate layer only swaps the SAP adapter at the core. Anyone who writes directly into SAP from the shop, by contrast, feels the rebuild in many places at once. That is why the ERP switch is often the right occasion to replace a grown point-to-point connection with a decoupled architecture. How such a rebuild of existing legacy systems is planned is described in detail in the article on migrating legacy systems.
IDoc, BAPI and RFC: What Becomes of the Old Interfaces
In ECC landscapes, data exchanges usually run over IDoc messages, BAPI function modules or direct RFC calls. S/4HANA still supports many of these techniques for compatibility reasons, but explicitly recommends modern, released APIs on an OData and SOAP basis, which SAP publishes in its API Business Hub. For the shop integration this means, concretely: instead of subscribing to an IDoc for stock, the new connector reads availability over an OData service; instead of creating an order via BAPI, it uses a released API endpoint. This changeover not only makes the interface future-proof, but usually leaner and easier to test as well. If no matching standard service exists for a special case, it is added through targeted API development.
| Criterion | ECC connector (today) | S/4HANA integration (future) |
|---|---|---|
| Interface technology | IDoc, BAPI and RFC | OData and REST APIs |
| Extensions | custom code in the core | extensions beside the clean core |
| Maintenance by SAP | ends 31 Dec 2027 | ongoing support |
| Data model | grown ECC tables | unified S/4HANA model |
| Updates | often batch and nightly runs | events and webhooks in real time |
| Outlook | phasing out | supported for years |
Inventory the Interfaces First
Greenfield or Brownfield: Consequences for the Integration
SAP broadly knows three migration paths, and each affects the interface differently. In the greenfield approach, S/4HANA is set up fresh, processes are remodeled and the shop connector is rebuilt from scratch anyway, but cleanly and without legacy burden. In the brownfield approach, the technical conversion of the existing system, many structures are preserved, yet the interfaces in use have to be checked individually for S/4HANA compatibility and partly replaced. The selective approach combines both and migrates step by step. For the shop integration, it is decisive that the choice of path is fixed early, because it determines whether the connector is created anew or adjusted field by field.
Across all three paths stands a principle SAP calls clean core: the ERP core stays as close to standard as possible, extensions sit in clearly separated extensions. This is more than a SAP recommendation, it protects your interface directly, because future updates no longer let the core collide with custom code. Why the clean-core idea makes the shop integration lastingly more stable, and how the SAP Integration Suite helps, is explored in the article on clean-core shop integration with the SAP Integration Suite.
The Migration Path for Your Interfaces
- Take inventory: Record all SAP-shop data flows, with technology, direction and frequency, and separate the critical ones from the rarely used.
- Define the target architecture: Decide whether the integration is decoupled through a central middleware instead of writing directly into SAP from the shop again.
- Assign standard APIs: For each data flow, find the matching released S/4HANA service and plan your own endpoints only where no standard exists.
- Re-adjust the mapping: Check field mappings for customers, items, prices and documents against the S/4HANA model and set up real-time synchronization between SAP and the shop anew.
- Test in parallel and switch: Test in a sandbox against S/4HANA, run the old and new connector in parallel for a while, and only switch finally to the new path after a stable reconciliation.
Beyond the pure technology, data ownership decides the project's success. For every data type, whether item, price, customer or document, it must be clearly defined which system leads and which only reads. This definition belongs before the first line of code, because it determines in which direction a field is synchronized after the migration. If it is skipped, exactly those conflicts arise that only surface late in live operation and can then be fixed only with great effort. A short workshop with the business department and IT is usually enough to fix these direction decisions bindingly before the first adapter is built.
Timeline 2026 and 2027: Why Waiting Gets Expensive
Counting backwards, the deadline gets tight. If around 37 percent of companies plan their move only for 2027 (DSAG Investment Report 2026), many projects meet the same scarce consulting capacity in the same window. An interface migration needs time for inventory, new development, testing in a sandbox and a controlled cutover. Anyone who starts only shortly before the maintenance end risks the shop integration becoming the bottleneck of the entire ERP project. On top of this comes a second date in the same period: the phased e-invoicing mandate from 2027 already demands changes to the document interface that can sensibly be bundled with the S/4HANA switch.
The early-planned move pays off twice. On one hand, there is room to use the migration as an opportunity and clean up outdated processes at the same time. On the other, you decouple shop operations from the time pressure of the ERP project. A customer account that pulls order status and documents from the ERP in real time only works if the underlying interface is in place in time. How such a live order status in the B2B customer account is built depends directly on a stable S/4HANA integration.
The Interface Is Not an Afterthought
Common Mistakes in Connector Migration
- Overlooking side interfaces: Credit notes, partial deliveries or master-data special cases often run over their own, forgotten IDocs that are missing in the new connector.
- Migrating directly instead of decoupled: Anyone who rebuilds the old point-to-point connection one to one gives away the biggest advantage of the move and takes on the same maintenance effort again.
- Testing too late: Without early sandbox tests against S/4HANA, deviating field contents and data conflicts only surface in live operation, as the article on resolving bidirectional data conflicts shows.
- Carrying custom code back into the core: Extensions that land back in the ERP core against the clean-core principle make the next update risky again.
- Cutover without a fallback: A hard switchover date without a parallel run leaves no safe way back if something fails.
The end of maintenance forces not only the ERP to move, but every line attached to it. Anyone who considers the shop interface early migrates once cleanly instead of twice under pressure.