SAP ECC 2027: Shop Integration for the S/4HANA Switch

SAP has confirmed the dates repeatedly: mainstream maintenance for SAP Business Suite 7, which includes ECC 6.0, ends at the close of 2027, with paid extended maintenance available through 2030 at a surcharge of around 2 percentage points on the maintenance fee (Rimini Street, 2025). After that, there are no regular security patches and compliance updates. For a B2B company with an online store this means: the system that supplies prices, inventory, customer master data and orders loses its support -- and with every day without a roadmap, the window for an orderly transition shrinks.

The numbers paint a tense picture. According to SAPinsider, there are still between 20,000 and 25,000 existing customers worldwide who have not even licensed SAP S/4HANA (SAPinsider, 2026). While 55 percent of respondents say they deployed S/4HANA in some form over the past year, only 34 percent are fully migrated (SAPinsider, 2026). At the same time, around 50 percent of existing customers plan to complete their migration only by the end of 2030 (DSAG Investment Report, 2025). The result is a capacity bottleneck among consultants and developers that intensifies as the deadline approaches.

Moving from ECC 6.0 to S/4HANA is not a mere version update but a technical realignment of the data model. Table structures are simplified and merged, the material and business partner models change, and grown custom developments must be reviewed. This is exactly where typical store connections hang: item master data, customer-specific price lists, inventory, orders and documents. If one of these connections drops out, the store shows wrong prices, outdated stock or stops accepting orders correctly.

In addition, many ECC connections were built using classic methods such as IDoc, BAPI or flat-file transfer. These mechanisms cannot simply be carried over to the new system: SAP states in its Custom Code Migration Guide that years of grown custom code must be assessed and adapted for S/4HANA, that some BAPIs are no longer released and that IDoc and ALE technologies are restricted in the Cloud edition (SAP Custom Code Migration Guide). A Horvath study names 44 percent of companies who see decades of custom development and customizing as the biggest migration hurdle, and 49 percent for whom adapting business processes is the central challenge (Horvath, 2025).

The decisive lever is decoupling the store from the ERP. Instead of wiring the store directly to ECC or later to S/4HANA, a middleware layer mediates between the two worlds. The store talks exclusively to the middleware via a stable, clearly defined data contract -- the middleware translates this contract into the underlying ERP. When the ERP changes, only the ERP-side adapter in the middleware changes, not the store connection.

This approach follows the principle of loose coupling: store and ERP can be updated, tested and replaced independently of each other as long as the API contract is honored. For the S/4HANA switch this is the key, because it enables parallel operation. While the old ECC is still in production, the S/4HANA adapter can already be built and tested. On cutover day, the switch happens inside the middleware -- ideally the store notices nothing. With a well-designed interface architecture, downtime stays minimal.

There are several paths for the switch. The brownfield approach technically converts the existing system, the greenfield approach rebuilds from scratch, and the selective approach moves parts step by step. According to SAP's own estimate, migrating from SAP ERP to SAP S/4HANA typically takes 12 to 18 months, while a pure system conversion takes between 6 months and one year depending on the system delta (SAP PRESS, 2025). Regardless of the chosen strategy: the store integration is affected in every scenario and benefits in every scenario from a decoupled layer.

Choosing the strategy is a business and technical trade-off usually made hand in hand with the ERP partner. Our role as integration partner sits in front of that: we make sure the store integration survives the chosen path unharmed. This decouples the two projects from each other -- the ERP team can migrate without waiting for the store, and the store stays sales-ready.

The market experience is sobering. According to the Horvath study 2025, 60 percent of all migration projects to date have exceeded their budget, their schedule or both (Horvath, 2025). On average, projects take around 30 percent longer than originally planned, and fewer than one in ten companies that have already completed the transformation stayed within their timeline (Horvath, 2025). Two thirds of respondents were dissatisfied with the result quality (Horvath, 2025).

The causes are rarely purely technical. Frequently cited are scope expansion during the project, underestimated testing and data migration phases, and organizational resistance -- which 37 percent of companies name as a hurdle (Horvath, 2025). Only 21 percent of companies that bring in external support for their SAP transformation invest in change-management specialists (SAPinsider, 2025). An early-decoupled store integration takes one risk factor out of this mix: the sales platform no longer sits on the critical path of the ERP migration.

An often underestimated aspect is the security and compliance situation after maintenance ends. As long as a system is in mainstream maintenance, the vendor regularly delivers security patches and adjustments to changed legal requirements. With the end of 2027, this protection for ECC 6.0 ends in regular maintenance. Anyone operating a system with customer data, price information and order data that remains unpatched increases their attack surface and makes it harder to comply with requirements such as the GDPR and German GoBD rules. This is all the more true when that system is connected via an interface directly to a publicly reachable online store.

Here too, decoupling reduces risk. A middleware with a clearly defined data contract limits the communication paths between store and ERP to what is functionally necessary. The store gets no direct database access to the ERP, only the agreed entities via controlled endpoints. This separation makes it easier to document data flows, control permissions and cleanly trace the transition to the actively maintained S/4HANA. For documentation obligations during a tax audit, a continuous, logged document chain is a practical advantage.

At the center of the decoupled architecture is the data contract between store and middleware. It defines which entities are exchanged in which structure -- items, prices, stock, customers, orders and documents. This contract stays stable across the ERP switch. The actual translation into the respective ERP structure happens in the adapter layer, implemented separately for ECC and S/4HANA. This places the complexity of the model differences where it belongs: in the middleware, not in the store.

Clean mapping is the most frequent sticking point. According to Gartner, 83 percent of all data migration projects fail or exceed budget and schedule, with poor data quality cited as the most common cause (Gartner). A mapping table created before project start and approved by both business and IT significantly reduces this risk. It documents how fields, units and hierarchies are mapped between the systems -- and at the same time forms the basis for verifying parallel operation.

A migration-proof interface project can be structured into clear phases. Unlike the ERP migration itself, whose duration depends heavily on the chosen approach, preparing the decoupled store integration is achievable within a manageable timeframe -- and it should begin well before the ERP cutover.

On the store side we rely on Shopware in the open-source variant. The open architecture and API-first orientation fit well with a decoupled integration: the store consumes the data contract via defined interfaces, without internal ERP specifics bleeding into the store. This keeps the sales platform independent of the ERP lifecycle -- an advantage that reaches beyond the current S/4HANA switch and also cushions future system changes.

In the B2B context the typical requirements must be mapped: customer-specific prices and tiers, order lists, approval processes and self-service functions in the customer portal. All of these functions access the ERP via the stable data contract. When the backend changes from ECC to S/4HANA, the B2B functions remain usable unchanged. Those who are also advancing sales digitalization will find further starting points in the article on digitalized B2B sales processes.

The growing topic of discoverability in AI-assisted purchasing also benefits from consistent product data. How business customers increasingly inform themselves via AI systems, and what role clean data plays in this, is examined in the article on AI-assisted B2B product search. A decoupled, well-maintained interface is the technical prerequisite for this data to arrive reliably in the store at all.