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

31. Juli 2026. An diesem Tag stellt SAP die Auslieferung von Sicherheitspatches, Compliance-Updates und Plattform-Support für SAP Commerce On-Premise ein (SAP Help Portal, 2026). Keine sanfte Abkündigung. Kein graduelles Auslaufen. Ein harter Wartungs-Cutoff.

Wenn Sie das hier im April 2026 lesen, haben Sie noch vier Monate. Das ist knapp, aber nicht unmöglich — wir haben Franke in 90 Tagen migriert und dafür einen SAP Quality Award erhalten. Allerdings: Dieses Projekt hatte eine aggressive Vorbereitung. Falls Sie noch nicht angefangen haben, lesen Sie diese Checkliste vollständig durch.

TL;DR: Die Mainstream-Wartung für SAP Hybris (Commerce) On-Prem endet am 31. Juli 2026. Danach: keine Sicherheitspatches, keine Compliance-Updates, kein Java-Support, kein SLA-basierter Support. Über 3’200 Unternehmen betreiben SAP Commerce (6sense, 2025). Die Migration zu SAP Commerce Cloud dauert typischerweise 6-12 Monate, Fast-Track-Projekte schaffen es in 4-6 Monaten. Dieser Beitrag ist die vollständige Checkliste: 24 Punkte in 4 Phasen, Kostenschätzungen nach Szenario und eine ehrliche Bewertung, was passiert, wenn Sie nichts tun. Starten Sie jetzt Ihr Assessment.

Was genau passiert am 31. Juli 2026

Lassen Sie uns präzise sein, was sich ändert — und was nicht. «End of Life» wird oft ungenau verwendet. Der korrekte Begriff ist End of Mainstream Maintenance (EoMM), und er hat konkrete Konsequenzen.

Was sofort aufhört:

• Sicherheitspatches. Keine regulären Sicherheitsupdates mehr. Ihre Commerce-Plattform — die, die Kundenzahlungsdaten verarbeitet — läuft auf ungepatchter Software. Jeder Monat nach EoMM vergrössert Ihre Angriffsfläche.
• Rechts- und Steuer-Compliance-Updates. Mehrwertsteueränderungen, Steuerregulierungen, PCI-DSS-Compliance-Änderungen — SAP liefert dafür keine Updates mehr. Sie sind auf sich gestellt.
• Drittanbieter-Bibliotheks-Updates. Wenn eine Abhängigkeit eine CVE erhält, aktualisiert SAP sie nicht in Ihrem On-Prem-Release. Sie müssen entweder forken oder die Schwachstelle akzeptieren.
• Java-VM-Versions-Support. Neue JDK-Versionen werden nicht zertifiziert. Mit der Zeit läuft Ihr Application Server auf einer veralteten, nicht unterstützten Java-Runtime.
• Plattformverbesserungen. Keine neuen Features, keine Performance-Optimierungen, keine API-Erweiterungen. Das Produkt ist eingefroren.

Was weiterläuft — zu einem Preis:

• Kundenspezifischer Support (CSS). SAP bietet weiterhin Support, aber er wechselt von Mainstream-SLA-Bedingungen zu kundenspezifischen Vereinbarungen. Das ist teuer — typischerweise 2-4x so viel wie die Mainstream-Wartung — und ohne garantierte Reaktionszeiten für Patches.
• Zugang zu bestehenden SAP Notes. Die Wissensdatenbank bleibt zugänglich. Aber Fixes für neue Probleme existieren möglicherweise nicht.

Das ist nicht theoretisch. 83 % der Datenmigrationsprojekte scheitern oder überschreiten ihr Budget (Bloor Group, 2023). Die Unternehmen, die erfolgreich sind, sind diejenigen, die früh beginnen und sauber planen.

Zur Terminologie: «SAP Hybris», «SAP Commerce» und «SAP Commerce Cloud» werden in verschiedenen Kontexten verwendet. SAP Hybris war der ursprüngliche Markenname nach der Akquisition 2013. Er wurde umbenannt in SAP Commerce (das On-Prem-Produkt) und SAP Commerce Cloud (das verwaltete Cloud-Produkt). Wenn von «Hybris End of Life» die Rede ist, ist die On-Prem-Version gemeint — SAP Commerce On-Premise Version 2205 ist das letzte unterstützte Release. SAP Commerce Cloud (das cloud-gehostete Produkt) erhält weiterhin quartalsweise Updates und ist das Migrationsziel.

Für eine detaillierte Aufschlüsselung dessen, was aufhört und was weiterläuft, lesen Sie unseren EoMM-Vorbereitungsleitfaden.

Der Migrations-Entscheidungsrahmen

Bevor Sie in die Checkliste einsteigen, müssen Sie eine Frage beantworten: Bei SAP bleiben oder wechseln?

Wir sind SAP-Partner. Wir haben ein kommerzielles Interesse daran, Sie bei SAP zu halten. Deshalb seien wir ehrlich, wann welcher Weg Sinn macht.

Bleiben Sie bei SAP Commerce Cloud, wenn:

• Sie SAP ERP betreiben (S/4HANA, ECC) und auf tiefe ERP-Commerce-Integration angewiesen sind. Die nativen Konnektoren sparen 200-400 Stunden Custom-Integrationsarbeit.
• Ihr B2B-Commerce-Modell SAP-spezifische Funktionen nutzt — komplexe Preisfindung, Vertragsmanagement, kundenspezifische Kataloge, Genehmigungsworkflows. Der B2B Accelerator von Commerce Cloud deckt das nativ ab.
• Ihr Team über SAP-Commerce-Skills verfügt. Ein komplettes Reskilling auf eine völlig andere Plattform fügt 3-6 Monate und erhebliche Kosten hinzu.
• Sie schnell handeln müssen. Commerce Cloud Migration bewahrt Ihr Datenmodell, Ihre Geschäftslogik und viele Anpassungen — ein kompletter Plattformwechsel nicht.

Erwägen Sie den Abschied von SAP, wenn:

• Sie kein SAP ERP haben oder die ERP-Integration minimal ist (einfacher Order-Feed). Ohne tiefe Backend-Integration rechtfertigt sich der SAP-Aufpreis nicht.
• Ihr Storefront rein B2C mit Standard-Katalog, Warenkorb und Checkout-Flows ist. Shopify Plus oder ein Composable Stack ist dann möglicherweise einfacher und günstiger.
• Ihr Team keine SAP-Skills hat und Sie diese nicht aufbauen wollen. SAP-Commerce-Entwickler zu finden, wird jedes Jahr schwieriger.
• Sie langfristig eine Composable- oder Headless-Architektur anstreben — allerdings dauert das 9-15 Monate, nicht 4 (lesen Sie unsere Composable-Commerce-Analyse).

Für die meisten SAP-Commerce-On-Prem-Kunden ist SAP Commerce Cloud die pragmatische Antwort. Es ist der risikoärmste Weg, die schnellste Umsetzung und derjenige, der Ihre bestehende Investition bewahrt. «Pragmatisch» heisst aber nicht «automatisch» — treffen Sie diese Entscheidung aktiv.

Auf unserer SAP Commerce Cloud Lösungsseite finden Sie einen vollständigen Überblick über die heutigen Plattform-Funktionalitäten.

Die vollständige Migrations-Checkliste

Vierundzwanzig Punkte in vier Phasen. Das ist die Checkliste, die wir mit unseren Migrationskunden verwenden. Drucken Sie sie aus, hängen Sie sie an die Wand, verfolgen Sie jeden Punkt.

Phase 1: Assessment (Wochen 1-4)

Die Phase, die die meisten Unternehmen überstürzen oder ganz überspringen. Tun Sie das nicht. Alles Nachfolgende hängt davon ab, dass diese Phase sauber durchgeführt wird.

1. Inventarisieren Sie jede Anpassung. Exportieren Sie eine vollständige Liste aller Custom Extensions, ImpEx-Skripte, Custom HAC-Module und modifizierten Plattform-APIs. Klassifizieren Sie jede als: weiterhin benötigt, durch Commerce-Cloud-native-Funktionalität ersetzbar oder obsolet. Unserer Erfahrung nach sind 25-35 % der Anpassungen entfernbar (siehe unseren Beitrag über 5 Migrationsfehler).

2. Erfassen Sie alle Integrationen. Dokumentieren Sie jedes System, mit dem Ihre Commerce-Plattform kommuniziert: ERP, PIM, CRM, Payment Gateway, Versanddienstleister, Steuermodul, Loyalty-System, Marketing-Automation. Für jede Integration: Protokoll (API, IDoc, dateibasiert), Datenvolumen, Frequenz und das verantwortliche Team.

3. Katalogisieren Sie Ihre Storefronts. Wie viele Sites? Wie viele Sprachen? Wie viele Produktkataloge? Multi-Country-Setups mit separater Preisfindung, Steuerregeln und Fulfillment-Logik erhöhen die Komplexität signifikant. Eine Single-Storefront-Migration in einem Land ist ein fundamental anderes Projekt als ein 12-Länder, 6-Sprachen-Deployment.

4. Messen Sie Ihr Datenvolumen. Zählen Sie: Produkte (inklusive Varianten), Kategorien, Kunden, Bestellungen (historisch), Content-Seiten, Medien-Assets. Dies bestimmt Ihre Datenmigrationsstrategie und den Zeitrahmen. Eine Plattform mit 50’000 SKUs migriert fundamental anders als eine mit 5 Millionen.

5. Bewerten Sie Ihren SEO-Footprint. Ziehen Sie Ihr vollständiges URL-Inventar aus der Google Search Console. Wie viele indexierte Seiten? Welchen Wert hat der organische Traffic? Sites mit hohem SEO-Wert brauchen eine detaillierte Redirect-Strategie. Rankings während der Migration zu verlieren kann mehr kosten als die Migration selbst.

6. Evaluieren Sie die Team-Readiness. Kennen Ihre Entwickler SAP Commerce Cloud? Haben sie Erfahrung mit dem Composable Storefront (Spartacus) oder dem SAP Commerce Cloud Accelerator? Wenn nicht, kalkulieren Sie Schulungszeit ein. Cloud-Deployment-Patterns (Kubernetes, CI/CD-Pipelines, Environment-Management) unterscheiden sich erheblich vom On-Prem-Betrieb.

7. Lizenzposition prüfen. Überprüfen Sie Ihre aktuellen SAP-Commerce-Vertragsbedingungen. Klären Sie, was bei EoMM mit Ihrem spezifischen Vertrag passiert — manche Verträge wechseln automatisch zu CSS, andere erfordern eine explizite Zustimmung. Sprechen Sie frühzeitig mit Ihrem SAP-Ansprechpartner. Lizenzverhandlungen dauern Wochen, und Sie wollen keine vertraglichen Überraschungen während der Migration.

Phase 2: Architektur & Planung (Wochen 5-10)

7. Wählen Sie Ihren Storefront-Ansatz. Drei Optionen:

• Composable Storefront (Spartacus/Angular): SAPs empfohlenes modernes Frontend. Headless, vom Backend entkoppelt. Ideal für Neubauten und Teams, die mit Angular vertraut sind. Ermöglicht unabhängige Frontend-Releases.
• Commerce Cloud Accelerator: Der traditionelle JSP-basierte Storefront, in die Cloud migriert. Schnellster Weg, wenn Sie Ihren bestehenden Storefront-Code bewahren wollen. Weniger modern, aber erprobt.
• Custom Headless Frontend: Ihr eigenes React/Next.js/Vue-Frontend, das Commerce-Cloud-APIs konsumiert. Maximale Flexibilität, aber Sie sind vollständig für das Frontend verantwortlich.

Für die meisten Migrationen unter Zeitdruck ist der Accelerator-Ansatz am schnellsten. Als strategische Investition ist der Composable Storefront die richtige Wahl. Die Abwägungen erläutern wir detailliert in unserer Composable-Commerce-Analyse.

8. Entwerfen Sie Ihre Zielarchitektur. Dokumentieren Sie die Cloud-Architektur: Commerce-Cloud-Umgebungen (Dev, Staging, Production), Integrationsarchitektur (SAP Integration Suite vs. direkte API), CDN- und Edge-Caching-Strategie sowie Monitoring/Alerting-Setup.

9. Planen Sie die Integrations-Überarbeitung. On-Prem-Integrationen nutzen oft direkte Datenbankverbindungen, Datei-Drops oder On-Prem-Middleware. In Commerce Cloud läuft alles über APIs oder SAP Integration Suite. Jede Integration braucht einen Migrationsplan. Rechnen Sie mit 3-5 Tagen pro Integration für Analyse und Redesign.

10. Definieren Sie Ihre Datenmigrationsstrategie. Entscheiden Sie: Big-Bang-Migration (vollständiger Datenladen in einem Cutover-Fenster) oder iterative Migration (progressives Laden mit Delta-Sync). Für Plattformen mit über 1 Million Produkten empfehlen wir dringend iterative Migration mit mindestens drei Testläufen vor Go-Live.

11. Erstellen Sie Ihren SEO-Migrationsplan. Mappen Sie jede On-Prem-URL auf ihr Commerce-Cloud-Äquivalent. Planen Sie 301-Redirects für alle URLs, die sich ändern. Richten Sie ein Pre-Migrations-Benchmark in der Google Search Console ein. Details im SEO-Abschnitt unten.

12. Etablieren Sie Ihre Umgebungsstrategie. Commerce Cloud bietet Development-, Staging- und Production-Umgebungen. Richten Sie CI/CD-Pipelines früh ein. Automatisieren Sie Deployments von Tag eins — manuelle Deployments in dieser Phase sind ein Warnsignal.

13. Scope einfrieren. Aufschreiben. Unterschreiben lassen. Die grösste Einzelursache für Migrationsverzögerungen ist Scope Creep — «wenn wir schon dabei sind, könnten wir auch noch…» Nein. Erst migrieren, dann erweitern. Diese Disziplin hat uns beim Franke-Projekt 4 Wochen gespart.

Phase 3: Entwicklung & Migration (Wochen 11-30)

14. Commerce-Cloud-Umgebungen aufsetzen. Alle Umgebungen provisionieren und konfigurieren. Build-Pipelines verifizieren. Validieren, dass Sie Code durch die gesamte Pipeline deployen, testen und promoten können, bevor Sie Geschäftslogik schreiben.

15. Storefront umbauen oder migrieren. Beim Accelerator: JSP-Templates und Frontend-Assets portieren. Beim Composable Storefront: neues Frontend aus den Commerce-Cloud-APIs aufbauen. In beiden Fällen beginnen Sie mit der Homepage, Kategorieseiten und Produktdetailseiten — den Templates mit dem höchsten Traffic.

16. Integrationen überarbeiten. Jede Integration auf die in Phase 2 entworfene Cloud-Architektur migrieren. Mit echten Daten testen, nicht mit Mocks. Integrationstests sind der Punkt, an dem 60 % der Migrationsbugs auftauchen (Standish Group, 2020). Früh testen. Oft testen.

17. Datenmigration ausführen (Testläufe). Mindestens zwei vollständige Testmigrationen vor dem echten Cutover. Messen Sie: Gesamtdauer, Datengenauigkeit und Fehlerrate. Probleme zwischen den Läufen beheben. Jeder Testlauf sollte schneller und sauberer sein als der vorherige.

18. SEO-Änderungen implementieren. Redirect-Map deployen. Kanonische URLs konfigurieren. XML-Sitemap einrichten. robots.txt verifizieren. Mit einem Crawling-Tool (Screaming Frog, Sitebulb) gegen die Staging-Umgebung testen.

19. Performance optimieren. Commerce Cloud hat andere Performance-Charakteristiken als On-Prem. CDN-Caching, API-Antwortzeiten und Cold-Start-Verhalten müssen getestet und getuned werden. Zielmetriken setzen: Seitenladezeit unter 3 Sekunden, Time to Interactive unter 5 Sekunden, Core Web Vitals bestehend.

Phase 4: Testing & Go-Live (Wochen 31-38)

20. Umfassendes UAT durchführen. User-Acceptance-Testing mit echten Business-Usern, nicht nur Entwicklern. Abdecken: Produktsuche, Suche, Warenkorb, Checkout, Zahlung, Bestellbestätigung, Retouren, B2B-Workflows (falls zutreffend). In jedem Storefront, jeder Sprache, jedem Kundensegment testen.

21. Performance-Tests unter Last. Lasttests mit realistischen Traffic-Patterns. Peak-Day-Traffic simulieren (Black Friday, saisonale Spitzen). Commerce Cloud skaliert automatisch, aber Ihr Custom Code und Ihre Integrationen möglicherweise nicht. Engpässe identifizieren, bevor sie Sie in der Produktion finden.

22. SEO-Migration validieren. Staging-URL-Inventar mit dem Production-URL-Inventar vergleichen. Jeden Redirect verifizieren. Sitemap auf Vollständigkeit prüfen. Strukturierte Daten (JSON-LD) mit Googles Rich Results Test testen.

23. Cutover durchführen. Der Cutover-Plan sollte mindestens einmal geprobt sein. Kernschritte: Content-Änderungen auf der alten Plattform einfrieren, finale Delta-Datenmigration, DNS umschalten, alle Integrationen verifizieren, Fehlerraten 48 Stunden überwachen. Rollback-Plan dokumentiert und getestet bereithalten.

24. Post-Go-Live-Monitoring. Minimum 2 Wochen überwachen: Fehlerraten, Conversion Rate im Vergleich zur Pre-Migrations-Baseline, Suchmaschinen-Indexierungsrate, Integrations-Fehlerraten und Kundensupport-Ticket-Volumen. Alerts für jede Abweichung von der Baseline einrichten.

Zeitplan-Kalkulator

Nicht jede Migration ist gleich. Hier sehen Sie, was den Zeitrahmen bestimmt:

Diese Zahlen im April 2026 gelesen: Wenn Sie in der Fast-Track-Kategorie sind, können Sie die Juli-Deadline mit aggressiver Umsetzung noch schaffen. Standardkomplexität? Sie werden die Deadline verpassen, aber können bis Q4 2026 live sein — das bedeutet 3-5 Monate auf kundenspezifischem Support. Komplex? Sie hätten vor 12 Monaten anfangen müssen. Das Beste, was Sie jetzt tun können, ist sofort starten und die Zeit in der Gefahrenzone minimieren.

Kostenschätzungen nach Szenario

Das wird in jedem ersten Gespräch gefragt. Hier sind ehrliche Bandbreiten aus unserem Projektportfolio:

Fast-Track (einzelner Storefront, begrenzte Integrationen): 300’000-500’000 USD. Das setzt einen fokussierten Scope voraus, bestehende SAP-Skills im Team und die Bereitschaft, nicht-essentielle Anpassungen auf Post-Migration zu verschieben. Denken Sie an einen Plattform-Lift mit kontrolliertem Scope.

Mittelstand (2-3 Storefronts, moderate Komplexität): 500’000-800’000 USD. Der Grossteil unserer Migrationsprojekte fällt hierhin. Das Budget umfasst Assessment, Entwicklung, Datenmigration, Integrations-Überarbeitung, Performance-Testing und Go-Live-Support. Commerce-Cloud-Lizenzierung ist nicht enthalten — das ist ein separater jährlicher Kostenpunkt.

Enterprise (5+ Storefronts, komplexes B2B, Multi-Country): 800’000-2 Mio. USD+. Die Bandbreite ist gross, weil Enterprise-Komplexität enorm variiert. Ein 12-Länder-B2B-Betrieb mit Custom-Pricing-Engines, Genehmigungsworkflows und tiefer ERP-Integration ist ein fundamental anderes Projekt als ein 5-Storefront-B2C-Betrieb mit Standard-Checkout.

Das sind Migrationskosten — das einmalige Projekt, um von On-Prem in die Cloud zu wechseln. SAP-Commerce-Cloud-Lizenzierung ist jährlich und hängt von Ihrem GMV und Bestellvolumen ab.

Was in diesen Schätzungen nicht enthalten ist: Commerce-Cloud-Lizenzgebühren (jährlich), Drittanbieter-Lizenzen (PIM, Suche, CMS falls extern), interne Teamzeit und jegliche Post-Migrations-Erweiterungsarbeiten. Kalkulieren Sie einen zusätzlichen Puffer von 15-20 % für Unbekanntes — Datenqualitätsprobleme, Integrationsüberraschungen und Scope-Klärungen, die während der Migration unweigerlich auftreten.

Kostenbeschleunigung nach der Deadline: Migrationspartner — uns eingeschlossen — verzeichnen einen Nachfrage-Spike. Jede Beratung mit SAP-Commerce-Skills ist bis Q4 2026 ausgebucht. Wer im Juli startet, zahlt Premiumpreise für Premium-Dringlichkeit. Ein Start im April gibt Ihnen mehr Optionen und bessere Konditionen.

Die versteckten Kosten des Nichtstuns: Kundenspezifischer Support nach EoMM kostet 2-4x so viel wie die Mainstream-Wartung. Für ein Unternehmen mit 200’000 USD/Jahr SAP-Wartung sind das 400’000-800’000 USD pro Jahr — nur um den Betrieb aufrechtzuerhalten, ohne Verbesserungen, neue Features oder garantierte Sicherheitspatches. Zwei Jahre CSS kosten mehr als die meisten Migrationen.

SEO-Migration: Rankings nicht verlieren

Dieser Abschnitt existiert, weil wir Unternehmen erlebt haben, die eine einwandfreie technische Migration durchgeführt und dann 40-60 % ihres organischen Traffics verloren haben, weil niemand den SEO-Übergang geplant hat. Organischer Traffic macht oft 30-50 % des E-Commerce-Umsatzes aus. Rechnen Sie aus, was es für Ihr Geschäft bedeutet, die Hälfte davon zu verlieren.

Vor der Migration:

1. Alles benchmarken. Aus der Google Search Console exportieren: alle indexierten URLs, Click-Daten, Impression-Daten, durchschnittliche Position für Top-Queries. Ab jetzt wöchentlich aufzeichnen — Sie brauchen die Trendlinie, nicht einen einzelnen Snapshot.
2. Aktuelle Site crawlen. Mit Screaming Frog oder Sitebulb. Das vollständige URL-Inventar, die interne Linkstruktur, Canonicals und strukturierte Daten erfassen. Das ist Ihr Referenzdokument.
3. Jede URL mappen. Tabelle erstellen: alte URL → neue URL → Redirect-Typ (301 in fast jedem Fall). Wenn sich Ihre URL-Struktur ändert, ist diese Tabelle kritisch.

Während der Migration:

4. Redirects früh implementieren. Nicht bis zur Cutover-Woche aufheben. Redirect-Regeln parallel zur neuen Plattform aufbauen. Auf Staging testen.
5. Metadaten bewahren. Seitentitel, Meta-Descriptions, Heading-Strukturen und strukturierte Daten (JSON-LD, Produkt-Schema, Breadcrumb-Schema) müssen alle übernommen werden. Alles von Grund auf neu zu erstellen garantiert Ranking-Verluste.
6. XML-Sitemap aktuell halten. Die neue Sitemap sollte vor Go-Live bereit sein. Sofort nach DNS-Umschaltung in der Search Console einreichen.

Nach der Migration:

7. 4 Wochen lang täglich überwachen. Beobachten: Indexierungsrate (wie schnell Google neue URLs aufnimmt), 404-Fehlerrate (verpasste Redirects), organischer Traffic im Vergleich zur Baseline, Ranking-Positionen für die Top-50-Queries.
8. Probleme sofort beheben. Wenn die Search Console einen Spike bei 404s oder einen Coverage-Drop zeigt, beheben Sie es am selben Tag. Nicht im nächsten Sprint. Am selben Tag. Die ersten 2-4 Wochen nach der Migration sind die Zeit, in der Google Ihre gesamte Site neu bewertet.

Was ist mit dem Franke-Ansatz?

Wir haben Franke in 90 Tagen von SAP Hybris zu SAP Commerce Cloud migriert. SAP hat uns dafür einen Quality Award verliehen. Das vollständige Playbook ist hier veröffentlicht: Von SAP Hybris zu Commerce Cloud in 90 Tagen.

Die Kurzversion: 30 Tage Vorbereitung vor Kickoff, kompromissloses Scope-Management (35 % der Anpassungen eliminiert), parallele Workstreams und iterative Delivery. Nicht jedes Unternehmen kann 90 Tage schaffen — Franke hatte einen fokussierten Scope und ein eingespieltes Team. Aber die Methodik ist auf jeden Zeitrahmen anwendbar.

Zentrale Erkenntnisse aus dem Franke-Ansatz, die für jede Migration gelten:

• Auditieren vor dem Migrieren. Wir haben festgestellt, dass 35 % der Anpassungen bei Franke entweder obsolet oder durch native Commerce-Cloud-Funktionalität ersetzbar waren. Das sind 35 % weniger Code zum Migrieren, Testen und Warten.
• Parallele Workstreams. Storefront, Integrationen und Datenmigration nicht sequenziell abarbeiten. Parallel laufen lassen mit täglicher Koordination. Das allein kann einen 12-Monats-Zeitplan auf 8 Monate komprimieren.
• Iterative Delivery statt Big-Bang. Früh in die Cloud deployen, auch wenn unvollständig. Echtes Feedback aus echter Infrastruktur holen. Agile Delivery zeigt 42 % Erfolgsquote gegenüber 13 % bei Wasserfall (Standish Group, 2020).

Lesen Sie die vollständige Franke-Erfolgsgeschichte für die detaillierten Ergebnisse.

Die «Nichts-Tun»-Risikobewertung

Einige Unternehmen werden diese Checkliste betrachten und entscheiden: Wir kümmern uns nach Juli 2026 darum. So sieht das dann aus.

Sicherheitsrisiko. Ihre Plattform erhält keine Sicherheitspatches mehr. SAP Commerce verarbeitet Kundendaten, Zahlungsinformationen und personenbezogene Daten. Eine ungepatchte Commerce-Plattform zu betreiben, verstösst gegen den Geist — und möglicherweise den Wortlaut — von PCI-DSS, DSGVO und dem Schweizer nDSG. Bei einem Audit ist «wir haben die Migration nicht rechtzeitig geschafft» keine Verteidigung.

Compliance-Risiko. Mehrwertsteuerregeln ändern sich. Steuervorschriften entwickeln sich weiter. Datenschutzanforderungen werden aktualisiert. Ohne dass SAP Compliance-Patches liefert, müssen Sie diese selbst implementieren. Die meisten Unternehmen haben nicht die Expertise, SAP-Commerce-Kern-Compliance-Module sicher zu modifizieren.

Kostenexplosion. Kundenspezifischer Support kostet 2-4x so viel wie die Mainstream-Wartung. Und die Migrationskosten sinken nicht mit der Zeit — sie steigen. Entwickler mit SAP-Hybris-On-Prem-Erfahrung werden seltener. Beratungsfirmen sind ausgebucht. Die Preise steigen nach der Deadline, nicht davor.

Talentabwanderung. SAP-Commerce-Entwickler bewegen sich in Richtung Cloud-Skills. Jemanden zu finden, der an einer End-of-Life-On-Prem-Plattform arbeiten will, wird jedes Quartal schwieriger. Ihr bestehendes Team könnte zu Unternehmen wechseln, die moderne Stacks betreiben.

Wettbewerbsnachteil. Während Sie eine eingefrorene Plattform warten, erhalten Wettbewerber auf Commerce Cloud quartalsweise neue Features, Performance-Verbesserungen und KI-Funktionen. Commerce Cloud liefert 4 grosse Updates pro Jahr. On-Prem nach EoMM liefert null.

Versicherungs- und Audit-Risiko. Cyber-Versicherer fragen zunehmend nach dem Wartungsstatus der Plattform. Eine ungepatchte E-Commerce-Plattform mit Kundendaten zu betreiben kann Ihre Versicherungsbedingungen oder Prämien beeinflussen. Externe Auditoren — ob für SOC 2, ISO 27001 oder PCI-DSS — werden eine End-of-Maintenance-Commerce-Plattform als wesentliches Finding markieren. Das erzeugt Vorstandsvisibilität, die Sie vermutlich nicht wollen.

Nächste Schritte

Wenn Sie bis hierher gelesen haben, kennen Sie die Situation. Vier Monate sind knapp, aber für Fast-Track-Szenarien machbar. Für alles andere: Jetzt starten und die Expositionszeit minimieren.

1. Assessment-Gespräch buchen. Wir führen ein strukturiertes Migrations-Assessment in 2-3 Wochen durch. Das liefert: Anpassungsinventar, Integrations-Map, Komplexitätsbewertung, Zeitplan-Schätzung und Budgetrahmen. Hier starten.
2. Begleitmaterial lesen. Unser EoMM-Vorbereitungsleitfaden zeigt im Detail, was aufhört. Das 90-Tage-Playbook zeigt, wie schnelle Umsetzung aussieht. Die Composable-Commerce-Analyse behandelt die «SAP verlassen»-Option ehrlich.
3. Besuchen Sie unsere On-Prem-Kampagnenseite für dedizierte Ressourcen und Migrationsangebote.
4. Warten Sie nicht auf Q3. Jede Woche Verzögerung reduziert Ihre Optionen. Der Unterschied zwischen einem Start im April und einem Start im Juni ist der Unterschied zwischen Deadline einhalten und Deadline verpassen.

Die Deadline bewegt sich nicht. Ihre Bereitschaft kann es. Sprechen Sie mit uns.