Von SAP Commerce Cloud zu einem eigenen Solidus Shop wechseln

Was SAP Commerce Cloud ist, und wer herauswächst

SAP Commerce Cloud ist ernstzunehmende Unternehmenssoftware, und das will ich klar sagen, bevor ich den Rest des Artikels damit verbringe zu erklären, warum ein mittelgroßes Unternehmen sie verlassen könnte. Sie begann als Hybris, wurde nach der Übernahme 2013 zu SAP Hybris und ist heute SAP's Plattform für den anspruchsvollen Handel: eine große Java Anwendung, die Kataloge im Geschäft zwischen Unternehmen und im Geschäft mit Endkunden aus einer Installation betreibt, sehr große Produktmengen mit komplexen Regeln bewältigt und einen Shop direkt an SAP's eigenes Back Office bindet. Wenn dein Unternehmen wirklich auf SAP läuft, im echten Maßstab verkauft und das nutzt, wofür diese Plattform gebaut ist, verdient sie ihren Platz, und du solltest vermutlich bleiben. Dieser Artikel ist kein Argument, dass SAP Commerce Cloud schlechte Software wäre. Es ist das Gegenteil.

Das Unternehmen, für das ich schreibe, ist das andere. Es ist der mittelgroße Hersteller, die mittelgroße Marke oder der mittelgroße Händler, der vor Jahren bei SAP Commerce Cloud gelandet ist, oft weil der Rest der Firma ohnehin SAP betrieb und ein Implementierungspartner es empfahl, und der nun die Lizenz, die Tagessätze des Partners und die Java Komplexität einer Plattform für den anspruchsvollen Handel für einen Shop trägt, der in Wahrheit nicht in diesem Maßstab spielt. Der Checkout funktioniert. Der Katalog funktioniert. Aber jede Änderung ist ein Partnerprojekt, jedes Upgrade ist ein Partnerprojekt, und die Person, die die Rechnung unterschreibt, fragt sich allmählich, wofür das alles gut ist.

Dies ist der ehrliche Leitfaden zum Umzug von SAP Commerce Cloud auf einen eigenen Shop auf Basis von Solidus, dem quelloffenen Shop Framework für Ruby on Rails. Ich baue den neuen Shop und führe den Umzug durch. Dir gehört das Ergebnis. Ich werde konkret, wie SAP's Export und die API wirklich arbeiten, was sauber herausgegeben wird und was zurückgehalten wird und wo die harten Teile liegen. Für das tiefe Detail, wie jede Art von Daten umzieht, verlinke ich auf die Beiträge, die das sauber behandeln, statt es hier zu wiederholen. Falls du ihn noch nicht gelesen hast, ist der Einstieg der Überblick: was sich überträgt und was nicht.

Wie sie verkauft wird, und warum die Rechnung schwer zu lesen ist

Das Erste, was du über SAP Commerce Cloud verstehen solltest, ist, dass es keinen Preis gibt, den du nachschlagen kannst. SAP veröffentlicht keinen Listenpreis. Die eigene Preisseite sagt, dass die Plattform nach deinen jährlichen Bestellungen oder deinem Bruttowarenwert bepreist wird und dass die Preisstruktur und die Vertragsdetails auf Anfrage verfügbar sind.¹ In der Praxis heißt das ein Abonnement, über den SAP Vertrieb oder einen Implementierungspartner angeboten, an die Größe deines Unternehmens angepasst, meist auf eine Verpflichtung über mehrere Jahre. Zwei Firmen ähnlicher Größe können sehr unterschiedliche Summen zahlen, je nachdem, was sie wann ausgehandelt haben.

Genau diese Undurchsichtigkeit macht die Kosten so schwer zu hinterfragen. Du kannst dein Angebot mit keiner öffentlichen Zahl vergleichen, die Lizenz ist mit Hosting und Support gebündelt, und die Umsetzung und die laufende Änderungsarbeit liegen bei einem Partner auf Tagessatz. Für viele Unternehmen ist das SAP Commerce Cloud Abonnement plus der Partnervertrag der größte einzelne Grund, warum die Zahlen am Jahresanfang keinen Sinn mehr ergeben, und es ist die eine Position, die niemand in klaren Worten erklären kann.

Wenn du für SAP Commerce Cloud zahlst und nicht in einem Satz sagen kannst, was dir die Plattform gibt, das eine Rails Anwendung plus dein eigener Entwickler nicht könnte, dann ist genau diese Lücke das Erste, was du prüfen solltest. Für manche Unternehmen ist die Antwort echt und konkret, und ich komme darauf zurück. Für sehr viele ist die ehrliche Antwort, dass der Shop weit weniger tut, als die Plattform zu tun gebaut ist.

Was dir wirklich gehört, und was dich hält

Hier die gute Nachricht, und sie ist wirklich gut: deine Handelsdaten gehören dir, und sie sind herausholbar. SAP Commerce Cloud speichert ihre Daten in einer Datenbank, die durch ihr eigenes Typensystem definiert ist, und liefert zwei erstklassige Wege, Daten hinein und heraus zu bekommen, das ImpEx Framework und die Omni Commerce Connect API. Niemand kann deinen Shop abschalten und sich weigern, deinen Katalog herauszugeben. Das ist ein echter Vorteil, und es bedeutet, dass der Umzug, den ich unten beschreibe, eine Frage des Aufwands ist und nicht der Erlaubnis.

Was dich hält, sind nicht die Daten. Es ist das Gewicht des Apparats rundherum.

Eine SAP Commerce Cloud Installation ist eine große Java Anwendung mit einem Typensystem, einem Erweiterungsmodell, einer Build und Deploy Pipeline und in den meisten Fällen einer Integration in SAP's Back Office. Sie wird von Leuten betrieben, die sich genau auf diese Plattform spezialisieren, und dieser Kreis ist klein und teuer. Die Plattform ist nicht teuer, weil SAP gierig wäre. Sie ist teuer, weil sie groß ist, und große Software braucht große Pflege, geliefert von raren Spezialisten. Die Frage ist nicht, ob die Plattform leistungsfähig ist. Das ist sie offenkundig. Die Frage ist, ob dein Shop schwer genug ist, um sie zu rechtfertigen.

Das Zweite, was dich hält, ist der Partner. Weil die Plattform komplex ist, hängen die meisten SAP Commerce Cloud Shops für alles jenseits des Pflegens von Produkten von einem Implementierungspartner ab, und das Wissen, wie der Shop gebaut wurde, welche eigenen Typen definiert wurden und warum, lebt beim Partner statt bei dir. Das ist in Ordnung, solange die Beziehung gut ist. Es wird zum Problem an dem Tag, an dem die Beziehung oder der Tagessatz nicht mehr passt.

Die Daten herausholen: ImpEx und die API

Weil die Daten dir gehören, ist das Herausholen eine echte Möglichkeit statt einer Verhandlung. SAP gibt dir zwei Wege, und ein ernsthafter Umzug nutzt beide.

Der erste ist ImpEx. SAP beschreibt es als ein starkes Import und Export Werkzeug, zugeschnitten auf das SAP Commerce Typensystem, und Entwickler nutzen es, um Objekte des Typensystems über eine Textdatei im kommagetrennten Format anzulegen, zu aktualisieren und zu löschen.² Mit anderen Worten ist es SAP's eigenes Massendatenwerkzeug, es spricht ein CSV ähnliches Format, und es kann den Katalog, die Kundendatensätze und vieles mehr aus dem System lesen. Es ist das Werkzeug für den Großteil des Umzugs, und weil es rund um das Typensystem gebaut ist, gibt es dir die Daten in der Form, die das Typensystem definiert.

Der zweite Weg ist die Omni Commerce Connect API, meist OCC abgekürzt. SAP beschreibt das Modul als eines, das die Datenkommunikation über verschiedene Kanäle ermöglicht, und seine Standardfunktionen decken die Produktsuche mit Details, Bestand und Preisen, Promotions und Gutscheine, die Bestellverwaltung samt Bestellstatus, Historie und dem Aufgeben oder Stornieren von Bestellungen, Zahlungs und Lieferoptionen sowie die Benutzerverwaltung mit Profilen, Adressen und Passwortänderungen ab.³ Die zweite Version der API ist die Vorgabe, sie ist zustandslos, und SAP behandelt sie als bevorzugte Version, während eine ältere zustandsbehaftete Version nur aus Gründen der Abwärtskompatibilität bleibt. Die Sicherheit läuft über OAuth, und SAP veröffentlicht die vollständige Liste der Endpunkte über eine integrierte Swagger Oberfläche.³ Für einen Umzug ist die API der Weg, über den ich die Datensätze hole, die ImpEx unbeholfen behandelt, etwa Bestellungen mit ihrer vollständigen Statushistorie, und über den ich die Zählungen zwischen altem und neuem Shop abgleiche.

Zwei Dinge solltest du wissen, bevor du um einen der Wege herum planst. ImpEx und das Typensystem sind eng gekoppelt, also ist ein Export nur so klar wie das Typenmodell dahinter, was das Thema des nächsten Abschnitts ist. Und die OCC API ist, wie jede Produktiv API, mengenbegrenzt und seitenweise, also werden große Lesevorgänge in Stapeln statt in einem Durchgang gemacht. Keiner von beiden ist ein Hindernis für einen einmaligen Umzug. Beide sind Gründe, den Export als Ingenieursarbeit zu behandeln und nicht als Knopfdruck.

Das Typensystem, und warum das Mapping Arbeit macht

Der Grund, warum ein SAP Commerce Cloud Export aufwendiger ist, als er aussieht, liegt im Typensystem. SAP's Typensystem wirkt als Vermittler zwischen der Java Geschäftslogik und der Datenbank.⁴ Typen werden in XML definiert, in einer Datei namens items.xml, und aus diesen Definitionen erzeugt SAP die Java Klassen beim nächsten Build und die Datenbanktabellen beim nächsten System Update.⁴ Dein Katalog, deine Kunden, deine Bestellungen und jedes eigene Konzept, das dein Partner modelliert hat, leben alle als Typen in diesem System.

Dieses Design ist mächtig, und es ist der Grund, warum SAP Commerce Cloud fast jedes Geschäft abbilden kann. Der Preis dieser Macht ist, dass deine Daten keine ordentliche Tabelle sind, die an einer Stelle liegt. Sie sind über ein Typenmodell verteilt, das über Jahre von demjenigen geformt wurde, der den Shop umgesetzt hat. Welche Attribute noch genutzt werden, welche eigenen Typen für ein längst abgeschlossenes Projekt ergänzt wurden, welche Felder etwas subtil anderes meinen, als ihr Name nahelegt: all das lebt teils in den Daten und teils in den Köpfen des Partners, der es gebaut hat.

Für einen Umzug zählt das auf eine konkrete Weise. ImpEx und die API geben dir die Werte, aber du musst sie noch auf das Modell des neuen Shops abbilden, entscheiden, welche Typen und Attribute den Umzug überleben und welche nie wirklich genutzt wurden, und jene abgleichen, die sich als etwas anderes erweisen, als sie scheinen. Das ist kein Hindernis. Es ist ehrliche Arbeit, bei einem echten Katalog meist mehrere Tage sorgfältigen Abgleichs, und es ist dieselbe Art von Arbeit, die der Beitrag zu Produkt und Katalogdaten im Detail durchgeht. Setz die Erwartung jetzt: die Daten kommen heraus, und sie abzubilden ist der Teil, der Zeit kostet.

Was umzieht, was feststeckt und was neu gebaut werden muss

Was zieht also sauber um, was mit Aufwand und was muss neu gebaut werden? Das ist die Tabelle, die ich mir von mehr Plattformen wünschte.

Was	Wie es SAP Commerce Cloud verlässt	Wie schwer
Produkte, Varianten, Preise, Bilder, Kategorien, Bestand	ImpEx Export in kommagetrennte Dateien, auf das neue Modell abgebildet	Zieht mit Mapping Arbeit um
Kunden und Adressen	ImpEx Export oder über die OCC API gelesen	Zieht mit Mapping Arbeit um
Bestell und Kaufhistorie	Über die OCC API als Datensätze gelesen, als reine Lesehistorie importiert	Zieht teilweise um
Passwörter	Nur Hashes, beim ersten Login aktualisiert, nie der Klartext	Sonderbehandlung
Gespeicherte Karten und Token	Nur zwischen zertifizierten Anbietern, oft braucht es das Gateway	Am härtesten, zuerst planen
Abonnements und wiederkehrende Mandate	Hängen von der Abrechnungsintegration ab, brauchen oft deren Mithilfe	Am härtesten, zuerst planen
ERP Integration zu SAP	Gegen SAP's Integrationsschnittstellen neu gebaut	Neu gebaut, zuerst abstecken
URLs und Weiterleitungen	Von Hand von der alten auf die neue Struktur abgebildet	Zieht mit Aufwand um
Storefront, Erweiterungen, eigene Logik	Ziehen nicht um, werden als Code neu gebaut	Neu gebaut

Die Zeilen im härtesten Band sind die, die du am ersten Tag ansprichst, nicht in der letzten Woche. Auf jede komme ich gleich zurück.

Die Fallen, die typisch für SAP Commerce Cloud sind

Jede Plattform hat eigene Stellen, an denen ein Umzug hängen bleibt. Für SAP Commerce Cloud sind das die, die ich ehrlich kennzeichnen muss.

Die Storefront hat sich schon einmal geändert und wird es wieder. Jahrelang war die Standard Storefront der auf JSP basierende Accelerator. SAP hat diesen Accelerator abgekündigt und lenkt neue Projekte nun auf die Composable Storefront, eine auf Angular basierende Storefront, früher das quelloffene Projekt Spartacus, die ausschließlich über die Commerce REST API mit SAP Commerce Cloud spricht.⁵⁶ SAP enthält die Composable Storefront ohne Aufpreis in der SAP Commerce Cloud Lizenz und liefert sie mit einer vorwärts rollenden Aktualisierungspolitik aus, während Kunden im eigenen Rechenzentrum weiter den quelloffenen Spartacus Code nutzen dürfen.⁷ Der praktische Punkt für einen Umziehenden ist dieser: Wenn dein Shop auf dem alten Accelerator läuft, steht dir ohnehin schon ein Storefront Neubau innerhalb von SAP bevor. Ein Neubau kommt so oder so, und das ist ein vernünftiger Moment, um zu fragen, ob dieser Neubau überhaupt bei SAP bleiben soll.

Zahlungen und hinterlegte Karten sind das härteste Einzelteil. SAP Commerce Cloud hält nicht die Kartennummern deiner Kunden. Die Zahlung läuft über eine Gateway Integration, und die gespeicherten Karten und Token gehören diesem Zahlungsanbieter, nicht der Plattform. Also hängt es von deinem Gateway ab und nicht von einem der beiden Shops, ob deine Kundinnen ihre gespeicherten Karten behalten. Der beste Fall ist, dass dein SAP Shop bereits über einen Anbieter abrechnet, der dir gehört, etwa dein eigenes Stripe Konto, denn dann verbindet sich der neue Solidus Shop mit demselben Konto und die Token ziehen gar nicht um. Der schlechteste Fall ist ein Anbieter, der Token nur an einen anderen Inhaber mit der höchsten Stufe des Kartensicherheitsstandards herausgibt, falls er sie überhaupt herausgibt. Das ist die Frage, die du vor allem anderen klärst, und der Beitrag zu Zahlungstoken ist das Detail. Lies die versteckten Gefahren beim Wechsel von Payment Gateways, bevor du zum Plattformwechsel noch einen Gatewaywechsel hinzufügst.

Abonnements und wiederkehrende Mandate leben in einer Abrechnungsintegration. Wenn dein Shop wiederkehrend abrechnet, sitzen diese Logik und diese Mandate in einer Komponente zur Abonnementabrechnung oder in der Abofunktion eines Zahlungsanbieters, nicht in einer ordentlichen exportierbaren Tabelle. Ein aktives Mandat lässt sich oft nicht einfach exportieren und wieder einfügen und braucht vielleicht die Mithilfe des Abrechnungsanbieters, um ohne Unterbrechung der Abrechnung einer Kundin umzuziehen. Kennzeichne jedes laufende Abo früh und plane den Umschaltpunkt um die Abrechnungstermine herum. Der Beitrag zu Abonnements ist der, den du ganz lesen solltest, wenn das auf dich zutrifft.

Die tiefe SAP Integration ist die eigentliche Frage, nicht die Daten. Das ist die Falle, die wirklich typisch für SAP ist, und ich will dabei fair sein. SAP Commerce Cloud ist gebaut, um sich mit SAP's Back Office zu verbinden. Unternehmen betreiben Flüsse in Echtzeit für Produkt, Preis, Bestand und Auftragsabwicklung zwischen dem Shop und einem SAP ERP System wie S/4HANA, aufgebaut auf SAP's eigener Integrationswerkzeugkette und vorgefertigten Integrationspaketen.⁸ Wenn diese Integration echte Arbeit leistet, heißt den Shop zu ersetzen, diese Flüsse gegen SAP's Schnittstellen neu zu bauen, und das ist richtige Ingenieursarbeit, kein Nachmittag. Für ein Unternehmen, das mit S/4HANA lebt und atmet, ist die native Integration ein echter Vorteil und ein echter Grund zu bleiben. Für sehr viele mittelgroße Shops stellt sich die ERP Verbindung aber als ein nächtlicher Export und eine Handvoll Felder heraus, mit denen eine Rails Anwendung bestens reden kann, oft für weit weniger als die SAP Lizenz, die sie ersetzt. Steck das ehrlich ab, bevor du irgendetwas entscheidest: es ist das Scharnier, um das sich die ganze Entscheidung dreht.

Die URL Struktur ist deine, und du bewahrst sie. Deine SAP Storefront hat eine URL Struktur, und Jahre an Links und Rankings hängen daran. Jede dieser Adressen muss mit einer dauerhaften Weiterleitung auf ihren neuen Ort abgebildet werden, sonst trifft der Verkehr, der dich gestern fand, morgen auf eine tote Seite. Auf den Shops, die ich baue, leben die Weiterleitungen in der Anwendung selbst, in einer Tabelle, die das eigene Personal des Shops bearbeiten kann, sodass sie jedes künftige Deploy überleben. Die Mechanik steht im Beitrag zu Produkt und Katalogdaten, denn die Weiterleitungskarte und der Produktumzug sind dieselbe Übung.

Ein Beispiel aus Graz

Lass es mich mit einem erfundenen Unternehmen greifbar machen, denn echte Kundengeschichten sind nicht meine, sie zu erzählen.

Murtal Licht (murtallicht.example) ist ein Grazer Hersteller von Gewerbe und Architekturbeleuchtung und verkauft an Elektrogroßhändler und Planer auf Gewerbekonten sowie über eine kleinere Konsumentenlinie an Private. Der Shop setzt online rund neun Millionen Euro im Jahr um, führt einen Katalog von etwa 18.000 Produkten mit starker Nutzung eigener Attribute für Lichtstrom, Fassung, Dimmung und Konformität und ist seit sieben Jahren auf SAP Commerce Cloud, gewählt, als die Gruppe ihre Finanzen und Fertigung auf SAP brachte. Die Gewerbekunden haben ausgehandelte Preislisten und zahlen auf monatliche Rechnung. Der Shop funktioniert. Was aufhörte zu funktionieren, war die Rechnerei: das SAP Commerce Cloud Abonnement, der Vertrag des Implementierungspartners für Änderungen und Upgrades und die rare Spezialistenzeit kosteten zusammen jedes Jahr mehr als mehrere Vollzeitkräfte, und die Geschäftsführerin konnte nicht sagen, was die Plattform kaufte, das das Unternehmen tatsächlich nutzte.

Wenn ich so einen Umzug plane, dreht sich die erste Woche nicht um Produkte. Sie dreht sich um die harten Zeilen in der Tabelle. Murtal Licht rechnet über das eigene Zahlungskonto ab, also bleiben die gespeicherten Karten, wo sie sind: der neue Solidus Shop verbindet sich mit demselben Konto, und kein Token zieht um. Es gibt keine Konsumentenabos, womit dieser harte Fall entfällt. Die eigentliche Frage ist die SAP Integration, also wird in Woche eins genau gelesen, was zwischen dem Shop und dem SAP Back Office läuft. Es stellt sich heraus als Produkt und Preisdaten, die planmäßig aus SAP fließen, Bestände und fertige Bestellungen, die zur Abwicklung und Fakturierung zurückfließen. Das ist ein klar umrissener Satz von Schnittstellen, kein Gewirr, und er lässt sich als getestete Integration aus der Rails Anwendung gegen SAP's eigene Endpunkte neu bauen. Das in Woche eins zu klären macht den Rest des Projekts ruhig.

Der Katalog ist die eigentliche Mühe. Der ImpEx Export kommt als kommagetrennte Dateien heraus, geformt vom Typensystem, und die Mapping Arbeit besteht darin zu entscheiden, welche der vielen eigenen Attribute noch genutzt werden, Jahre an Fastdubletten zusammenzuführen und die Gewerbepreislisten auf das neue Modell abzugleichen. Die Kundendatensätze kommen mit derselben Sorgfalt herüber, und ihre Passwort Hashes ziehen mit, um beim ersten Login aktualisiert zu werden, sodass niemand zum Zurücksetzen gezwungen wird, der Weg, den der Beitrag zu Kundenkonten beschreibt. Die Bestellhistorie kommt über die OCC API als reine Lesedatensätze, sodass Kundenservice und Kundinnen die Vergangenheit weiter nachsehen können, während Gutschriften und Retouren auf wirklich alten Bestellungen für ein kurzes Übergabefenster beim alten System bleiben, die Form, die der Beitrag zur Bestellhistorie beschreibt. Die 18.000 alten URLs werden zu einer Weiterleitungskarte, die jemand von Murtal Licht prüft, denn nur dort weiß man, welche Seiten ihren Verkehr noch verdienen. Auf der anderen Seite werden die Gewerbepreislisten, die monatliche Rechnung und die SAP Integration, die Aufgabe einer Plattform für den anspruchsvollen Handel waren, zu gewöhnlichen getesteten Funktionen einer Rails Anwendung, und das Abonnement und der Partnervertrag verschwinden für immer aus dem Budget.

Der Umzug ist nicht gratis und nicht sofort. Aber ein Jahr später zahlt Murtal Licht für Hosting, die eigene Entwicklung und eine klar umrissene SAP Integration, und sonst nichts, und der Shop gehört ihm ganz.

Der ehrliche Umzug auf Solidus

Die Form eines SAP Commerce Cloud Umzugs ist jedes Mal dieselbe, und die Reihenfolge zählt.

Ich beginne mit den Fragen, die ein Projekt versenken können: wo liegen die gespeicherten Karten und Token und ziehen sie um, gibt es aktive Abonnements und wovon hängen sie ab, was trägt die SAP Integration tatsächlich und lässt sie sich im passenden Umfang neu bauen, und wer auf deiner Seite besitzt die Daten und kann sagen, was ein eigener Typ bedeutet. Klär die zuerst, denn spät entdeckt sind sie teuer. Dann kommen Katalog und Kunden über ImpEx und die API herüber, auf das Solidus Modell abgebildet mit dem Abgleich, den das Typensystem verlangt. Die Bestellhistorie folgt als reine Lesedatensätze. Die URL Karte wird gebaut und von jemandem geprüft, der den Shop kennt. Die Storefront, der Checkout und jede Integration, die SAP Verbindung eingeschlossen, werden als getesteter Rails Code neu gebaut. Alt und neu laufen ein paar Wochen parallel mit eingefrorenem Katalog, der finale Import wird geprobt, bis er langweilig ist, und die Umschaltung geschieht an einem ruhigen Werktagvormittag, wobei der alte Shop dreißig Tage unangetastet als Rückfallebene bleibt.

Das Ergebnis ist ein passend dimensionierter Shop. Wo SAP Commerce Cloud dir eine Plattform für den anspruchsvollen Handel und ein an deinen Umsatz angepasstes Abonnement gab, gibt dir Solidus eine Rails Anwendung ohne Lizenzgebühr, ohne vom Anbieter aufgezwungenen Upgrade Takt und mit einer Hostingrechnung, die zu einem Shop passt statt zu einer Plattform für die größten Konzerne der Welt. Die Anpassung, die ein Partnerprojekt war, wird zu Anwendungscode, der dir gehört, und der maßgefertigte Code, den ich schreibe, wird deiner, sobald er voll bezahlt ist. Für die Einordnung der Plattformen zueinander und das volle Geldbild über fünf Jahre lies den Plattformvergleich und die Gesamtkosten über fünf Jahre. SAP Commerce Cloud ist die andere Plattform für den anspruchsvollen Handel neben Salesforce Commerce Cloud, und vieles, was für die eine gilt, gilt auch für die andere.

Wann du bleiben solltest

Ich verliere die Arbeit lieber, als einen Shop umzuziehen, der bleiben sollte, also hier, wann du auf SAP Commerce Cloud bleibst.

Bleib, wenn dein Unternehmen wirklich auf SAP läuft und die native Integration in S/4HANA oder ein anderes SAP Back Office echte, schwere Arbeit in Echtzeit leistet, deren Neubau teuer und deren Verlust riskant wäre. Bleib, wenn du im echten anspruchsvollen Maßstab verkaufst, über viele Märkte und Marken aus einer Plattform, mit einem internen Team oder einem Partner, dem du vertraust. Bleib, wenn das Abonnement und die Partnerkosten im Verhältnis zu dem stehen, was die Plattform für dich tut, und du klar sagen kannst, was das ist. In diesen Fällen tut SAP Commerce Cloud ihren Dienst, und ein Umzug tauschte ein funktionierendes System für den anspruchsvollen Handel gegen ein kleineres, das du dann selbst bauen und betreiben musst.

Der Shop, der umziehen sollte, ist der, der ein Abonnement und Partnersätze für den anspruchsvollen Handel zahlt, obwohl er nicht in diesem Maßstab spielt, wo die Lizenz, die Spezialisten und die Komplexität mehr kosten als das Geschäft, das die Plattform trägt, und wo die ERP Integration, ehrlich betrachtet, eine Handvoll Felder ist und nicht das schlagende Herz des Betriebs. Wenn das auf dich zutrifft, sagt das Geld meist: zieh um, und der Beitrag zu den Gesamtkosten zeigt dir, um wie viel.

Was das für dich bedeutet

SAP Commerce Cloud zu verlassen ist keine Flucht aus einer Plattform, die dich eingesperrt hätte. Deine Daten gehören dir, sie kommen über ImpEx und die OCC API heraus, und die Tür ist offen. Es ist die Entscheidung, aufzuhören, für eine Plattform für den anspruchsvollen Handel zu zahlen, aus der du herausgewachsen bist oder in die du nie hineingewachsen bist, und einen Shop zu betreiben, der passt. Der Katalog braucht wegen des Typensystems echte Mapping Arbeit. Die Zahlungen, etwaige Abonnements und die SAP Integration sind die harten Teile, und sie werden zuerst geklärt. Alles andere ist ein gut verstandenes Projekt mit klarer Reihenfolge.

Wenn du nutzt, wofür SAP Commerce Cloud gebaut ist, behalt es. Wenn du für weit mehr Plattform zahlst, als du brauchst, und deine Daten ohnehin dir gehören, ist ein eigener Solidus Shop meist die richtige Größe. Wer überhaupt die Schlüssel zu diesen Daten hält, ist auf jeder Plattform eine klare Frage wert, und das ist das Thema von wem deine Geschäftsdaten gehören.

Wenn du eine klare Antwort auf deine eigenen Zahlen willst, bring sie in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Ich stelle dein Abonnement, deinen Partner und deine Integrationszahlen einem Solidus Bau gegenüber, kennzeichne die Zahlungs, Abo und SAP Integrationsfragen vor allem anderen und sage dir ehrlich, ob sich der Umzug für dich lohnt. Manchmal tut er das nicht, und dann sage ich es.

Footnotes

1. SAP, SAP Commerce Cloud Preise (bepreist nach jährlichen Bestellungen oder Bruttowarenwert, Preisstruktur und Vertragsdetails auf Anfrage, kein veröffentlichter Listenpreis), abgerufen am 14. November 2026, https://www.sap.com/products/crm/commerce-cloud/pricing.html ↩

2. SAP Learning, Getting an Overview of ImpEx (ein starkes Import und Export Werkzeug, zugeschnitten auf das SAP Commerce Typensystem, um Objekte des Typensystems aus einer Textdatei im kommagetrennten Format anzulegen, zu aktualisieren und zu löschen), abgerufen am 14. November 2026, https://learning.sap.com/courses/exploring-the-technical-essentials-of-sap-commerce-cloud/impex-overview_aaae24a6-83e4-4ec5-8ff8-9149e361f9a5 ↩

3. SAP Learning, Introducing the Omni Commerce Connect Module (OCC ermöglicht Datenkommunikation über Kanäle, mit Produktsuche, Promotions und Gutscheinen, Bestellverwaltung, Zahlungs und Lieferoptionen und Benutzerverwaltung; Version zwei ist die zustandslose bevorzugte Vorgabe, mit OAuth gesichert und über Swagger dokumentiert), abgerufen am 14. November 2026, https://learning.sap.com/courses/mastering-the-technical-essentials-of-sap-commerce-cloud/omni-commerce-connect-restful-web-services_a60bebeb-75bc-4a6d-972b-96c17363b909 ↩ ↩²

4. SAP Learning, Introducing the Type System (das Typensystem wirkt als Vermittler zwischen Java Geschäftslogik und Datenbank; die XML Definitionen in items.xml erzeugen die Java Klassen beim nächsten Build und die Datenbanktabellen beim nächsten System Update), abgerufen am 14. November 2026, https://learning.sap.com/courses/exploring-the-technical-essentials-of-sap-commerce-cloud/introducing-the-type-system_ab582bd7-f30e-4351-850f-70d341d569fa ↩ ↩²

5. SAP, Spartacus Repository (eine schlanke, auf Angular basierende JavaScript Storefront für SAP Commerce Cloud, die ausschließlich über die Commerce REST API mit SAP Commerce Cloud spricht), GitHub, abgerufen am 14. November 2026, https://github.com/SAP/spartacus ↩

6. SAP Knowledge Base Article 3263872, Accelerator Storefront Deprecation FAQ (die auf JSP basierende Accelerator Storefront ist abgekündigt, mit der Composable Storefront als empfohlenem Weg), abgerufen am 14. November 2026, https://userapps.support.sap.com/sap/support/knowledge/en/3263872 ↩

7. SAP, Composable storefront Dokumentation (auf dem quelloffenen Spartacus Code basierend, ohne Aufpreis in der SAP Commerce Cloud Lizenz enthalten, mit einer vorwärts rollenden Aktualisierungspolitik; Kunden im eigenen Rechenzentrum dürfen weiter Spartacus Open Source nutzen), abgerufen am 14. November 2026, https://sap.github.io/spartacus-docs/ ↩

8. SAP Learning, Implement an Integration of SAP S/4HANA Cloud with SAP Commerce Cloud (SAP Integration Suite verbindet Commerce Cloud mit dem S/4HANA Back Office über vorgefertigte Integrationspakete für Flüsse wie die Auftragsabwicklung), abgerufen am 14. November 2026, https://learning.sap.com/learning-journeys/implement-an-integration-of-sap-s-4hana-cloud-with-sap-commerce-cloud ↩