7 SAP Commerce Cloud Fehler, die Projekte entgleisen lassen (und wie Sie sie vermeiden)

SAP Commerce Cloud ist eine solide Plattform. Sie ist aber auch komplex genug, dass dieselben Fehler immer wieder Projekte aus der Bahn werfen, über Branchen, Teamgrössen und Budgets hinweg. Die Muster sind vorhersehbar, und das ist die gute Nachricht: Vorhersehbare Fehler lassen sich verhindern.

Hier sind die sieben, die wir am häufigsten sehen, jeweils mit dem, was dagegen hilft.

Kurzfassung: SAP Commerce Cloud Projekte gehen aus sieben wiederkehrenden Gründen schief: Java-Generalisten statt Commerce-Spezialisten, aufgeschobene Upgrades, eine überangepasste Plattform, vage Anforderungen, vernachlässigte Performance, unterschätzte Datenmigration und zu wenig Tests. Für jeden gibt es einen konkreten Gegenschritt, und der gemeinsame Nenner ist, früh zu entscheiden statt spät zu reparieren. Wenn Sie noch auf SAP Commerce On-Premise sind, lesen Sie zuerst unseren Leitfaden zu den Optionen nach dem Ende der Mainstream Maintenance.

Fehler 1: Java-Generalisten statt Commerce-Spezialisten einstellen

Commerce Cloud läuft auf Java, also stellen Unternehmen starke Java-Entwickler ein und erwarten, dass sie ab dem ersten Tag produktiv sind. Das werden sie nicht sein.

Commerce Cloud hat ein eigenes Datenmodell (das Typsystem), einen eigenen Importmechanismus (ImpEx), eine eigene Extension-Architektur, eine eigene Build- und Deployment-Pipeline sowie eigenes Caching und eine eigene Suchindexierung (Solr). Ein erfahrener Java-Entwickler ohne Commerce-Cloud-Erfahrung braucht Monate, um sich einzuarbeiten, und macht in dieser Zeit genau die Architekturfehler, die teuer zu korrigieren sind: das Typsystem überanpassen, den Upgrade-Pfad verbauen, Eigencode schreiben, wo Standardkonfiguration gereicht hätte.

Wir haben Projekte übernommen, in denen genau das passiert war, und die Bereinigung kostete mehr, als es gekostet hätte, von Anfang an die richtigen Leute einzusetzen.

So verhindern Sie es: Stellen Sie Entwicklerinnen und Entwickler mit nachgewiesener SAP Commerce Cloud Erfahrung ein. Fragen Sie nach konkreten Projektreferenzen und prüfen Sie SAP-Zertifizierungen. Wenn Sie ein internes Team aufbauen, stellen Sie jeder neuen Person für die ersten Monate einen erfahrenen Commerce-Cloud-Berater zur Seite. Wenn Sie noch einen Implementierungspartner suchen, zeigt unsere Übersicht der SAP Commerce Cloud Partner in der Schweiz, worauf Sie achten sollten.

Fehler 2: Upgrades überspringen oder aufschieben

SAP aktualisiert Commerce Cloud regelmässig (SAP Help Portal). Jedes Update bringt Sicherheitspatches, Performance-Verbesserungen, neue Funktionen und Fehlerbehebungen. Updates auszulassen fühlt sich nach Zeitersparnis an, erzeugt in Wahrheit aber ein sich aufschaukelndes Problem. Je länger Sie warten, desto mehr Updates stauen sich, und desto schwerer wird das spätere Upgrade.

Nach zwei oder drei übersprungenen Releases kann der Upgrade-Aufwand an die ursprüngliche Implementierung heranreichen. Eigencode, der auf Version N lief, kompiliert auf N+3 vielleicht nicht mehr, Abhängigkeiten driften auseinander, und der Testaufwand vervielfacht sich. Plattformweite Änderungen wie der Wechsel auf Java 21 und Spring 6 machen das sehr konkret; was diese Migration bedeutet, beschreiben wir in unserem Leitfaden zu Java 21 und Spring 6 in SAP Commerce Cloud.

So verhindern Sie es: Behandeln Sie Upgrades als Routinewartung, nicht als Projekte. Reservieren Sie jedes Jahr ein festes Budget für Commerce-Cloud-Updates und spielen Sie sie innerhalb eines Release-Zyklus ein. Wenn Sie so häufig nicht upgraden können, ist Ihr Anpassungsumfang wahrscheinlich zu gross, und damit sind wir bei Fehler 3.

Fehler 3: Die Plattform überanpassen

Das Extension-Framework von Commerce Cloud macht es leicht, fast alles zu verändern. Zu leicht. Jede Eigen-Extension ist Code, den Sie besitzen, pflegen und bei jedem Upgrade testen. Jede einzelne erhöht den Upgrade-Aufwand, vergrössert die Testfläche und schafft mögliche Kompatibilitätsprobleme.

Eine Landschaft mit hundert oder mehr Eigen-Extensions kann jedes Upgrade zu einem mehrmonatigen Projekt machen. Sie auf einen kleinen, begründeten Satz zu konsolidieren, der dieselben Geschäftsfunktionen abdeckt, ist oft der schnellste Weg, Upgrades wieder zur Routine zu machen: gleiche Ergebnisse, ein Bruchteil der Wartung.

Die schlimmsten Verursacher: Änderungen an Kerndefinitionen des Typsystems, überschriebene Standard-Controller und Eigenimplementierungen, die Standardfunktionen mit kleinen Abweichungen nachbauen.

So verhindern Sie es: Fragen Sie vor jeder neuen Eigen-Extension, ob Standardkonfiguration reicht. Wenn nicht, nutzen Sie die Erweiterungspunkte der Plattform und auf der Storefront-Seite die Anpassungsmechanismen von SAP Composable Storefront, statt Kerncode zu verändern. Setzen Sie eine Obergrenze für Eigen-Extensions (10 bis 15 sind für ein Projekt mittlerer Komplexität ein vernünftiges Ziel) und dokumentieren Sie für jede einzelne die fachliche Begründung.

Wie wir Anpassungen schlank halten und trotzdem das Maximum aus der Plattform holen, zeigt unsere SAP Commerce Cloud Lösungsseite.

Fehler 4: Vage oder unrealistische Geschäftsanforderungen

Laut einer Gartner-Umfrage erreichen oder übertreffen nur 48 % der digitalen Initiativen ihre Geschäftsziele (Gartner, 2024). Unklare Anforderungen tragen häufig dazu bei.

“Wir wollen eine E-Commerce-Plattform wie Amazon” ist keine Anforderung. “Wir brauchen eine B2B-Storefront mit kundenspezifischen Preisen, Mindestbestellmengen, Freigabe-Workflows und einer Anbindung an unser SAP ERP für Echtzeit-Verfügbarkeit” ist eine.

Wenn Geschäftsanforderungen vage sind, füllt das Implementierungsteam die Lücken mit Annahmen, und diese Annahmen sind oft falsch. Einige Monate später wird die Lücke sichtbar, und teuer: Nacharbeit, ausufernder Projektumfang und ein System, das nicht zu dem passt, was die Anwender brauchen.

So verhindern Sie es: Definieren Sie Anforderungen auf Prozessebene, nicht auf Funktionsebene. Arbeiten Sie mit konkreten Beispielen: “Wenn sich ein Einkäufer von Kunde X anmeldet, sieht er seine verhandelte Preisliste und seine Bestellhistorie der letzten 12 Monate.” Gehen Sie jeden Ablauf aus Kundensicht durch: Stöbern, Suchen, Produkte konfigurieren, Bestellen, Aufträge verfolgen und Retouren.

Fehler 5: Performance vernachlässigen, bis es zu spät ist

Ein langsamer Shop kostet Umsatz, und im B2B kostet er zusätzlich das Vertrauen von Einkäufern, die ihn täglich nutzen.

Die Performance von Commerce Cloud hängt von sauberer Suchindexierung, Caching-Konfiguration, CDN-Setup und effizientem Eigencode ab. Viele Teams konzentrieren sich im Build ausschliesslich auf Funktionalität und entdecken Performance-Probleme erst im Lasttest oder nach dem Go-live.

Typische Performance-Killer: nicht optimierte Produktabfragen, fehlende Cache-Header, zu viele API-Aufrufe pro Seite, grosse Kataloge ohne saubere Indexierung und Eigencode, der das eingebaute Caching der Plattform umgeht.

So verhindern Sie es: Legen Sie ab dem ersten Tag Performance-Budgets fest, zum Beispiel Ladezeiten unter 2 Sekunden für Produktlisten und unter 1,5 Sekunden für Produktdetailseiten. Führen Sie Lasttests nach jedem Sprint durch, nicht erst vor dem Go-live, und überwachen Sie Suchantwortzeiten, Cache-Trefferquoten und API-Antwortzeiten laufend.

Fehler 6: Die Datenmigration zu knapp planen

Die Datenmigration für Commerce Cloud umfasst Produkte, Kategorien, Preise, Kunden, historische Aufträge und Inhalte (CMS-Seiten, Medien). Jeder Datentyp hat sein eigenes ImpEx-Format, eigene Validierungsregeln und eigene Abhängigkeiten. Produkte hängen von Kategorien ab, Preise von Produkten, Aufträge von Kunden und Produkten. Die Abhängigkeitskette ist real.

Teams, die die Migration als einmaliges Skript behandeln, stellen im Abnahmetest fest, dass manche Produkte defekte Bilder haben, Kundenkonten doppelt vorhanden sind und historische Aufträge nicht korrekt angezeigt werden. Dann ist der Go-live-Termin in Gefahr. Die migrationsspezifischen Stolpersteine beschreiben wir ausführlicher in den fünf häufigsten Fehlern bei der SAP Commerce Migration.

So verhindern Sie es: Planen Sie die Migration als eigenen Workstream mit eigenem Zeitplan, nicht als Aufgabe. Führen Sie vor dem Go-live mindestens drei vollständige Migrationsläufe durch: einen zur Strukturvalidierung, einen zur Prüfung der Datenqualität und einen als Generalprobe. Validieren Sie ImpEx-Dateien vor dem Import und prüfen Sie Bilder, Kategoriezuordnungen und Preisverknüpfungen automatisiert.

Fehler 7: Zu wenig testen

Zu wenig Tests sind der Weg, auf dem viele Budgetüberschreitungen entstehen, denn spät gefundene Fehler kosten deutlich mehr als früh gefundene.

Commerce-Cloud-Projekte brauchen mehrere Testarten: Unit-Tests für Eigencode, Integrationstests für API-Verbindungen, Performance-Tests unter Last und Abnahmetests mit echten Geschäftsszenarien. Wer eine davon auslässt, geht ein Risiko ein.

Die gefährlichste Lücke ist der Integrationstest mit dem ERP. Commerce Cloud sendet Aufträge an das ERP und erhält Verfügbarkeiten, Preise und Versand-Updates zurück. Wird diese Integration nicht unter realistischen Bedingungen getestet (gleichzeitige Nutzer, Spitzenlasten, Fehlerszenarien), zeigen sich die Probleme am Launch-Tag. Für Unternehmen auf SAP S/4HANA erklärt unser Leitfaden zu SAP Commerce Cloud mit S/4HANA Public Cloud im B2B, wo diese Nahtstelle liegt.

So verhindern Sie es: Planen Sie Tests als substanziellen Anteil des gesamten Projektaufwands ein. Beginnen Sie Integrationstests in der Projektmitte, nicht in der letzten Woche. Setzen Sie automatisierte Suiten für Regressionstests bei jedem Deployment ein und lassen Sie Abnahmetests von echten Fachanwendern mit realen Szenarien durchführen, nicht vom Implementierungsteam, das sich durch Idealabläufe klickt.

Häufig gestellte Fragen

Welcher Commerce Cloud Fehler ist am teuersten zu beheben?

Überanpassung. Tief verankerte Eigen-Extensions zu entfernen oder umzubauen kann mehr kosten als die ursprüngliche Implementierung, und jede Extension verteuert jedes Upgrade. Jede Eigen-Extension braucht eine dokumentierte fachliche Begründung und eine Einschätzung ihrer Auswirkung auf den Upgrade-Pfad.

Wie lange sollte eine SAP Commerce Cloud Implementierung dauern?

Typisch sind 4 bis 9 Monate für eine Standard-Storefront im B2B oder B2C und 8 bis 14 Monate für komplexe mehrsprachige Implementierungen in mehreren Ländern. Die wichtigsten Treiber sind die Zahl der Integrationen, der Umfang der Anpassungen und der Zustand der zu migrierenden Daten.

Sollte ich von SAP Hybris On-Premise zu Commerce Cloud migrieren?

In den meisten Fällen ja. Die Mainstream Maintenance für SAP Commerce On-Premise endete am 31. Juli 2026; Release 2205 erhält nur noch kundenspezifische Wartung, ohne neue Support Packages, gesetzliche Änderungen oder Bibliotheks-Updates. Die Frage ist, wie und wie schnell, und ob Commerce Cloud, die ERP Edition oder ein Replatforming zu Ihrer Situation passt.

Wie viele Eigen-Extensions sind zu viele?

Eine absolute Zahl gibt es nicht, aber 10 bis 15 sind für die meisten Projekte beherrschbar. Ab 30 wächst der Upgrade-Aufwand überproportional. Ab 50 wird jedes Upgrade in der Regel zu einem mehrmonatigen Projekt. Zählen Sie Ihre Extensions regelmässig und konsolidieren Sie, wo es geht.

Kann ich Commerce Cloud für B2B und B2C auf derselben Plattform nutzen?

Ja. Commerce Cloud unterstützt mehrere Storefronts (Sites) auf einer Instanz, jede mit eigenem Katalog, eigenen Preisen, eigenem Kundenmodell und eigenem Checkout. B2B und B2C können nebeneinander bestehen, aber die Implementierung wird komplexer; planen Sie Umfang und Budget entsprechend.