Am 31. Dezember 2027 endet die Standardwartung für SAP ECC 6.0 (SAP), und mit dem ERP wandert auch jeder daran gekoppelte Shop-Connector auf die Werkbank. Wer heute Artikel, Preise, Bestände und Aufträge zwischen SAP und dem Online-Shop synchronisiert, betreibt diese Schnittstelle in aller Regel gegen ECC-Technik wie IDoc, BAPI oder RFC, also gegen Bausteine, die es in SAP S/4HANA so nicht mehr gibt. Der Zeitdruck ist real: Bis Ende 2024 waren erst 39 Prozent der ECC-Kunden auf S/4HANA umgestiegen (Gartner, via Computerwoche), rund 50 Prozent haben den Umstieg noch komplett vor sich (DSAG-Investitionsreport 2026). Dieser Beitrag zeigt B2B-Shop-Betreibern, was mit dem ECC-Connector konkret passiert, welchen Migrationspfad für die SAP-Anbindung es für bestehende Schnittstellen gibt und wie der Wechsel gelingt, ohne dass der Shop verkaufsunfähig wird.
Das Wichtigste in Kürze
- Am 31. Dezember 2027 endet die Standardwartung für SAP ECC 6.0 (SAP). Eine kostenpflichtige Extended Maintenance verschiebt das Ende für viele Systeme auf Ende 2030 (SAP), ist aber ein Aufschub gegen Aufpreis und keine Lösung.
- Bis Ende 2024 waren erst 39 Prozent (Gartner, via Computerwoche) der ECC-Kunden auf S/4HANA umgestiegen, rund 50 Prozent (DSAG-Investitionsreport 2026) haben den Umstieg noch komplett vor sich.
- Betroffen ist vor allem die SAP-seitige Schicht des Connectors: IDoc, BAPI und RFC weichen freigegebenen OData- und REST-Services, während Transformation und Shop-Seite bei entkoppelter Architektur erhalten bleiben.
- Greenfield, Brownfield und selektiver Ansatz wirken unterschiedlich auf die Schnittstelle, deshalb muss die Wahl früh feststehen. Quer über alle Wege gilt Clean Core: Erweiterungen liegen in getrennten Extensions statt im ERP-Kern.
- Der Migrationspfad führt über die Bestandsaufnahme aller Datenflüsse, eine entkoppelte Zielarchitektur, die Zuordnung freigegebener Standard-APIs, ein neu justiertes Mapping und einen Parallelbetrieb mit Rückfallplan statt hartem Umschalttermin.
Warum das ECC-Wartungsende jeden gekoppelten Shop betrifft
SAP ECC und SAP S/4HANA sind nicht einfach zwei Versionen desselben Programms, sondern zwei unterschiedliche Datenmodelle. S/4HANA läuft ausschließlich auf der In-Memory-Datenbank SAP HANA, fasst früher getrennte Tabellen zusammen und stellt Daten bevorzugt über moderne OData-Schnittstellen bereit. Genau hier liegt das Problem für die Shop-Anbindung: Ein Connector, der Kunden, Material und Belege aus den gewachsenen ECC-Tabellen liest und über IDoc oder RFC austauscht, findet dieselben Strukturen in S/4HANA nicht mehr unverändert vor. Die Schnittstelle bricht also nicht am Tag des Wartungsendes schlagartig ab, aber sie verliert ihre technische Grundlage, sobald das ERP migriert wird, und muss dann neu aufgebaut werden.
Die Dringlichkeit ergibt sich aus den Zahlen. SAP zählt rund 35.000 ECC-Kunden, von denen bis Ende 2024 nur etwa 14.000 auf S/4HANA gewechselt waren (Gartner, via Computerwoche). Etwa 37 Prozent der Betriebe planen den Umstieg erst bis Ende 2027 (DSAG-Investitionsreport 2026), also punktgenau zum Wartungsende, was die verfügbaren Projektkapazitäten am Markt weiter verknappt. Eine kostenpflichtige Extended Maintenance verschiebt das Ende zwar für viele Systeme auf Ende 2030 (SAP), doch das ist ein Aufschub gegen Aufpreis, keine Lösung. Der Branchendienst Computerwoche beschreibt die Lage treffend als stockende Migration (Computerwoche), bei der viele Betriebe die Schnittstellenfrage bislang aufgeschoben haben.
Hinter dem Termin steht ein Datenthema. 61 Prozent (Bitkom, Digitalisierung der Wirtschaft 2025) der Unternehmen können ihr Datenpotenzial nicht voll ausschöpfen, weil Informationen in unverbundenen Systemen liegen. Genau diese Trennung verschärft sich, wenn während der Umstellung ein alter ECC-Connector und ein neuer S/4HANA-Connector eine Zeit lang nebeneinander laufen. Umso wichtiger ist es, den Wechsel als sauberen Übergang zu planen, bei dem zu jedem Zeitpunkt klar ist, welches System für welchen Datensatz führend ist, statt zwei konkurrierende Wahrheiten entstehen zu lassen. Wer diese Frage früh klärt, spart sich im Livebetrieb genau die Abstimmungen, die unter Termindruck am meisten kosten.
Harte Frist 2027
Mit dem Wartungsende am 31.12.2027 (SAP) verliert der ECC-Connector seine technische Grundlage, sobald das ERP umzieht.
IDoc und BAPI entfallen
S/4HANA setzt auf OData- und REST-APIs. Klassische IDoc-, BAPI- und RFC-Aufrufe werden schrittweise abgelöst.
Neues Datenmodell
Tabellen und Feldstrukturen ändern sich, etwa bei Kunden, Material und Belegen. Die Feldzuordnung muss neu justiert werden.
Echtzeit statt Nachtlauf
Wo früher Batch-Läufe synchronisierten, ermöglichen Events und Webhooks eine Anbindung in Echtzeit.
Clean Core als Vorgabe
Erweiterungen wandern aus dem Kern in separate Extensions, damit künftige Updates die Schnittstelle nicht brechen.
Kein Verkaufsstopp
Ein geplanter Parallelbetrieb hält den Shop verkaufsfähig, während die Anbindung Schritt für Schritt umgestellt wird.
Was mit Ihrem ECC-Connector technisch passiert
Ein typischer ECC-Shop-Connector besteht aus drei Schichten: dem Auslesen und Schreiben in SAP, der Transformation der Daten und der Übergabe an den Shop. Die mittlere und die shopseitige Schicht bleiben bei einer Migration weitgehend nutzbar, denn Ihr Warenkorb, Ihre Preislogik und Ihre Produktdaten im Shop ändern sich durch den ERP-Wechsel nicht. Betroffen ist vor allem die SAP-seitige Schicht: Welche Tabellen und Funktionsbausteine ausgelesen werden, über welche Technik Belege zurückfließen und wie Nummernkreise, Steuerkennzeichen und Konditionen abgebildet sind. Diese Schicht wird neu gegen S/4HANA gebaut, während die Middleware als stabile Drehscheibe erhalten bleibt.
Damit ist die Migration kein Grund, die gesamte Integration wegzuwerfen. Wer seine Schnittstelle sauber über eine Zwischenschicht entkoppelt hat, tauscht im Kern nur den SAP-Adapter aus. Wer dagegen direkt aus dem Shop heraus in SAP schreibt, spürt den Umbau an vielen Stellen zugleich. Deshalb ist der ERP-Wechsel oft der richtige Anlass, eine gewachsene Punkt-zu-Punkt-Verbindung durch eine entkoppelte Architektur zu ersetzen. Wie ein solcher Umbau bestehender Altsysteme geplant wird, beschreibt der Beitrag zur Migration von Legacy-Systemen ausführlich.
IDoc, BAPI und RFC: was aus den alten Schnittstellen wird
In ECC-Landschaften laufen Datenaustausche meist über IDoc-Nachrichten, BAPI-Funktionsbausteine oder direkte RFC-Aufrufe. S/4HANA unterstützt viele dieser Techniken aus Kompatibilitätsgründen zwar noch, empfiehlt aber ausdrücklich moderne, freigegebene APIs auf OData- und SOAP-Basis, die SAP im API Business Hub veröffentlicht. Für die Shop-Anbindung heißt das konkret: Statt ein IDoc für den Bestand zu abonnieren, liest der neue Connector die Verfügbarkeit über einen OData-Service; statt einen Auftrag per BAPI anzulegen, nutzt er einen freigegebenen API-Endpunkt. Diese Umstellung macht die Schnittstelle nicht nur zukunftsfest, sondern in der Regel auch schlanker und besser testbar. Fehlt für einen Sonderfall ein passender Standard-Service, wird er über eine gezielte API-Entwicklung ergänzt.
| Kriterium | ECC-Connector (heute) | S/4HANA-Anbindung (künftig) |
|---|---|---|
| Schnittstellentechnik | IDoc, BAPI und RFC | OData- und REST-APIs |
| Erweiterungen | Custom-Code im Kern | Extensions neben dem Clean Core |
| Wartung durch SAP | endet 31.12.2027 | laufender Support |
| Datenmodell | gewachsene ECC-Tabellen | vereinheitlichtes S/4HANA-Modell |
| Aktualisierung | oft Batch und Nachtläufe | Events und Webhooks in Echtzeit |
| Perspektive | auslaufend | auf Jahre unterstützt |
Schnittstellen zuerst inventarisieren
Greenfield oder Brownfield: Folgen für die Anbindung
SAP kennt grob drei Migrationswege, und jeder wirkt anders auf die Schnittstelle. Beim Greenfield-Ansatz wird S/4HANA neu aufgesetzt, Prozesse werden neu modelliert und der Shop-Connector ohnehin komplett neu gebaut, dafür sauber und ohne Altlasten. Beim Brownfield-Ansatz, der technischen Konvertierung des bestehenden Systems, bleiben viele Strukturen erhalten, doch die genutzten Schnittstellen müssen einzeln auf S/4HANA-Kompatibilität geprüft und teilweise ersetzt werden. Der selektive Ansatz kombiniert beides und migriert schrittweise. Für die Shop-Anbindung ist entscheidend, dass die Wahl des Weges früh feststeht, weil sie bestimmt, ob der Connector neu entsteht oder Feld für Feld angepasst wird.
Quer über alle drei Wege steht ein Grundsatz, den SAP als Clean Core bezeichnet: Der ERP-Kern bleibt möglichst standardnah, Erweiterungen liegen in klar getrennten Extensions. Das ist mehr als eine SAP-Empfehlung, es schützt Ihre Schnittstelle direkt, weil künftige Updates den Kern nicht mehr mit Custom-Code kollidieren lassen. Warum die Clean-Core-Idee die Shop-Anbindung dauerhaft stabiler macht und wie die SAP Integration Suite dabei hilft, vertieft der Beitrag zur Clean-Core-Shop-Anbindung mit der SAP Integration Suite.
Der Migrationspfad für Ihre Schnittstellen
- Bestandsaufnahme: Alle SAP-Shop-Datenflüsse erfassen, mit Technik, Richtung und Häufigkeit, und die kritischen von den selten genutzten trennen.
- Zielarchitektur festlegen: Entscheiden, ob die Anbindung über eine zentrale Middleware entkoppelt wird, statt erneut direkt aus dem Shop in SAP zu schreiben.
- Standard-APIs zuordnen: Für jeden Datenfluss den passenden freigegebenen S/4HANA-Service suchen und nur dort eigene Endpunkte planen, wo kein Standard existiert.
- Mapping neu justieren: Feldzuordnungen für Kunden, Artikel, Preise und Belege gegen das S/4HANA-Modell prüfen und die Echtzeit-Synchronisation zwischen SAP und Shop neu aufsetzen.
- Parallel testen und umschalten: In einer Sandbox gegen S/4HANA testen, alten und neuen Connector eine Zeit lang parallel fahren und erst nach stabilem Abgleich final auf den neuen Weg umschalten.
Über die reine Technik hinaus entscheidet die Datenhoheit über den Projekterfolg. Für jede Datenart, ob Artikel, Preis, Kunde oder Beleg, muss eindeutig festgelegt sein, welches System führt und welches nur liest. Diese Festlegung gehört vor die erste Zeile Code, weil sie bestimmt, in welche Richtung ein Feld nach der Migration synchronisiert wird. Wird sie übersprungen, tauchen genau jene Konflikte auf, die sich spät im Livebetrieb und dann nur mit hohem Aufwand beheben lassen. Ein kurzer Workshop mit Fachbereich und IT reicht in der Regel aus, um diese Richtungsentscheidungen verbindlich festzuhalten, bevor der erste Adapter gebaut wird.
Zeitplan 2026 und 2027: warum Warten teuer wird
Rechnet man rückwärts, wird die Frist eng. Wenn rund 37 Prozent der Betriebe ihren Umstieg erst für 2027 planen (DSAG-Investitionsreport 2026), treffen viele Projekte im selben Zeitfenster auf dieselben knappen Beraterkapazitäten. Eine Schnittstellenmigration braucht Zeit für Bestandsaufnahme, Neuentwicklung, Test in einer Sandbox und einen kontrollierten Cutover. Wer erst kurz vor dem Wartungsende beginnt, riskiert, dass die Shop-Anbindung zum Flaschenhals des gesamten ERP-Projekts wird. Hinzu kommt ein zweiter Termin im selben Zeitraum: Die schrittweise E-Rechnungspflicht ab 2027 verlangt ohnehin Anpassungen an der Beleg-Schnittstelle, die sich sinnvoll mit der S/4HANA-Umstellung bündeln lassen.
Der früh geplante Umstieg zahlt sich doppelt aus. Zum einen bleibt Spielraum, die Migration als Chance zu nutzen und veraltete Prozesse gleich mit zu bereinigen. Zum anderen entkoppeln Sie den Shop-Betrieb vom Termindruck des ERP-Projekts. Ein Kundenkonto, das Auftragsstatus und Belege in Echtzeit aus dem ERP zieht, funktioniert nur, wenn die darunterliegende Schnittstelle rechtzeitig steht. Wie ein solcher live gespeister Auftragsstatus im B2B-Kundenkonto aufgebaut wird, hängt direkt an einer stabilen S/4HANA-Anbindung.
Die Schnittstelle ist kein Nachgedanke
Häufige Fehler bei der Connector-Migration
- Nebenschnittstellen übersehen: Gutschriften, Teillieferungen oder Stammdaten-Sonderfälle laufen oft über eigene, vergessene IDocs, die im neuen Connector fehlen.
- Direkt statt entkoppelt migrieren: Wer die alte Punkt-zu-Punkt-Verbindung eins zu eins nachbaut, verschenkt den größten Vorteil des Umstiegs und handelt sich denselben Wartungsaufwand erneut ein.
- Zu spät testen: Ohne frühe Sandbox-Tests gegen S/4HANA fallen abweichende Feldinhalte und Datenkonflikte erst im Livebetrieb auf, wie der Beitrag zur Auflösung bidirektionaler Datenkonflikte zeigt.
- Custom-Code in den Kern zurücktragen: Erweiterungen, die entgegen dem Clean-Core-Prinzip wieder im ERP-Kern landen, machen das nächste Update erneut riskant.
- Cutover ohne Rückfallplan: Ein harter Umschalttermin ohne Parallelbetrieb lässt bei einem Fehler keinen sicheren Weg zurück.
Das Wartungsende zwingt nicht nur das ERP zum Umzug, sondern jede Leitung, die daran hängt. Wer die Shop-Schnittstelle früh mitdenkt, migriert einmal sauber statt zweimal unter Druck.