Ihre SAP-Hybris-Plattform wird im Juli 2026 eingestellt. Was das wirklich bedeutet, und was Sie jetzt tun sollten.

Wenn Sie SAP Commerce on-premise betreiben (die Plattform, die die meisten noch Hybris nennen), steht Ihnen eine verbindliche Frist bevor. Der Mainstream-Wartungsvertrag endet am 31. Juli 2026. Ab diesem Datum stellt SAP keine Sicherheitspatches, Compliance-Updates und Plattform-Korrekturen mehr bereit. Das ist bestätigt. Es ist kein Gerücht.

Die meisten betroffenen Unternehmen kennen das Datum bereits. Nur wenige haben durchdacht, was es für ihren Tagesbetrieb wirklich bedeutet, und noch weniger haben ihre tatsächlichen Optionen klar herausgearbeitet.

Dieser Beitrag tut genau das.

Was "Ende des Mainstream-Wartungsvertrags" wirklich bedeutet

SAP wird nach dem Stichtag kundenspezifische Wartungsverträge anbieten. Viele Unternehmen betrachten dies als Sicherheitsnetz. Das ist es nicht.

Kundenspezifische Wartung gibt Ihnen Zugang zu Korrekturen, die vor dem Stichtag veröffentlicht wurden. Nichts Neues. Keine neu entdeckten Schwachstellen werden behoben. Keine Updates, wenn sich Compliance-Rahmenwerke weiterentwickeln: DSGVO-Durchsetzung, NIS2, branchenspezifische Anforderungen. Kein neuer API-Support. Keine technologische Weiterentwicklung.

Sie zahlen Wartungsgebühren für eine Plattform, die aufgehört hat, sich weiterzuentwickeln. Ihr Unternehmen entwickelt sich jedoch weiter. Je länger Sie bleiben, desto grösser wird diese Lücke.

Die eigentliche Gefahr der erweiterten Wartung ist nicht technischer Natur. Sie ist organisatorischer Natur. Sobald die Verlängerung unterzeichnet ist, lässt die interne Dringlichkeit nach. Das Re-Plattforming-Projekt rutscht auf der Prioritätenliste nach unten. Schlüsselpersonen verlassen das Unternehmen. Das Budget wird anderweitig eingesetzt. Dann ist es 2028. Ihre Plattform ist vollständig ununterstützt, der Talentpool für SAP-Commerce-Spezialisten ist noch kleiner, ihre Tagessätze sind höher, und die Wettbewerber, die vor zwei Jahren eine Entscheidung getroffen haben, sind vorausgeeilt.

Erweiterte Wartung kann der richtige taktische Schritt sein, um Zeit für eine gut geplante Migration zu gewinnen, aber nur wenn Sie es genau als das behandeln: als Übergang mit einem verbindlichen Enddatum, nicht als Ziel.

Die drei Wege nach vorne

Jedes Unternehmen mit SAP Commerce on-premise steht vor denselben drei Optionen. Sie sind nicht gleichwertig.

Sie sind sich nicht sicher, welcher Weg zu Ihrer Situation passt? Sehen Sie den vollständigen Migrationsvergleich und was jeder Weg in der Praxis bedeutet →

Option 1: Migration zu SAP Commerce Cloud (CCV2)

Dies ist der von SAP empfohlene Weg, und es ist das, was die meisten etablierten Systemintegratoren vorschlagen werden, weil sie es kennen und es in vielen Fällen der einzige Weg ist, den sie anbieten können.

Was CCV2 Ihnen bietet: verwaltete Infrastruktur, SAP-seitige Patch-Verwaltung, ein Technologie-Stack, den Ihr bestehendes SAP-Team kennt.

Was es Ihnen nicht bietet: keinen wesentlichen architektonischen Fortschritt. CCV2 ist dieselbe monolithische Architektur, die Sie heute betreiben, nur gehostet von SAP. Die Starrheit, die Ihre Agilität on-premise einschränkt, folgt Ihnen in die Cloud. Das Ändern einer Preisregel, das Hinzufügen eines Workflows oder das Starten eines neuen Kanals: all das erfordert weiterhin die Beteiligung von Entwicklern, Sprint-Zyklen und Deployment-Fenster.

Obligatorische Update-Zyklen alle sechs Monate. Für stark angepasste B2B-Implementierungen verbraucht jeder Zyklus wochenlange Spezialistenzeit und birgt Regressionsrisiken.

Eine typische CCV2-Migration für eine komplexe B2B-Umgebung dauert 12 bis 18 Monate. Wenn Sie noch nicht begonnen haben, liegen Sie bereits hinter dem Stichtag. Am Ende haben Sie all die Einschränkungen geerbt, die Sie zu dieser Entscheidung geführt haben, und werden sich in fünf bis sieben Jahren erneut mit derselben Frage konfrontiert sehen.

Option 2: Wartung verlängern und richtig planen

Wie oben beschrieben: ein legitimer taktischer Übergang, keine Strategie. Der Wert liegt in der Zeit, die er Ihnen gibt, um eine fundierte Entscheidung zu treffen. Das Risiko liegt darin, ihn als die Entscheidung selbst zu behandeln.

Option 3: Direkt zu Composable, autonomem Commerce wechseln

Statt von einem Monolithen zu einem anderen zu migrieren, ersetzen Sie den Ansatz vollständig. Wechseln Sie von einer Plattform, die Sie aufbauen und warten, zu einer Architektur, die Sie betreiben: eine, die Ihre Commerce-Workflows durchgängig orchestriert, sich durch eingebettete Intelligenz anpasst und sich kontinuierlich ohne erzwungene Update-Zyklen weiterentwickelt.

Dies war der Weg, den HABA FAMILYGROUP gewählt hat, als sie vor derselben Entscheidung standen. Sie betrieben SAP Commerce, ihr Backend war zu komplex und unflexibel geworden, und die End-of-Life-Frist nahte. Statt einer risikobeladenen Big-Bang-Migration zu CCV2 entschieden sie sich für den direkten Sprung.

Erster Kanal in vier Monaten live. 43% Gesamteinsparungen im zweiten Jahr. 74% Einsparungen bei Lizenzen und Hosting. Null Geschäftsunterbrechungen während der Migration: Sie ersetzten Backend-Komponenten schrittweise und behielten gleichzeitig ihren bestehenden Storefront in Betrieb. Obligatorische Update-Zyklen vollständig eliminiert.

Warum das speziell für B2B relevant ist

Der B2B-Business-Case für Composable Architecture ist stärker als für B2C, nicht schwächer. Die Komplexität, die B2B schwierig macht (kundenspezifische Preisgestaltung, mehrstufige Genehmigungsworkflows, Kontohierarchien, EDI-Integration, komplexe Vertragspreise und Multi-Channel-Fulfillment) ist genau das, was eine composable, orchestrierungsorientierte Plattform nativ bewältigt.

Plattformen wie commercetools und Shopify sind von einem B2C-Ausgangspunkt her aufgebaut und für B2B nachgerüstet. Die ursprüngliche Hybris-Plattform wurde von Grund auf für B2B konzipiert. Dasselbe Gründerteam hat Emporix entwickelt, und diese Designphilosophie setzt sich fort: B2B-Komplexität ist der Standard, nicht die Ausnahme.

Auch der KI-Aspekt ist hier relevant. Innerhalb von zwei bis drei Jahren wird ein erheblicher Anteil der B2B-Kaufinteraktionen KI-Agenten umfassen. KI nachträglich auf eine bestehende monolithische Plattform aufzusetzen produziert unzusammenhängende Funktionen, die Fragmente automatisieren. Eine Architektur, die KI-Agenten in Commerce-Workflows einbettet, wo sie Zugang zum vollständigen Geschäftskontext, der Kundenhistorie, der Bestandslage, den Margenzielen und den Fulfillment-Einschränkungen haben, erzielt echte Ergebnisse. Der Unterschied ist architektonischer Natur, nicht kosmetischer.

Unsere Perspektive bei Mimacom

Wir arbeiten seit Jahren mit komplexen B2B-Commerce-Umgebungen. Wir haben gesehen, wie Migrationen scheitern, wir haben das Muster beobachtet, bei dem erweiterte Wartung in dauerhafte Inaktivität abdriftet, und wir haben gesehen, wie gut umgesetzte Composable Architecture aussieht.

Unsere Einschätzung: Die richtige Antwort für die meisten unentschlossenen Unternehmen ist es jetzt, die Wartung als Übergang zu verlängern und gleichzeitig eine Composable-Migration zu planen, nicht CCV2. Der direkte Sprung ist schneller als eine CCV2-Migration (vier bis sechs Monate bis zum ersten Kanal gegenüber 12 bis 18), strukturell besser und eliminiert den Re-Plattforming-Zyklus dauerhaft, anstatt ihn zu verschieben.

Die Rechnung ist einfach. Eine CCV2-Migration dauert 12 bis 18 Monate und stellt Sie in fünf bis sieben Jahren vor dieselbe Entscheidung: zwei grosse disruptive Projekte in weniger als einem Jahrzehnt. Eine gut umgesetzte Composable-Migration löst das strukturelle Problem dauerhaft und beginnt im ersten Jahr, Kosteneinsparungen zu liefern.

Wir übernehmen Verantwortung für das Ergebnis, nicht für die geleisteten Stunden. Das ist das Fundament unseres Delivery-Modells. Mehr über unseren Ansatz erfahren Sie hier.

Was jetzt zu tun ist, wenn Sie SAP Commerce on-premise betreiben

Drei Diagnosen diese Woche:

1. Berechnen Sie Ihre tatsächliche Wartungslast. Lizenzen, Beratergebühren, Update-Testzyklen und die Opportunitätskosten für Funktionen, die Ihr Team nicht liefern konnte, weil es die Plattform verwaltete, anstatt das Geschäft weiterzuentwickeln.
2. Zählen Sie Ihre SAP-Commerce-Spezialisten. Intern und extern. Was sind ihre aktuellen Tagessätze? Was passiert, wenn einer das Unternehmen verlässt? Wenn die Antwort Sie beunruhigt, ist das eine wichtige Information.
3. Messen Sie Ihre Time-to-Change. Wählen Sie drei aktuelle Geschäftsanforderungen: eine Preisanpassung, ein neues Kundensegment, eine Workflow-Änderung. Wie viele Tage vergehen von der Anfrage bis zur Produktion? Diese Zahl sagt mehr über die tatsächliche Eignung Ihrer Plattform aus als jeder Funktionsvergleich.

Wenn diese drei Übungen in dieselbe Richtung zeigen, die sie meist tun, ist der nächste Schritt eine fundierte Analyse: Mapping Ihrer Umgebung, TCO-Modellierung über alle drei Wege und Erstellung eines realistischen Migrations-Zeitplans für Ihre spezifische Architektur.