SAP ECC 2027: Shopanbindung beim S/4HANA-Umstieg

SAP hat die Fristen mehrfach bestätigt: Die Mainstream-Wartung für die SAP Business Suite 7, zu der ECC 6.0 gehört, läuft Ende 2027 aus, eine kostenpflichtige erweiterte Wartung ist bis 2030 zu einem Aufschlag von rund 2 Prozentpunkten auf die Wartungsgebühr möglich (Rimini Street, 2025). Danach gibt es keine regulären Sicherheits-Patches und Compliance-Updates mehr. Für ein B2B-Unternehmen mit Online-Shop bedeutet das: Das System, das Preise, Lagerbestände, Kundenstammdaten und Aufträge liefert, verliert seinen Support -- und mit jedem Tag ohne Roadmap schrumpft das Zeitfenster für einen geordneten Übergang.

Die Zahlen zeichnen ein angespanntes Bild. Laut SAPinsider gibt es weltweit noch zwischen 20.000 und 25.000 Bestandskunden, die SAP S/4HANA bislang nicht einmal lizenziert haben (SAPinsider, 2026). Zwar geben 55 Prozent der Befragten an, im vergangenen Jahr S/4HANA in irgendeiner Form ausgerollt zu haben, doch nur 34 Prozent sind vollständig migriert (SAPinsider, 2026). Gleichzeitig planen rund 50 Prozent der Bestandskunden, ihre Migration erst bis Ende 2030 abzuschließen (DSAG-Investitionsreport, 2025). Die Folge ist ein Kapazitätsengpass bei Beratern und Entwicklern, der sich mit näherrückender Frist verschärft.

Der Wechsel von ECC 6.0 auf S/4HANA ist kein reines Versions-Update, sondern eine technische Neuausrichtung des Datenmodells. Tabellenstrukturen werden vereinfacht und zusammengeführt, das Material- und Geschäftspartnermodell ändert sich, und gewachsene Eigenentwicklungen müssen überprüft werden. Genau an diesen Stellen hängen die typischen Shop-Anbindungen: Artikelstammdaten, kundenindividuelle Preislisten, Lagerbestände, Aufträge und Belege. Bricht eine dieser Verbindungen weg, zeigt der Shop falsche Preise, veraltete Bestände oder nimmt Bestellungen nicht mehr korrekt an.

Hinzu kommt, dass viele ECC-Anbindungen über klassische Verfahren wie IDoc, BAPI oder Flat-File-Transfer realisiert wurden. Diese Mechanismen lassen sich nicht ohne Weiteres auf das neue System übertragen: SAP führt im Custom Code Migration Guide aus, dass über Jahre gewachsener kundenspezifischer Code für S/4HANA geprüft und angepasst werden muss, einige BAPIs nicht mehr freigegeben sind und IDoc-/ALE-Technologien in der Cloud-Edition eingeschränkt sind (SAP Custom Code Migration Guide). Eine Horvath-Studie nennt 44 Prozent der Unternehmen, die jahrzehntelange Eigenentwicklungen und Customizing als größte Migrationshürde sehen, und 49 Prozent, für die die Anpassung der Geschäftsprozesse die zentrale Herausforderung darstellt (Horvath, 2025).

Der entscheidende Hebel ist die Entkopplung von Shop und ERP. Statt den Shop direkt mit ECC oder später mit S/4HANA zu verdrahten, vermittelt eine Middleware-Schicht zwischen beiden Welten. Der Shop spricht ausschließlich mit der Middleware über einen stabilen, klar definierten Datenvertrag -- die Middleware übersetzt diesen Vertrag in das jeweils dahinterliegende ERP. Wechselt das ERP, ändert sich nur der ERP-seitige Adapter in der Middleware, nicht aber die Shop-Anbindung.

Dieser Ansatz folgt dem Prinzip der losen Kopplung: Shop und ERP können unabhängig voneinander aktualisiert, getestet und ausgetauscht werden, solange der API-Vertrag eingehalten wird. Für den S/4HANA-Umstieg ist das der Schlüssel, denn er erlaubt einen Parallelbetrieb. Während das alte ECC noch produktiv ist, kann der S/4HANA-Adapter bereits aufgebaut und getestet werden. Am Cutover-Tag wird in der Middleware umgeschaltet -- der Shop merkt davon im Idealfall nichts. Bei einer durchdachten Schnittstellenarchitektur bleibt die Ausfallzeit minimal.

Für den Umstieg gibt es mehrere Wege. Beim Brownfield-Ansatz wird das bestehende System technisch konvertiert, beim Greenfield-Ansatz auf der grünen Wiese neu aufgebaut, und beim selektiven Ansatz werden Teile schrittweise überführt. Laut SAP-eigener Einschätzung dauert die Migration von SAP ERP zu SAP S/4HANA typischerweise 12 bis 18 Monate, eine reine Systemkonvertierung je nach System-Delta zwischen 6 Monaten und einem Jahr (SAP PRESS, 2025). Unabhängig von der gewählten Strategie gilt: Die Shopanbindung ist in jedem Szenario betroffen und profitiert in jedem Szenario von einer entkoppelten Schicht.

Die Wahl der Strategie ist eine betriebswirtschaftliche und technische Abwägung, die in der Regel im Schulterschluss mit dem ERP-Partner getroffen wird. Unsere Rolle als Schnittstellen-Partner setzt davor an: Wir sorgen dafür, dass die Shopanbindung den gewählten Weg unbeschadet übersteht. Das entkoppelt die beiden Projekte voneinander -- das ERP-Team kann migrieren, ohne auf den Shop warten zu müssen, und der Shop bleibt verkaufsfähig.

Die Erfahrung aus dem Markt ist ernüchternd. Laut der Horvath-Studie 2025 haben 60 Prozent aller bisherigen Migrationsprojekte ihr Budget, ihren Zeitplan oder beides überschritten (Horvath, 2025). Im Schnitt dauern die Projekte rund 30 Prozent länger als ursprünglich geplant, und weniger als jedes zehnte Unternehmen, das die Transformation bereits abgeschlossen hat, blieb im Zeitrahmen (Horvath, 2025). Zwei Drittel der Befragten zeigten sich mit der Ergebnisqualität unzufrieden (Horvath, 2025).

Die Ursachen sind selten rein technisch. Häufig genannt werden eine Ausweitung des Projektumfangs während der Laufzeit, unterschätzte Test- und Datenmigrationsphasen sowie organisatorischer Widerstand -- den 37 Prozent der Unternehmen als Hürde nennen (Horvath, 2025). Nur 21 Prozent der Unternehmen, die externe Unterstützung für ihre SAP-Transformation hinzuziehen, investieren dabei in Change-Management-Spezialisten (SAPinsider, 2025). Eine früh entkoppelte Shopanbindung nimmt aus dieser Gemengelage einen Risikofaktor heraus: Die Verkaufsplattform hängt nicht mehr am kritischen Pfad der ERP-Migration.

Ein oft unterschätzter Aspekt ist die Sicherheits- und Compliance-Lage nach dem Wartungsende. Solange ein System in der Mainstream-Wartung steht, liefert der Hersteller regelmäßig Sicherheits-Patches und Anpassungen an geänderte gesetzliche Anforderungen. Mit dem Auslaufen Ende 2027 endet dieser Schutz für ECC 6.0 in der regulären Wartung. Wer ein System mit Kundendaten, Preisinformationen und Auftragsdaten betreibt, das ungepatcht bleibt, vergrößert seine Angriffsfläche und erschwert die Einhaltung von Vorgaben wie der DSGVO und den GoBD. Das gilt umso mehr, wenn dieses System über eine Schnittstelle direkt mit einem öffentlich erreichbaren Online-Shop verbunden ist.

Auch hier wirkt die Entkopplung risikomindernd. Eine Middleware mit klar definiertem Datenvertrag begrenzt die Kommunikationswege zwischen Shop und ERP auf das fachlich Notwendige. Der Shop erhält keinen direkten Datenbankzugriff auf das ERP, sondern nur die abgestimmten Entitäten über kontrollierte Endpunkte. Diese Trennung erleichtert es, Datenflüsse zu dokumentieren, Berechtigungen zu steuern und den Übergang auf das aktiv gewartete S/4HANA sauber nachzuvollziehen. Für die Nachweispflichten bei einer Betriebsprüfung ist eine durchgängige, protokollierte Belegkette ein praktischer Vorteil.

Im Zentrum der entkoppelten Architektur steht der Datenvertrag zwischen Shop und Middleware. Er definiert, welche Entitäten in welcher Struktur ausgetauscht werden -- Artikel, Preise, Bestände, Kunden, Aufträge und Belege. Dieser Vertrag bleibt über den ERP-Wechsel hinweg stabil. Die eigentliche Übersetzung in die jeweilige ERP-Struktur findet in der Adapter-Ebene statt, die für ECC und S/4HANA getrennt implementiert wird. So liegt die Komplexität der Modellunterschiede dort, wo sie hingehört: in der Middleware, nicht im Shop.

Ein sauberes Mapping ist dabei der häufigste Knackpunkt. Laut Gartner scheitern 83 Prozent aller Datenmigrationsprojekte oder überschreiten Budget und Zeitplan, wobei mangelhafte Datenqualität als häufigste Ursache gilt (Gartner). Eine Mapping-Tabelle, die vor Projektbeginn erstellt und von Fach- und IT-Seite abgenommen wird, reduziert dieses Risiko erheblich. Sie dokumentiert, wie Felder, Einheiten und Hierarchien zwischen den Systemen aufeinander abgebildet werden -- und bildet zugleich die Prüfgrundlage für den Parallelbetrieb. Wer hier auf eine professionelle PIM-Integration setzt, hält die Produktdaten zwischen den Systemen konsistent.

Ein migrationsfestes Schnittstellenprojekt lässt sich in klare Phasen gliedern. Anders als die ERP-Migration selbst, deren Dauer stark vom gewählten Ansatz abhängt, ist die Vorbereitung der entkoppelten Shopanbindung in einem überschaubaren Zeitrahmen umsetzbar -- und sie sollte deutlich vor dem ERP-Cutover beginnen.

Für die Shop-Seite setzen wir auf Shopware in der Open-Source-Variante. Die offene Architektur und die API-First-Ausrichtung passen gut zu einer entkoppelten Integration: Der Shop konsumiert den Datenvertrag über definierte Schnittstellen, ohne dass interne ERP-Spezifika in den Shop durchschlagen. So bleibt die Verkaufsplattform unabhängig vom ERP-Lebenszyklus -- ein Vorteil, der über den aktuellen S/4HANA-Umstieg hinausreicht und auch künftige Systemwechsel abfedert.

Im B2B-Kontext sind dabei die typischen Anforderungen abzubilden: kundenindividuelle Preise und Staffeln, Bestelllisten, Freigabeprozesse und Self-Service-Funktionen im Kundenportal. All diese Funktionen greifen über den stabilen Datenvertrag auf das ERP zu. Wechselt das Backend von ECC auf S/4HANA, bleiben die B2B-Funktionen unverändert nutzbar. Wer parallel die Digitalisierung des Vertriebs vorantreibt, findet im Beitrag zu digitalisierten B2B-Vertriebsprozessen weitere Ansatzpunkte.

Auch das wachsende Thema der Auffindbarkeit in KI-gestützten Einkaufsprozessen profitiert von konsistenten Produktdaten. Wie sich Geschäftskunden zunehmend über KI-Systeme informieren und welche Rolle saubere Daten dabei spielen, beleuchtet der Beitrag zur KI-gestützten B2B-Produktsuche. Eine entkoppelte, gepflegte Schnittstelle ist die technische Voraussetzung dafür, dass diese Daten überhaupt verlässlich im Shop ankommen.