SAP Hybris End of Life: Die vollständige Migrations-Checkliste für 2026

Am 31. Juli 2026 endete die Mainstream-Wartung für SAP Commerce On-Premise (SAP Help Portal). Release 2205 war das letzte On-Premise-Release. Wer es heute noch betreibt, hängt an kundenspezifischer Wartung, ohne reguläre Sicherheitspatches und gesetzliche Updates.

Wir haben diese Checkliste im April veröffentlicht, als noch vier Monate blieben. Die Frist ist vorbei, die Checkliste nicht: Sie beschreibt nach wie vor die Reihenfolge, in der wir Hybris-Installationen zu SAP Commerce Cloud bringen. Ich habe sie für die Lage nach Juli überarbeitet und zusammengeführt, was wir früher in drei einzelnen Beiträgen behandelt haben: was von Hybris mitkommt, den Phasenplan und die Arbeit nach dem Go-live.

Kurzfassung: SAP Commerce On-Premise (früher SAP Hybris) hat die Mainstream-Wartung am 31. Juli 2026 verlassen; seither gibt es nur noch kundenspezifische Wartung. Das Ziel für die meisten Kunden ist SAP Commerce Cloud: derselbe Kern wie Hybris, aber von SAP betrieben und laufend aktualisiert. Diese Checkliste umfasst 26 Schritte in vier Phasen, typische Zeitpläne (je nach Umfang 3 bis 18 Monate), Richtwerte für die Kosten, den Schutz Ihrer SEO und die ersten Wochen nach dem Go-live. Wenn Sie noch On-Premise sind, beginnen Sie mit dem Assessment: Es sagt Ihnen, wie lange Sie exponiert bleiben.

Was war SAP Hybris?

SAP Hybris war die E-Commerce-Plattform, die SAP 2013 übernommen hat. SAP hat sie später umbenannt: SAP Commerce für das On-Premise-Produkt, SAP Commerce Cloud für die von SAP betriebene Variante; seit Release 2211 wird sie nur noch als SAP Commerce Cloud ausgeliefert. Wer heute «Hybris» sagt, meint fast immer eine On-Premise-Installation von SAP Commerce, und genau deren Mainstream-Wartung endete am 31. Juli 2026.

Was sich am 31. Juli 2026 geändert hat

«End of Life» ist der Begriff, nach dem gesucht wird. Korrekt heisst es End of Mainstream Maintenance (EoMM), und das hat konkrete Folgen.

Was weggefallen ist:

• Reguläre Sicherheitspatches. Ihre Commerce-Plattform, die Kunden- und Zahlungsdaten verarbeitet, erhält keine routinemässigen Sicherheitsupdates mehr.
• Gesetzliche und steuerliche Updates. Mehrwertsteueränderungen und andere regulatorische Anpassungen werden nicht mehr als Standardwartung ausgeliefert.
• Updates von Drittbibliotheken. Bekommt eine mitgelieferte Abhängigkeit eine CVE, kommt der Fix nicht mehr selbstverständlich in Ihr On-Premise-Release.
• Zertifizierung der Java-Laufzeit. Neue JDK-Versionen werden für 2205 nicht zertifiziert; die Laufzeit altert mit der Plattform.
• Produktentwicklung. Keine neuen Funktionen, keine Performance-Arbeit, keine neuen APIs. Das On-Premise-Produkt ist eingefroren.

Was weiterläuft, gegen Aufpreis:

• Kundenspezifische Wartung. SAP bietet Support über individuelle Vereinbarungen an. Konditionen und Preise hängen von Ihrem Vertrag ab; lassen Sie sich diese vom SAP-Account-Team schriftlich geben.
• Bestehende SAP-Hinweise. Die Wissensdatenbank bleibt zugänglich, Fixes für neue Probleme gibt es aber unter Umständen nicht.

Was das nach Juli praktisch bedeutet und welche Übergangsmassnahmen sinnvoll sind, steht in SAP Commerce On-Premise: Der Support ist zu Ende, was jetzt?. In diesem Beitrag geht es um den Weg hinaus.

Hybris, SAP Commerce, Commerce Cloud: was geblieben ist und was sich geändert hat

Zuerst zu den Namen. SAP hat Hybris 2013 übernommen und später umbenannt: SAP Commerce für das On-Premise-Produkt, SAP Commerce Cloud für die von SAP betriebene Variante. «Hybris End of Life» meint also die On-Premise-Version. Seit Release 2211 wird SAP Commerce nur noch als SAP Commerce Cloud ausgeliefert, und das ist das Migrationsziel.

Das häufigste Missverständnis, das wir hören: «Commerce Cloud ist ein völlig neues Produkt.» Ist es nicht. Der Motor ist derselbe; geändert hat sich, wie er betrieben wird.

Was geblieben ist:

• Das Typsystem (Item-Typen werden weiterhin in XML definiert)
• Der Extension-Mechanismus und Spring als Container für Services
• Das Java-Backend und die Commerce-Module: Katalog, Warenkorb, Checkout, Preisfindung, Auftragsverwaltung

Was sich geändert hat:

• Betrieb. SAP stellt die Infrastruktur bereit, skaliert, patcht und überwacht sie. Teams, die früher die Hälfte ihrer Zeit mit Servern verbracht haben, können am Shop arbeiten.
• Updates. Statt grosser Upgrades alle paar Jahre liefert SAP laufend Updates. Neue Funktionen kommen ausgeschaltet, und Sie aktivieren sie, wenn Ihr Team bereit ist. Die Kehrseite: Updates lassen sich nicht mehr über Jahre aufschieben. Was das konkret heisst, zeigt das Framework-Update 2211-jdk21 mit Java 21 und Spring 6.
• Deployment. Builds und Deployments laufen über das Cloud Portal statt über eigene Skripte.
• Storefront. Das empfohlene Frontend ist der headless SAP Composable Storefront (früher Spartacus), der über die OCC-REST-APIs mit dem Backend spricht. Die JSP-basierten Accelerator-Templates hat SAP mit Release 2205 als veraltet erklärt und entfernt sie laut veröffentlichtem Plan im September 2027 aus Commerce Cloud (SAP KBA 3263872).

Für Ihr Team heisst das: Java- und Typsystem-Wissen bleibt nutzbar. Lernen muss es das Cloud-Deployment-Modell, das Cloud Portal und, falls Sie noch Accelerator betreiben, ein Angular-Frontend. Das ist Schulung, keine Umschulung.

Der Entscheidungsrahmen für die Migration

Vor der Checkliste braucht eine Frage eine Antwort: Bei SAP bleiben oder wechseln?

Wir sind SAP-Partner und haben damit ein kommerzielles Interesse daran, dass Sie bleiben. Deshalb hier, wann welcher Weg sinnvoll ist.

Bleiben Sie bei SAP Commerce Cloud, wenn:

• Sie SAP ERP (S/4HANA oder ECC) betreiben und auf eine tiefe ERP-Integration angewiesen sind: Preise, Verfügbarkeit, Aufträge, kundenspezifische Konditionen. Läuft dieses ERP noch auf ECC, gehört dessen eigenes Wartungsende von SAP ECC 2027 in denselben Plan.
• Ihr B2B-Modell SAP-spezifische Funktionen nutzt: komplexe Preisfindung, Kontrakte, kundenspezifische Kataloge, Freigabe-Workflows.
• Ihr Team SAP-Commerce-Know-how hat. Eine Umstellung auf eine völlig andere Plattform kostet Monate.
• Sie schnell vorankommen müssen. Commerce Cloud bewahrt Datenmodell, Geschäftslogik und viele Anpassungen; ein komplettes Replatforming nicht.

Erwägen Sie einen Wechsel, wenn:

• Sie kein SAP ERP haben oder die Integration ein einfacher Auftragsexport ist.
• Ihr Storefront reines B2C mit Standardkatalog, Warenkorb und Checkout ist.
• Ihr Team kein SAP-Know-how hat und keines aufbauen will.
• Sie ohnehin eine vollständig composable Architektur anstreben. Das dauert deutlich länger als eine Commerce-Cloud-Migration; unsere Analyse zu Composable Commerce im B2B zeigt, wann es sich lohnt.

Für die meisten On-Premise-Kunden ist SAP Commerce Cloud die pragmatische Antwort: geringstes Risiko, schnellste Umsetzung, bestehende Investitionen bleiben erhalten. Pragmatisch heisst aber nicht automatisch. Treffen Sie die Entscheidung aktiv. Einen Überblick über die Plattform heute finden Sie auf unserer Seite zu SAP Commerce Cloud.

Die vollständige Migrations-Checkliste

Sechsundzwanzig Punkte in vier Phasen. Mit dieser Checkliste arbeiten wir bei unseren Kunden.

Phase 1: Assessment (Wochen 1 bis 4)

Diese Phase wird am häufigsten überhastet. Alles Weitere hängt an ihr.

1. Alle Anpassungen inventarisieren. Exportieren Sie eine vollständige Liste der eigenen Extensions, ImpEx-Skripte, HAC-Anpassungen und geänderten Plattform-APIs. Ordnen Sie jeden Punkt ein: weiterhin nötig, durch Standardfunktionen von Commerce Cloud ersetzbar oder obsolet. In unseren Audits fällt meist ein beträchtlicher Teil in die letzten beiden Kategorien; warum das zählt, zeigen die 5 Fehler bei der Migration.

2. Kernmodifikationen finden. Code, der ausgelieferte SAP-Klassen ändert statt Extensions zu nutzen, oder der das Typsystem umgeht und direkt auf die Datenbank zugreift, muss vor der Migration umgebaut werden. Genau diese Punkte sprengen Zeitpläne; finden Sie sie zuerst.

3. Alle Integrationen kartieren. ERP, PIM, CRM, Zahlung, Versand, Steuern, Loyalty, Marketing-Automation. Für jede: Protokoll (API, IDoc, Dateitransfer, direkte Datenbankverbindung), Datenvolumen, Frequenz, Verantwortliche. Dateiablagen und direkte Datenbankverbindungen funktionieren in Commerce Cloud nicht, und dieser Punkt führt am häufigsten zu «Wie konnten wir das übersehen?».

4. Drittanbieter-Extensions prüfen. Klären Sie für jedes Add-on und jede Drittanbieter-Extension die Commerce-Cloud-Kompatibilität mit dem Hersteller und testen Sie sie in einer Cloud-Sandbox. Manche gibt es cloudfähig, andere brauchen Ersatz.

5. Storefronts erfassen. Anzahl Sites, Sprachen, Kataloge. Länderübergreifende Setups mit eigener Preisfindung, eigenen Steuer- und Fulfillment-Regeln sind ein anderes Projekt als ein einzelner Storefront.

6. Daten profilieren. Zählen Sie Produkte (mit Varianten), Kategorien, Kunden, historische Aufträge, Inhaltsseiten und Medien. Prüfen Sie gleichzeitig die Qualität: Dubletten, verwaiste Referenzen, uneinheitliche Formate, Daten, die seit Jahren niemand angefasst hat. Bereinigen Sie im Quellsystem; unsaubere Daten gehören nicht in eine neue Umgebung.

7. Ausgangswerte festhalten. Antwortzeiten, Durchsatz, Konversionsrate, Fehlerraten. Ohne diese Zahlen kann nach dem Go-live niemand belegen, ob die neue Plattform besser oder schlechter läuft.

8. SEO-Fussabdruck bewerten. Holen Sie das vollständige URL-Inventar aus der Google Search Console. Wie viele Seiten sind indexiert, wie viel organischen Traffic bringen sie? Sites mit hohem SEO-Wert brauchen eine detaillierte Redirect-Strategie.

9. Verschlüsselung und Zugangsdaten dokumentieren. Wenn Sie Transparent Attribute Encryption mit eigenen Schlüsseln nutzen, dokumentieren Sie alle verschlüsselten Attribute und planen Sie deren Übernahme in das Schlüsselmanagement von Commerce Cloud.

10. Lizenz- und Vertragslage klären. Was sagt Ihr heutiger Vertrag zur Zeit nach EoMM, und wie sieht ein Commerce-Cloud-Abonnement für Ihr Volumen aus? Vertragsgespräche dauern Wochen; starten Sie sie parallel.

Phase 2: Architektur und Planung (Wochen 5 bis 10)

11. Storefront-Ansatz wählen. Drei Optionen:

• SAP Composable Storefront: das von SAP empfohlene Frontend. Headless, vom Backend entkoppelt, unabhängig deploybar. Die richtige Wahl für eine strategische Investition; unser Leitfaden zur Migration vom Accelerator auf den Composable Storefront beschreibt die Schritte.
• Accelerator-Storefront mitnehmen: der schnellste Weg weg von On-Premise, weil der Storefront-Code bleibt. Die Templates sind aber seit 2205 veraltet und sollen im September 2027 entfernt werden; das ist also eine Übergangslösung mit festem Ablaufdatum.
• Eigenes Headless-Frontend: React, Next.js oder Vue auf den Commerce-Cloud-APIs. Maximale Freiheit, aber das Frontend gehört vollständig Ihnen. Wir vergleichen die Optionen in Composable Storefront vs. React/Next.js.

12. Zielarchitektur entwerfen. Commerce-Cloud-Umgebungen, Integrationsarchitektur (SAP Integration Suite oder direkte APIs), CDN- und Caching-Strategie, Monitoring und Alerting.

13. Integrationsumbau planen. In Commerce Cloud läuft alles über APIs oder SAP Integration Suite. Jede Integration braucht einen eigenen Migrationsplan; rechnen Sie mit drei bis fünf Tagen pro Integration für Analyse und Neukonzeption.

14. Datenmigrationsstrategie festlegen. Big Bang (vollständiger Load in einem Cutover-Fenster) oder iterativ (schrittweise Loads mit Delta-Synchronisation). Ab einer Million Produkten empfehlen wir iterative Loads mit mindestens drei Probeläufen. Die verfügbaren Methoden beschreibt unser Beitrag zu den Ladetechniken in SAP Commerce Cloud.

15. Umgebungen, CI/CD und Wiederherstellung planen. Mindestens Entwicklung, Staging und Produktion; grössere Projekte ergänzen eine Integrationstestumgebung. Richten Sie automatisierte Build-, Test- und Deployment-Pipelines ab dem ersten Tag ein. Definieren Sie Recovery Point und Recovery Time Objectives und testen Sie die Wiederherstellung vor dem Go-live.

16. Governance aufsetzen und Scope fixieren. Ein wöchentlicher Steuerungsausschuss mit Entscheidungskompetenz, ein Entscheidungslog, Sprint-Demos alle zwei Wochen und ein Product Owner auf Kundenseite, der Scope-Entscheide trifft. Dann den Scope schriftlich festhalten und abnehmen lassen. Die grösste Ursache für Verzögerungen ist «Wenn wir schon dabei sind, machen wir noch …». Erst migrieren, dann ausbauen.

Phase 3: Umsetzung und Migration (Wochen 11 bis 30)

17. Commerce-Cloud-Umgebungen aufsetzen. Alle Umgebungen bereitstellen, Build-Pipelines prüfen und einmal durch die ganze Kette deployen, bevor Geschäftslogik geschrieben wird.

18. Storefront neu bauen oder migrieren. Beginnen Sie mit den Templates mit dem meisten Traffic: Startseite, Kategorieseiten, Produktdetailseiten, Checkout.

19. Integrationen umbauen. Testen Sie jede Integration mit echten Daten, nicht mit Mocks. In Integrationstests zeigen sich die meisten Migrationsfehler; testen Sie früh und oft.

20. Probe-Datenmigrationen durchführen. Mindestens zwei vollständige Läufe vor dem echten Cutover. Messen Sie Dauer, Genauigkeit und Fehlerquote und beheben Sie Probleme zwischen den Läufen.

21. SEO und Performance umsetzen. Redirect-Map, kanonische URLs, XML-Sitemap und robots.txt bereitstellen und die Staging-Umgebung crawlen. CDN-Caching und API-Antwortzeiten optimieren; Zielwerte für Ladezeiten und Core Web Vitals festlegen.

Phase 4: Test und Go-live (Wochen 31 bis 38)

22. Abnahmetests mit dem Fachbereich. Fachanwender, nicht Entwickler, testen Suche, Navigation, Warenkorb, Checkout, Zahlung, Retouren und B2B-Workflows, in jedem Storefront, jeder Sprache und jedem Kundensegment.

23. Lasttests im Massstab. Simulieren Sie Spitzentage. Commerce Cloud skaliert automatisch; Ihr eigener Code und Ihre Integrationen nicht unbedingt.

24. SEO-Migration validieren. URL-Inventare vergleichen, jeden Redirect prüfen, strukturierte Daten mit dem Rich-Results-Test von Google validieren.

25. Cutover proben und durchführen. Schreiben Sie ein Runbook, das jede Person im Team ausführen kann: Inhalte einfrieren, finale Delta-Migration, DNS umstellen, alle Integrationen prüfen, 48 Stunden überwachen. Proben Sie es mindestens einmal und dokumentieren Sie den Rollback, einschliesslich der Frage, wie Aufträge nach der Umstellung ins alte System zurückkommen, falls Sie zurückwechseln müssen.

26. Nach dem Go-live überwachen. Mindestens zwei Wochen engmaschig: Fehlerraten, Konversion gegenüber dem Ausgangswert, Indexierung, Integrationsfehler, Support-Tickets. Richten Sie Alarme für Abweichungen ein.

Der Go-live ist nicht die Ziellinie

Echter Produktionstraffic zeigt Engpässe, die kein Test gefunden hat. Planen Sie die Wochen nach dem Go-live von Anfang an ein:

• Ein Optimierungssprint. Vier bis sechs Wochen für Caching, langsame Abfragen, API-Antwortzeiten und Frontend-Rendering.
• Schulung. Ihr Team muss Commerce Cloud selbständig betreiben, Inhalte pflegen und Fehler eingrenzen können. Schulen Sie in Stufen: erst Betrieb, dann Konfiguration, dann Entwicklung.
• Ein Backlog für Zurückgestelltes. Was während der Migration aus dem Scope fiel, gehört in einen priorisierten Backlog, nicht ins Vergessen. Überprüfen Sie ihn regelmässig, statt alles auf einmal zu bauen.
• Ein Update-Rhythmus. Commerce Cloud erwartet, dass Sie Updates regelmässig übernehmen. Planen Sie feste Fenster dafür.

Zeitplan-Rechner

Nicht jede Migration ist gleich. Diese Faktoren bestimmen den Zeitplan:

Wie Sie diese Zahlen im September 2026 lesen: Ab jetzt zählt jeder Monat, denn jeder Monat läuft auf kundenspezifischer Wartung. Fast-Track-Projekte können vor Jahresende oder Anfang 2027 live sein. Standardprojekte landen im Lauf von 2027, und komplexe Vorhaben sollten Sie in Wellen teilen, damit die ersten Märkte die On-Premise-Plattform früh verlassen. Das schnellste Ende der Spanne beschreibt unser 90-Tage-Playbook.

Kostenschätzungen nach Szenario

Diese Frage kommt in jedem Erstgespräch, deshalb hier Richtwerte aus unseren Projekten statt eines vagen «kommt darauf an»:

Fast-Track (ein Storefront, wenige Integrationen): 300’000 bis 500’000 USD. Setzt einen fokussierten Scope, SAP-Know-how im Team und die Bereitschaft voraus, nicht zwingende Anpassungen zurückzustellen.

Mittelstand (zwei oder drei Storefronts, mittlere Komplexität): 500’000 bis 800’000 USD. Hier liegen die meisten unserer Migrationsprojekte: Assessment, Umsetzung, Datenmigration, Integrationsumbau, Performancetests und Go-live-Begleitung.

Enterprise (fünf und mehr Storefronts, komplexes B2B, mehrere Länder): 800’000 bis über 2 Millionen USD. Die Spanne ist gross, weil ein B2B-Geschäft in zwölf Ländern mit eigener Preisfindung und tiefer ERP-Integration ein anderes Projekt ist als fünf B2C-Storefronts mit Standard-Checkout.

Das sind einmalige Migrationskosten. Nicht enthalten: Commerce-Cloud-Lizenzen (jährlich, abhängig vom Volumen), Drittlizenzen (PIM, Suche, CMS), interner Aufwand und spätere Erweiterungen. Planen Sie 15 bis 20 Prozent Reserve für Datenqualität und Überraschungen bei den Integrationen ein. Die Lizenzseite schlüsselt unser Leitfaden zu den Kosten von Commerce Cloud auf.

Was Abwarten kostet: Kundenspezifische Wartung wird individuell bepreist und liegt in der Regel deutlich über dem, was Sie für die Mainstream-Wartung bezahlt haben, ohne neue Funktionen und ohne reguläre Patches. Vergleichen Sie diese Zahl mit dem Migrationsbudget, bevor Sie ein weiteres Jahr abwarten.

SEO-Migration: Rankings nicht verlieren

Wir haben technisch saubere Migrationen gesehen, die einen grossen Teil ihres organischen Traffics verloren haben, weil niemand den SEO-Übergang geplant hatte. Für viele Shops ist die organische Suche einer der wichtigsten Umsatzkanäle.

Vor der Migration:

1. Alles als Ausgangswert erfassen. Indexierte URLs, Klicks, Impressionen und durchschnittliche Positionen der wichtigsten Suchanfragen aus der Search Console, wöchentlich, denn Sie brauchen den Verlauf, keine Momentaufnahme.
2. Die aktuelle Site crawlen. Mit Screaming Frog oder Sitebulb: vollständiges URL-Inventar, interne Links, Canonicals, strukturierte Daten.
3. Jede URL zuordnen. Alte URL, neue URL, Redirect-Typ (fast immer 301).

Während der Migration:

4. Redirects früh bauen, parallel zur neuen Plattform, und auf Staging testen.
5. Metadaten bewahren. Titel, Beschreibungen, Überschriftenstruktur und strukturierte Daten müssen mitkommen.
6. XML-Sitemap bereithalten und direkt nach der DNS-Umstellung einreichen.

Nach der Migration:

7. Vier Wochen täglich überwachen: Indexierungsrate, 404-Fehler, organischer Traffic gegenüber dem Ausgangswert, Positionen der 50 wichtigsten Suchanfragen.
8. Probleme am selben Tag beheben. In den ersten Wochen bewertet Google Ihre ganze Site neu.

Was wir aus dem Franke-Launch mitgenommen haben

Bei Franke haben wir die SAP-Commerce-Cloud-Plattform in 90 Tagen live gebracht; die Angabe bezieht sich auf den Commerce-Launch. Ausgangspunkt war eine vernachlässigte Altplattform, die ein früherer Partner umgesetzt hatte. Wir haben sie durch eine Headless-Architektur für B2B und B2C ersetzt, sauber an S/4HANA und C4C angebunden, und heute verbindet sie mehr als zehn globale Kanäle. Das Projekt erhielt den SAP Quality Award für «Rapid Time to Value». Details stehen in der Franke-Erfolgsgeschichte.

Drei Lehren daraus gelten für jede Migration:

• Erst auditieren, dann migrieren. Jede Anpassung, die sich als obsolet erweist, ist Code, den Sie nicht migrieren, testen und warten müssen.
• Arbeitsstränge parallel führen. Plattform, Daten, Integrationen und Frontend parallel mit täglicher Abstimmung, nicht nacheinander.
• Iterativ liefern. Früh in die Cloud deployen, auch unvollständig, und den Stakeholdern jede Woche Fortschritt zeigen.

Das Risiko, On-Premise zu bleiben

Seit August ist Nichtstun kein Plan mehr, sondern ein Zustand. Was er bedeutet:

Sicherheit. Die Plattform verarbeitet Personen- und Zahlungsdaten ohne reguläre Sicherheitspatches. Das verträgt sich schlecht mit den Anforderungen von PCI-DSS, DSGVO und dem Schweizer nDSG, und in einem Audit ist «Wir haben nicht rechtzeitig migriert» kein Argument.

Compliance. Steuerregeln und Datenschutzanforderungen ändern sich weiter. Ohne SAP-Updates müssen Sie sie selbst umsetzen, in Kernmodulen, die nur wenige Teams sicher ändern können.

Kosten. Kundenspezifische Wartung kostet mehr als Mainstream-Wartung, und Migrationen werden nicht billiger: Entwickler mit On-Premise-Erfahrung werden seltener.

Fachkräfte. Entwickler wollen an aktuellen Plattformen arbeiten. Ein eingefrorenes System erschwert Rekrutierung und Bindung.

Versicherung und Audit. Cyberversicherer und Prüfer (SOC 2, ISO 27001, PCI-DSS) fragen nach dem Wartungsstatus. Eine nicht mehr gewartete Commerce-Plattform landet meist als Feststellung im Bericht.

Nächste Schritte

1. Assessment buchen. Unser strukturiertes Migrations-Assessment dauert zwei bis drei Wochen und liefert Anpassungsinventar, Integrationskarte, Komplexitätsbewertung, Zeitplan und Budgetrahmen. Hier anfragen.
2. Weiterlesen. Der On-Premise-Support ist zu Ende, was jetzt? behandelt die Übergangsmassnahmen; das 90-Tage-Playbook zeigt, wie schnelle Umsetzung aussieht.
3. Den Partner bewusst wählen. Unsere Übersicht über die besten SAP-Commerce-Cloud-Partner in der Schweiz nennt die Kriterien, die ein Migrationsprojekt entscheiden. Zieht auch Ihr ERP um, liefern wir den S/4HANA-Kern und den vollständigen CX-Stack aus einem Team; siehe die Übersicht für Cloud ERP und CRM.
4. Besuchen Sie unsere On-Premise-Kampagnenseite für weitere Ressourcen.

Die Frist ist vorbei. Wie lange Ihr Expositionsfenster dauert, liegt weiterhin bei Ihnen. Sprechen Sie mit uns.

Häufig gestellte Fragen

Wann endete die Mainstream-Wartung für SAP Hybris On-Premise?

Am 31. Juli 2026. Release 2205 war das letzte On-Premise-Release von SAP Commerce, dem früheren SAP Hybris. Seither bietet SAP nur noch kundenspezifische Wartung an; reguläre Patches und gesetzliche Updates kommen nicht mehr automatisch.

Wir sind nach Juli 2026 noch On-Premise. Was tun wir jetzt?

Klären Sie zuerst Ihren Vertragsstatus mit SAP, schliessen Sie dann die exponiertesten Sicherheitslücken und starten Sie das Assessment für SAP Commerce Cloud. Ein Assessment von zwei bis drei Wochen liefert Anpassungsinventar, Integrationskarte, Zeitplan und Budgetrahmen, damit die Monate auf kundenspezifischer Wartung möglichst wenige bleiben.

Wie lange dauert eine Migration von Hybris zu SAP Commerce Cloud?

Eine Fast-Track-Migration mit einem Storefront und wenigen Integrationen dauert drei bis sechs Monate; das 90-Tage-Playbook beschreibt das schnellste Ende dieser Spanne. Standardprojekte mit zwei oder drei Storefronts brauchen sechs bis zwölf Monate, komplexe Rollouts über mehrere Länder zwölf bis achtzehn Monate.

Ist SAP Commerce Cloud dasselbe Produkt wie SAP Hybris?

Der Kern ist derselbe: Typsystem, Extension-Mechanismus, Spring und das Java-Backend stammen aus Hybris. Geändert hat sich alles darum herum: SAP betreibt die Infrastruktur, Updates kommen laufend, Deployments laufen über das Cloud Portal, und der empfohlene Storefront ist der headless SAP Composable Storefront.

Funktionieren unsere Hybris-Anpassungen in SAP Commerce Cloud?

Extensions, die dem Extension-Modell von SAP folgen (eigene Typen, Spring-Bean-Overrides, OCC-Endpunkte), lassen sich meist mit kleinen Änderungen migrieren. Direkte Datenbankzugriffe, Änderungen am ausgelieferten SAP-Code, dateibasierte Integrationen und eigene Infrastrukturskripte müssen überarbeitet werden. Der grösste einzelne Arbeitsblock ist meist der Storefront, besonders wenn Sie noch einen Accelerator-Storefront betreiben.

Was kostet eine Migration von Hybris zu Commerce Cloud?

Als Richtwerte aus unseren Projekten: 300’000 bis 500’000 USD für eine Fast-Track-Migration, 500’000 bis 800’000 USD für Mittelstandsprojekte mit zwei oder drei Storefronts und 800’000 bis über 2 Millionen USD für komplexes B2B über mehrere Länder. Commerce-Cloud-Lizenzen, Drittanbieter-Tools und interner Aufwand kommen hinzu; planen Sie 15 bis 20 Prozent Reserve ein.