SAP Commerce On-Premise nach dem 31. Juli 2026: Was sich geändert hat und Ihre vier Optionen

Die Mainstream Maintenance für SAP Commerce On-Premise, die Plattform, die viele Teams noch Hybris nennen, endete am 31. Juli 2026 (SAP Help Portal). Release 2205 war das letzte On-Premise-Release, ein weiteres hat SAP nicht geplant. Dieser Beitrag ist unser laufend gepflegter Leitfaden für alle, die noch darauf arbeiten: was sich geändert hat, welcher Support bleibt und wie die realistischen Optionen im Vergleich abschneiden.

Am 1. August ist nichts kaputtgegangen. Die Shops blieben online, die Bestellungen liefen weiter, und genau deshalb wird diese Phase leicht unterschätzt. Die Kosten des Weiterbetriebs zeigen sich nicht als Ausfall. Sie zeigen sich als offene Schwachstellen, als Compliance-Arbeit, die jetzt Ihr Team trägt, und als Migration, die mit jedem Quartal schwerer zu besetzen ist.

Kurzfassung: Seit dem 31. Juli 2026 läuft SAP Commerce On-Premise (Release 2205) in der kundenspezifischen Wartung: Bekannte Probleme werden weiterhin gelöst, aber es gibt keine Support Packages, keine gesetzlichen Änderungen und keine Bibliotheks-Updates mehr, und neue Probleme können Zusatzkosten verursachen. Sie haben vier Optionen: befristet weiterbetreiben, die kundenspezifische Wartung bewusst als Brücke nutzen, zu SAP Commerce Cloud migrieren (oder, wenn Sie S/4HANA Public Cloud betreiben, zur neuen ERP Edition) oder SAP verlassen. Für die meisten SAP-integrierten B2B-Shops bewahrt die Migration innerhalb des SAP-Stacks die ERP-Integration und kostet in der Summe am wenigsten. Sprechen Sie mit uns über Ihre Landschaft.

Was sich am 1. August 2026 geändert hat

“End of Mainstream Maintenance” ist präzises SAP-Vokabular. Seit dem 1. August 2026 gilt für SAP Commerce On-Premise:

• Keine neuen Support Packages und Sicherheitspatches. Wenn die nächste Schwachstelle in der Plattform oder einer mitgelieferten Bibliothek (Spring, Solr, Apache-Komponenten) auftaucht, liefert SAP für 2205 keinen Fix. Das System, das Kundenkonten hält und Zahlungsflüsse berührt, sammelt ab jetzt offene Punkte an.
• Keine gesetzlichen und steuerlichen Änderungen. MWST-Satzänderungen, Rechnungsvorschriften und datenschutzbedingte Anpassungen sind jetzt Eigenentwicklung, multipliziert mit der Zahl der Länder, in denen Sie verkaufen.
• Keine Updates von Drittbibliotheken und keine neuen Java-Versionen. SAP testet und zertifiziert keine neuen JVM-Releases mehr für On-Premise. Die heutige Laufzeitumgebung altert an Ort und Stelle.
• Keine neuen Technologie- oder Schnittstellen-Updates. Wenn Zahlungs-, Logistik- und ERP-Partner ihre APIs ändern, ist es Ihre Aufgabe, die Integrationen am Laufen zu halten.
• Keine neuen Storefront-Funktionen. SAP Composable Storefront (früher Spartacus) und neue Fähigkeiten wie KI-gestütztes Merchandising werden für SAP Commerce Cloud entwickelt (SAP Help Portal).

Die End of Mainstream Maintenance FAQ von SAP ist die Referenz für die produktspezifischen Details; prüfen Sie sie, bevor Sie ein Budget festlegen.

Was die kundenspezifische Wartung noch abdeckt

Nach der Mainstream Maintenance gehen SAP-Releases automatisch in die kundenspezifische Wartung über. Gemäss der Definition von SAP (SAP Support, Customer-Specific Maintenance):

• Sie läuft im Rahmen Ihres bestehenden Supportvertrags weiter; ein separater Vertrag ist nicht nötig.
• Die Problemlösung umfasst bekannte Probleme. Die Lösung neuer Probleme kann kostenpflichtig sein.
• Es gibt keine gesetzlichen Änderungen, keine neuen Support Packages und keine garantierten Technologie-Updates wie neue Datenbank-, Betriebssystem- oder Java-Versionen.

Sie behalten also einen Supportkanal, aber kein gepflegtes Produkt. Als Brücke während einer Migration ist das nützlich. Als Dauerlösung taugt es nicht, und deshalb sprechen wir beim On-Premise-Pfad nicht mehr von “verlängertem Support”: Verlängert wird nichts, der Service wird schmaler.

Wo die Kosten des Weiterbetriebs stecken

Die Lizenzrechnung ist der sichtbare Teil. Der grösste Teil der Kosten für On-Premise nach EoMM steckt in Positionen, die selten in derselben Tabelle stehen:

Kostenposition	On-Premise nach EoMM	SAP Commerce Cloud
Infrastruktur (Produktion, Staging, Entwicklung, Disaster Recovery)	Hosting, Netzwerk und Verfügbarkeit liegen bei Ihnen	Im Abonnement enthalten
Sicherheitspatches	Ihr Team entwickelt und testet Fixes oder trägt das Risiko	Liefert SAP mit den Plattform-Updates
Steuer-, Rechts- und Java-Updates	Eigenentwicklung	Liefert SAP
Betrieb	Eigenes Plattformpersonal	Kleiner, auf Geschäftslogik fokussiert
Spezialisten	Ein schrumpfender Pool an On-Premise-Entwicklern	Ein grösserer Commerce-Cloud-Talentpool
Funktions-Backlog	Jede neue Fähigkeit ist ein Eigenprojekt	Regelmässige Plattform-Releases

Pauschale CHF-Beträge setzen wir bewusst nicht in diese Tabelle: Sie hängen von Ihrer Installation, der Zahl der Storefronts und davon ab, wie viel Betrieb Sie selbst leisten. In einem Assessment füllen wir sie mit Ihren Zahlen. Wie die Abonnementseite aufgebaut ist, erklärt unser Leitfaden zu Preisen und TCO von SAP Commerce Cloud.

Zwei Kosten verdienen eine eigene Erwähnung. Fachkräfte: Immer weniger Entwicklerinnen und Entwickler wollen auf einer nicht mehr gewarteten Plattform arbeiten, und wenn eine einzelne Person das kritische Wissen über Ihre Anpassungen trägt, ist das ein Geschäftsrisiko. Opportunitätskosten: Jede Funktion, die das Business wünscht (ein neuer Checkout, ein PWA-Frontend, B2B-Self-Service), wird auf einer eingefrorenen Plattform zur Eigenentwicklung.

Option 1: Weiterbetreiben und das Risiko tragen

Das ist der Standard, weil er keine Entscheidung erfordert, und es ist die einzige Option, deren Kosten jeden Monat steigen.

Für einen kleinen B2B-Shop mit wenig Änderungen hinter einem gehärteten Netzwerk kann ein Weiterbetrieb über einige Monate, während eine Migration vorbereitet wird, ein vertretbares, kalkuliertes Risiko sein. Weiterbetrieb ohne Migrationsplan ist ein aufgeschobener Vorfall. Das Risiko kumuliert sich: Jede ungepatchte Schwachstelle bleibt offen, die Compliance-Arbeit wandert zu Ihrem Team, und Ihre Position gegenüber Revision und Versicherung verschlechtert sich. “Wir wickeln Zahlungen auf Software ab, die nicht mehr gewartet wird” ist ein Satz, den Ihr CISO irgendwann laut aussprechen muss.

Wählen Sie diese Option nur als ausdrückliche, befristete Brücke mit einer freigegebenen Risikobeurteilung, während eine der anderen Optionen bereits läuft.

Option 2: Kundenspezifische Wartung als geplante Brücke

In der Praxis läuft diese Option parallel zu Option 1: In der kundenspezifischen Wartung sind Sie ohnehin, ob Sie das gewählt haben oder nicht. Der Unterschied ist, ob Sie sie bewusst nutzen. Sie verschafft Ihnen einen Supportkanal für bekannte Probleme und einen Hersteller, den Sie noch anrufen können. Neue Funktionen, Sicherheitspatches oder eine Roadmap verschafft sie Ihnen nicht.

Sinnvoll ist das in einem Szenario: eine grosse, komplexe Landschaft, die nicht innerhalb von 12 Monaten migrieren kann (regulatorischer Freeze, M&A, ein paralleles ERP-Programm) und eine dokumentierte Brücke braucht. Wenn das auf Sie zutrifft, klären Sie jetzt mit SAP, wie neue Probleme für Ihren Vertrag behandelt und verrechnet würden, statt nach dem ersten Vorfall, und setzen Sie das Ende der Brücke auf dieselbe Folie wie den Migrationsstart.

Option 3: Migration zu SAP Commerce Cloud

Der naheliegende Weg, und der, bei dem Ihre bisherige Investition erhalten bleibt: Datenmodell, Geschäftslogik, ein grosser Teil der Anpassungen und vor allem die ERP-Integration kommen mit. Es ist auch die Option, die wir am besten kennen; gewichten Sie unsere Sicht entsprechend und prüfen Sie sie an den Referenzen.

• Franke: Wir haben eine festgefahrene Legacy-Commerce-Plattform übernommen und SAP Commerce Cloud in 90 Tagen live gebracht. Der Commerce-Launch erhielt den SAP Quality Award für “Rapid Time to Value”, und die manuellen Bestellungen sanken um rund 75 %. Das 90-Tage-Playbook beschreibt die Methode.
• ANWR Group: eine Headless-B2B/B2C-Plattform auf SAP Commerce Cloud mit über 5 Millionen Produkt-SKUs und 80 % schnellerer Produktdatensynchronisation.
• Distrelec: vom monolithischen SAP Commerce Setup zur Headless-Architektur, mit 70 % kürzerer Time-to-Market und 15 % höherer Conversion Rate.

Realistische Zeitrahmen: 6 bis 12 Monate für eine typische Migration, 4 bis 6 Monate für einen disziplinierten Fast Track, 90 Tage am schnellen Ende mit vollständiger Vorbereitung.

Wenn Sie migrieren, bereiten Sie sich so vor. Der grösste Teil von Zeit und Geld einer Migration wird entschieden, bevor die erste Codezeile umzieht:

1. Jede Anpassung prüfen. Ordnen Sie jede als weiterhin nötig, durch Standardfunktionen ersetzbar oder obsolet ein. Eigenes Caching, Skalierungsskripte und Deployment-Pipelines sind typische On-Premise-Workarounds, die Commerce Cloud von Haus aus abdeckt.
2. Jede Integration erfassen. ERP, PIM, CRM, Zahlung, Logistik: Hier verstecken sich die Überraschungen.
3. Daten früh analysieren. Jahrelang gewachsene Dubletten, verwaiste Referenzen und uneinheitliche Katalogstrukturen werden durch einen Umzug nicht besser.
4. Vor dem Umzug aufräumen. Ungenutzte Extensions entfernen, fest codierte Konfiguration auslagern, tote Integrationen stilllegen und alte Testdaten löschen.
5. Iterativ liefern. Zuerst die Kernplattform, dann Storefronts und Märkte nacheinander, statt eines einzigen Big-Bang-Wochenendes.

Mehr dazu in den fünf häufigsten Fehlern bei der SAP Commerce Migration und in der schrittweisen Checkliste für die SAP Hybris Migration.

Der Blick auf die ERP Edition. Ein häufiger Einwand mittelgrosser On-Premise-Shops war, dass die volle Commerce Cloud für Konzerne dimensioniert und bepreist sei. SAP Commerce Cloud, ERP Edition, im Mai 2026 angekündigt, verändert diese Rechnung für Unternehmen auf SAP S/4HANA Public Cloud: eine paketierte B2B-Commerce-Schicht, die über ERP-native Masken bedient wird, wobei SAP einen grossen Teil der Integration übernimmt (DSAG impulsant). Spadoom ist einer der ersten Pilotpartner, mit einem Schweizer B2B-Kunden aus dem Mittelstand; was die ERP Edition für KMU verändert, beschreiben wir hier. Läuft Ihr ERP noch auf ECC, gehören die Commerce- und die ERP-Entscheidung zusammen, und unser S/4HANA Readiness Assessment ist der sinnvolle erste Schritt. Wie beides zusammenpasst, zeigt unser Leitfaden zu Commerce Cloud und S/4HANA Public Cloud im B2B.

Option 4: Replatforming weg von SAP

SAP Commerce zu verlassen ist eine legitime Option und für manche Unternehmen die richtige. Wenn sich Ihre Commerce-Anforderungen auf das vereinfacht haben, was Shopify Plus standardmässig kann, oder Ihre Architekturstrategie wirklich composable ist und Sie die Entwicklungsorganisation haben, um sie zu tragen, verdient ein Replatforming eine ernsthafte Prüfung. Unsere Einschätzung, wann Composable Commerce im B2B sinnvoll ist, geht die Kriterien durch.

Beziffern Sie die Punkte, die in Replatforming-Präsentationen gern fehlen:

• Neubau der ERP-Integration. Preise, Verfügbarkeitsprüfung, Kreditprüfung, Auftragssteuerung und Stammdaten sind der wertvollste und unsichtbarste Teil Ihrer heutigen Plattform. Beim Replatforming bauen Sie sie neu, meist über Middleware, die zum eigenen Projekt wird.
• B2B-Tiefe. Kontraktpreise, Punch-out, Freigabe-Workflows und mehrstufige Kontostrukturen sind in SAP Commerce ausgereift und anderswo oft Add-ons oder Eigenentwicklungen.
• Die Datenarbeit wird nicht kleiner. Katalog-, Kunden- und Auftragsdaten müssen trotzdem umziehen; der Integrations-Workstream kommt obendrauf.
• Zeitrahmen. Replatforming-Projekte für eine SAP-integrierte Landschaft dauern typischerweise 6 bis 12 Monate oder länger, also gleich lang wie eine SAP-zu-SAP-Migration, ohne dass etwas mitkommt.

Wenn Sie SAP ERP betreiben und echte B2B-Anforderungen haben, spricht die Gesamtkostenrechnung meist für den Verbleib im SAP-Stack. Wenn nicht, führen Sie die Evaluation durch und verlangen Sie von jedem Anbieter die Integrationspositionen, nicht nur Lizenzvergleiche.

Die Zeitrechnung im Vergleich

Weg	Zeit bis zu einem gewarteten Zustand	Risiko in der Zwischenzeit	Was Sie am Ende haben
Weiterbetreiben	Nie	Wächst unbegrenzt	Dieselbe Plattform, älter
Kundenspezifische Wartung als Brücke	Sofort, aber mit reduziertem Umfang	Bekannte Probleme abgedeckt, neue evtl. kostenpflichtig	Einen Supportkanal, keine Roadmap
Migration zu Commerce Cloud oder ERP Edition	3 bis 12 Monate	Auf die Projektdauer begrenzt	Eine gewartete, sich weiterentwickelnde Plattform; Investition bleibt erhalten
Replatforming weg von SAP	6 bis 12 Monate oder mehr	Auf das Projekt begrenzt, meist länger	Eine neue Plattform, neu gebaute Integrationen, eine neue Lernkurve

Drei der vier Wege beinhalten Monate auf einer Plattform, die keine Patches mehr erhält. Dieses Risiko begann am 1. August, ob Sie etwas entschieden haben oder nicht. Was Sie noch steuern, ist seine Dauer.

Was wir an Ihrer Stelle tun würden

Erste Woche: eine zweiseitige Risikobeurteilung der aktuellen Landschaft mit Versionen, Anpassungsumfang, Integrationsinventar und Compliance-Pflichten. Erster Monat: eine Entscheidung zwischen kundenspezifischer Wartung als Brücke, Migration und Replatforming, mit echten Offerten auf dem Tisch statt Richtwerten. Die Reihenfolge ist wichtig, weil die Kapazitäten der Implementierungspartner knapper werden, je mehr der abwartenden Unternehmen gleichzeitig loslegen. Wenn Sie noch Partner vergleichen, zeigt unsere Übersicht der SAP Commerce Cloud Partner in der Schweiz, worauf es ankommt.

Wir führen dieses Assessment als Engagement mit festem Umfang durch. Der Support ist ausgelaufen, die Optionen nicht. Sie haben jetzt nur eine Uhr.

Migrations-Assessment anfragen, mehr auf unserer SAP Commerce Cloud Lösungsseite lesen oder mit der On-Premise-Entscheidungsseite starten.