SAP Commerce Migration: Was Sie vor dem Juli 2026 wirklich wissen müssen
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.
Eine unbequeme Wahrheit über die SAP Commerce Migration: Der Großteil der Ratschläge, die gerade kursieren, stammt von Anbietern, die Ihnen ihre Plattform verkaufen wollen.
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.
Die drei Migrationspfade (und was sie wirklich bedeuten)
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.
Pfad 1: Lift and Shift zur SAP Commerce Cloud
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.
Pfad 2: Replatforming auf einen Composable Stack
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.
Pfad 3: Migration auf eine Orchestration-First-Plattform
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.
Fünf Fragen, die Sie vor der Wahl Ihres SAP Hybris-Migrationspfads stellen sollten
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.
Wie viel Custom Code tragen Sie mit sich?
SAP Commerce-Implementierungen in B2B-Umgebungen umfassen oft Zehntausende Zeilen Custom Code - für Preislogik, Genehmigungsworkflows, Produktkonfiguration, EDI-Integration. Jeder Migrationspfad, der nicht explizit adressiert, wie diese Logik übertragen (oder ersetzt) wird, ist unvollständig. Erfassen Sie Ihre Customizations, bevor Sie Anbieter evaluieren.
Welche Prozesse überspannen heute mehrere Systeme?
Die wertvollste Frage in jeder Migration. Wenn Ihr Order-to-Cash-Prozess SAP ERP, Commerce, ein Dritt-OMS und eine Logistikplattform berührt, muss Ihre neue Architektur den gesamten Ablauf orchestrieren—nicht nur die Commerce-Schicht ersetzen. Migrationen, die sich nur auf den Storefront konzentrieren, übersehen die operative Komplexität darunter.
Können Ihre Business-Teams ohne IT anpassen?
Die versteckten Kosten der meisten Enterprise-Plattformen sind die Change-Request-Warteschlange. Jedes Preisregel-Update, jedes neue Kundensegment, jede Workflow-Anpassung erfordert einen Entwickler. Prüfen Sie, ob Ihr Migrationspfad Business-Teams kontrollierte Autonomie gibt, Prozesse in Echtzeit anzupassen - oder ob Sie lediglich einen IT-Engpass gegen einen anderen tauschen.
Was ist Ihr realistischer Zeitplan?
Enterprise-SAP-Commerce-Migrationen dauern typischerweise 4 bis 12 Monate, abhängig von Komplexität, Datenvolumen und Integrationstiefe. Mit der Juli-2026-Deadline haben Organisationen, die jetzt starten, noch Optionen. Wer bis Q3 2026 wartet, steht vor komprimierten Zeitplänen und deutlich höherem Risiko. Ein phasenweiser Ansatz - Legacy-Systeme mit neuen Fähigkeiten ergänzen, bevor sie vollständig abgelöst werden - kann den Zeitdruck erheblich reduzieren.
Lösen Sie das richtige Problem?
Viele Migrationen scheitern nicht an der Technologie, sondern daran, dass die Organisation eine Plattform durch eine andere ersetzt, ohne das Operating Model zu verändern. Wenn Ihre SAP-Commerce-Schmerzpunkte in Wirklichkeit Prozessfragmentierung, manuelle Übergaben und langsame Anpassungsfähigkeit sind, wird eine Like-for-Like-Migration diese Probleme auf einem neuen Stack reproduzieren. Fragen Sie sich, ob die Migration verändern soll, wie Sie operieren - nicht nur, worauf Sie operieren.
Wie eine echte SAP Commerce Migration aussieht
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 Uhr läuft: Ihre nächsten Schritte zur SAP Commerce Migration
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.
