Die Mainstream Maintenance für SAP Commerce On-Premise endet im Juli 2026. Drei Migrationspfade, fünf entscheidende Fragen und konkrete Praxisbeispiele - ein Leitfaden für B2B-Entscheider, die mehr wollen als einen Plattformtausch.
Die Deadline ist real—SAP beendet die Mainstream Maintenance für SAP Commerce On-Premise (ehemals Hybris) am 31. Juli 2026 - aber die Entscheidung, die vor Ihnen liegt, ist differenzierter als „neuen Anbieter wählen und los“.
Weltweit betreiben mehr als 3.000 Unternehmen SAP Hybris Commerce. Deutschland ist nach den USA der zweitgrößte Markt mit rund 267 Organisationen. Die meisten davon sind mittelständische und große Unternehmen mit komplexen B2B-Anforderungen in der Fertigung, im Großhandel und in der Industriegüterbranche. Für diese Unternehmen ist eine Migration kein IT-Projekt. Es ist eine grundlegende Geschäftsentscheidung darüber, wie der digitale Handel in den nächsten zehn Jahren funktionieren soll.
Dieser Leitfaden bringt Klarheit. Wir erklären, was sich tatsächlich ändert, warum der Migrationspfad wichtiger ist als die Plattformwahl, und wie Sie Ihre Optionen bewerten, ohne in die typischen Fallen zu tappen, an denen Enterprise-Replatforming-Projekte scheitern.
Was passiert tatsächlich mit SAP Commerce
SAP hat bestätigt: Version 2205 - das letzte On-Premise-Release von SAP Commerce - erreicht am 31. Juli 2026 das End of Mainstream Maintenance (EoMM). Danach liefert SAP keine Sicherheitspatches, Updates oder Standard-Support mehr. Es bleibt lediglich die sogenannte Customer-Specific Maintenance—ohne garantierte Reaktionszeiten und ohne Sicherheitsfixes.
Das ist Teil eines größeren Musters. SAP stellt sein gesamtes Portfolio systematisch auf Cloud-first-Delivery um und beendet den On-Premise-Support für mehrere Produkte im gleichen Zeitraum, darunter SAP BusinessObjects BI und SAP BPC.
Für Unternehmen, die aktuell SAP Commerce On-Premise betreiben, sind die praktischen Konsequenzen eindeutig: Ungepatchte Sicherheitslücken werden sich anhäufen. Die Kompatibilität mit modernen Payment-Gateways, Browsern und Integrationen wird sich verschlechtern. Die internen Wartungskosten werden steigen, während der Talentpool für Legacy-SAP-Commerce schrumpft - ein Trend, der im DACH-Markt bereits spürbar ist, wo erfahrene Hybris-Entwickler zunehmend schwer zu finden sind.
Die Frage ist nicht, ob Sie handeln müssen, sondern wie.
Jede Diskussion über eine SAP Commerce Migration beginnt mit der Plattformauswahl. Das ist der falsche Ausgangspunkt. Die richtige Frage lautet: Welche Art von Migration braucht Ihr Unternehmen? Es gibt drei grundlegend verschiedene Pfade, und jeder hat unterschiedliche Auswirkungen auf Kosten, Zeitplan und langfristige Fähigkeiten.
Der von SAP selbst empfohlene Weg ist die Migration zur SAP Commerce Cloud—der gehosteten, Cloud-nativen Weiterentwicklung derselben Plattform. Das ist die Option mit der geringsten Reibung, wenn Ihre Organisation tief im SAP-Ökosystem verankert ist und Kontinuität über alles geht.
Der Trade-off: Sie wechseln das Deployment-Modell, nicht die Architektur. Viele der strukturellen Einschränkungen, die On-Premise zu Customization-Komplexität geführt haben—starre Datenmodelle, monolithische Prozessabläufe, Custom-Code-Abhängigkeiten—werden mitgenommen. Sie gewinnen operative Stabilität und weiterhin Herstellersupport. Sie verändern aber nicht grundlegend, wie Ihr Commerce-System funktioniert.
Für Organisationen, deren primäres Ziel Risikominimierung und Deadline-Compliance ist, ergibt dieser Pfad Sinn. Für diejenigen, die eine operative Transformation anstreben, verschiebt er möglicherweise nur das schwierigere Gespräch.
Der zweite Pfad beinhaltet den vollständigen Ersatz von SAP Commerce durch eine Composable-Commerce-Architektur - einen Stack aus spezialisierten Komponenten (Commerce Engine, PIM, OMS, Suche, CMS), die über APIs verbunden werden.
Dieser Ansatz verspricht Flexibilität und moderne Architektur. Er bringt aber auch die Herausforderung mit sich, mit der viele Composable-Adopter inzwischen konfrontiert sind: Flexibilität ohne Orchestrierung führt zu Fragmentierung. Wenn Sie sechs oder sieben unabhängige Services betreiben, brauchen die Prozesse, die diese Services überspannen—Order-to-Cash, Quote-to-Delivery, Retouren—nach wie vor eine Instanz, die sie koordiniert. APIs verbinden Systeme, aber sie orchestrieren keine Ergebnisse.
Organisationen, die diesen Pfad wählen, ohne die Orchestrierungsschicht zu adressieren, erleben häufig das, was wir als „Composable Regret“ bezeichnen - einen modernen, teuren Stack, der an jedem Übergabepunkt immer noch manuelle Eingriffe erfordert.
Der dritte Pfad betrachtet die Migration als Gelegenheit, die Funktionsweise des Commerce-Betriebs grundlegend zu verändern. Statt eine Plattform durch eine andere (oder durch mehrere) zu ersetzen, implementieren Sie ein System, das darauf ausgelegt ist, End-to-End-Prozesse zu orchestrieren—bestehende Infrastruktur zu verbinden, Workflows über Tools hinweg zu automatisieren und Business-Teams zu befähigen, Prozesse ohne Engineering-Abhängigkeit anzupassen.
Dies ist der Ansatz hinter Autonomous Commerce Execution: Plattformen, die Commerce-Fähigkeiten mit Prozessorchestrierung und intelligenter Automatisierung kombinieren. Statt Integrationen zwischen Tools zu bauen, modellieren Sie Value Streams—End-to-End-Abläufe, die Systeme, Daten und Entscheidungen in kohärente Geschäftsprozesse verbinden.
Das Ergebnis unterscheidet sich fundamental sowohl von einem Lift-and-Shift als auch von einem Composable-Rebuild. Statt eine Sammlung von Tools zu betreiben, betreiben Sie ein Commerce-System, das über diese Tools hinweg denkt und handelt.
Unabhängig davon, zu welchem Pfad Sie tendieren—diese fünf Fragen entscheiden darüber, ob Ihre Migration gelingt oder zum nächsten mehrjährigen IT-Projekt wird, das keinen Business Value liefert.
Abstrakte Frameworks sind hilfreich. Konkrete Beispiele sind besser.
HABA FAMILYGROUP, ein deutscher Hersteller mit B2C-, B2B- und B2B2C-Kanälen, hat seine bestehende SAP Commerce (Hybris)-Lösung durch einen modernen SaaS-Tech-Stack ersetzt. Ziel war es, die Betriebskosten zu senken und drei separate Vertriebskanäle auf einer einzigen Plattform zu konsolidieren. Der erste Kanal ging innerhalb von vier Monaten live. Das Ergebnis: eine Composable-Architektur mit deutlich niedrigeren Gesamtbetriebskosten und verbesserten Kundenerlebnissen über alle Kanäle hinweg.
DORMA-Glas, ein weiterer deutscher B2B-Hersteller, verfolgt einen ähnlichen Weg—die Ablösung der SAP Commerce Legacy-Lösung durch eine Composable-Architektur auf SaaS-Basis. Der Ansatz umfasst einen Headless Storefront, konfigurierbare Produkte und eine phasenweise Roadmap zur Anbindung von Fachhändlern.
Beide Fälle teilen ein gemeinsames Muster: Bei der Migration ging es nicht um den Plattformtausch. Es ging um den Übergang von einem Build-and-Maintain-Modell zu einem Operate-and-Adapt-Modell—die Custom-Code-Last reduzieren und gleichzeitig die Fähigkeit gewinnen, sich weiterzuentwickeln, ohne erneut replatformen zu müssen.
Die SAP Commerce Migration ist keine Technologieentscheidung. Es ist eine operative Entscheidung, die zufällig Technologie involviert. Organisationen, die sie als Replatforming-Projekt angehen, bekommen ein neues System. Diejenigen, die sie als Gelegenheit nutzen, den Commerce-Betrieb grundlegend zu überdenken, gewinnen einen Wettbewerbsvorteil.
Die Juli-2026-Deadline erzeugt Dringlichkeit, aber Dringlichkeit sollte keine schlechten Entscheidungen treiben. Beginnen Sie mit den fünf Fragen oben. Erfassen Sie Ihre Customizations, verstehen Sie Ihre Prozessabhängigkeiten, und seien Sie ehrlich darüber, welches Problem Sie tatsächlich lösen wollen.
Wenn Sie Ihre Optionen evaluieren und einen strukturierten Rahmen für die Entscheidung suchen, haben wir einen umfassenden Migration Decision Guide erstellt. Er führt durch Bewertungskriterien, Total-Cost-of-Ownership-Analysen und Migrationsplanungszeitpläne, die speziell auf B2B-Unternehmen zugeschnitten sind, die SAP Commerce verlässen.