Von Salesforce Commerce Cloud zu einem eigenen Shop wechseln

Was Salesforce Commerce Cloud ist und für wen es passt

Salesforce B2C Commerce, immer noch Commerce Cloud genannt und jahrelang als Demandware bekannt, ist eine Ecommerce Plattform für Großunternehmen, ausgeliefert als Software as a Service. Salesforce hat Demandware 2016 für rund 2,8 Milliarden US Dollar gekauft und in seine Cloud eingegliedert.¹ Du hostest nichts, patchst nichts und betreibst keine Server. Das macht Salesforce, in vielen Rechenzentren, und die Plattform ist gebaut, um sehr große Kataloge, viele Storefronts, mehrere Marken und mehrere Regionen aus einem Ort heraus zu tragen. Für einen Händler in dieser Größe, mit einem großen internen Team und einer Agentur auf Abruf, ist das eine leistungsfähige Plattform, und sie verdient ihr Geld.

Ich baue eigene Shops auf Solidus, dem quelloffenen Ecommerce Framework auf Rails, damit du weißt, wo ich stehe, bevor ich ein Wort gegen die Plattform sage. Genau deshalb will ich fair bleiben. Wenn du ein echtes Großunternehmen bist, das Commerce über mehrere Marken und Regionen in großem Maßstab braucht, mit den Leuten und dem Budget, um das zu betreiben, kann Salesforce der richtige Ort sein, und dieser Artikel will dich nicht davon wegreden. Die Ehrlichkeit ist der Punkt: Ich verliere die Arbeit lieber, als ein Unternehmen umzuziehen, das bleiben sollte.

Dieser Leitfaden ist für einen anderen Shop. Er ist für das mittelgroße Unternehmen, das auf Salesforce Commerce Cloud gesetzt wurde, oft von einem Systemintegrator, der die Plattform kannte, und das jetzt Enterprise Geld zahlt und mit Enterprise Komplexität lebt, die es nie gebraucht hat. Wenn die Rechnung jedes Jahr schneller wächst als das Team und niemand im Haus den Checkout ändern kann, ohne bei einer Agentur ein Ticket aufzumachen, dann ist das hier für dich.

Wer herauswächst und wer bleiben sollte

Das klarste Signal ist die Rechnung. Salesforce verrechnet B2C Commerce als Jahresvertrag, und die öffentliche Preisseite führt die Editionen Growth, Plus und Premium jährlich abgerechnet und mit Preisen nur auf Anfrage.² Es gibt keine veröffentlichte Preisliste, und ich erfinde keine. Was für diese Entscheidung zählt, ist die Form des Modells, nicht eine Zahl: Der Vertrag bemisst sich am Volumen der Umsätze, die über die Plattform laufen, also je mehr du verkaufst, desto mehr zahlst du. Wachstum wird besteuert. Ein gutes Jahr im Shop ist eine größere Rechnung von der Plattform, egal ob die Plattform dafür etwas Neues getan hat.

Für ein echtes Großunternehmen ist das ein vertretbarer Tausch. Die Plattform nimmt dir reale Kosten und reales Risiko ab, und ein Anteil an einer sehr großen Zahl kann gegenüber dem Eigenbetrieb immer noch gut sein. Für einen Shop mit ein paar Millionen Umsatz im Jahr und einem gewöhnlichen Katalog ist es das oft nicht. Du zahlst den Enterprise Anteil und nutzt einen Bruchteil der Enterprise Fähigkeiten.

Hier also der ehrliche Test. Bleib auf Salesforce, wenn du mehrere Marken oder mehrere Regionen betreibst, die wirklich eine Commerce Engine teilen, wenn du ein internes Commerce Team hast und wenn der Maßstab und der Support der Plattform dir Arbeit abnehmen, die du anders nicht leicht erledigst. Schau dir das Wechseln genau an, wenn du eine Marke in einem oder zwei Märkten bist, wenn die Agentur alle Schlüssel hat, wenn deine eigentliche Klage ist, dass der Shop teuer und geschlossen ist, und wenn die Funktionen, die du tatsächlich nutzt, in einen Shop passen würden, der dir selbst gehört.

Was dir gehört und was die Plattform behält

Das Erste, was vor jedem Umzug geklärt gehört, ist, was du mitnehmen darfst. Bei Salesforce teilt sich die Antwort sauber in zwei Hälften, und es ist nicht die Teilung, die die meisten erwarten.

Deine Geschäftsdaten gehören dir. Der Katalog, die Kundendaten und die Bestellhistorie lassen sich alle exportieren, und wie genau, dazu komme ich gleich. Nicht mitnehmbar ist fast alles, was den Shop laufen lässt: der Storefront Code, der Checkout, das Hosting, die Integrationen und, in der Praxis, die tägliche Kontrolle. Die Storefront wird aus Cartridges in einer proprietären Architektur gebaut, der Checkout ist der der Plattform, die Server sind die von Salesforce, und die Schlüssel zum Admin hat sehr oft dein Systemintegrator, nicht du. Dir gehört der Inhalt des Hauses. Das Haus mietest du, und jemand anderer hat den einzigen Schlüssel.

Was sauber umzieht	Was Mappingarbeit braucht	Was an die Plattform gebunden ist
Katalog: Produkte, Varianten, Kategorien, Preise, Bilder	Bestellhistorie, auf das neue Datenmodell gemappt	Die Storefront Cartridges und ISML Vorlagen
Kundendaten und Adressen	Aktionen und Gutscheinlogik, besser neu gebaut	Der Checkout und das Hosting
Content und statische Seiten	Weiterleitungstabelle von alten auf neue URLs	Gespeicherte Karten und Token beim Zahlungsdienstleister
Lagerbestand und Preislisten	Kundenpasswörter, die nie im Klartext exportieren	Die Plattform selbst und die Umsatzbeteiligung

Die mittlere und die rechte Spalte sind dort, wo die ehrliche Arbeit und die ehrlichen Grenzen liegen. Passwörter liegen gehasht vor und lassen sich nicht als nutzbare Passwörter mitnehmen, was auf jede ernsthafte Plattform zutrifft und im Überblicksartikel dazu, was sich überträgt und was nicht, ausführlich steht. Gespeicherte Karten gehören dem Zahlungsdienstleister, nicht Salesforce, und ob sie überhaupt mitkommen, hängt am Dienstleister, nicht am Shop.

Der Export und die API, und was sie wirklich hergeben

Salesforce gibt dir drei ehrliche Wege zu deinen eigenen Daten, und jeder hat Grenzen, die du kennen solltest, bevor du darum herum planst.

Der erste ist der Business Manager, der Admin der Plattform. Er kann eine Site als XML Archive importieren und exportieren, gebaut gegen veröffentlichte Schemata für Katalog, Kunden und Bestellungen, wobei Gutscheincodes die seltsame Ausnahme sind und als CSV herauskommen.³ Ein Site Export ist ein vollständiger Snapshot von Konfiguration und Daten, der sich auf dieselbe oder eine andere Instanz zurückspielen lässt, und so bewegen Agenturen einen Shop zwischen Sandboxes. Importe laufen in einem gewählten Modus wie Merge, der Business Manager analysiert die Datei, bevor er sie übernimmt, und, wichtig, ein Bestellimport aktualisiert keine bestehenden Bestellungen, die Historie ist also ein einseitiges Lesen der Vergangenheit, keine lebende Synchronisation.⁴ Für eine Migration ist das in Ordnung: Du willst eine treue Kopie der Vergangenheit, keine Brücke in beide Richtungen.

Der zweite Weg ist die API, und hier ist Salesforce mitten im Übergang. Die ältere Open Commerce API, OCAPI, hat eine Data API, die Kataloge, Kunden und Bestellungen genau für diese Art von Extraktion bereitstellt.⁵ Seit April 2026 ist OCAPI als veraltet markiert: Salesforce empfiehlt für alle neuen Arbeiten die neuere Salesforce Commerce API, SCAPI.⁶ Veraltet heißt nicht abgeschaltet. Die Versionsrichtlinie setzt kein Enddatum, sagt mindestens zwei Jahre Vorlauf vor einer Abschaltung zu und versorgt OCAPI weiter mit Sicherheits und Fehlerkorrekturen, nur ohne neue Funktionen.⁷ Für einen einmaligen Export ist diese Stabilität auf deiner Seite. Wenn du etwas Langlebiges gegen die Plattform baust, bau es auf SCAPI.

Das dritte, das du einplanen musst, ist die Drosselung. Die Storefront APIs sitzen hinter Load Shedding und Ratenlimits, und wenn du zu stark drückst, antwortet die Plattform mit einem HTTP 429 und einem Retry-After Header statt mit mehr Daten.⁸ Dazu erzwingt B2C Commerce Governance Quotas für API Aufrufe und dafür, wie lange serverseitige Skripte laufen dürfen.⁹ Nichts davon blockiert eine Migration, aber es heißt, dass ein Massenabzug eines großen Katalogs und mehrerer Jahre Bestellungen in Etappen laufen muss, gebündelt und höflich wiederholt, nicht in einer einzigen Schleife abgefeuert. Ich plane Exporte so, dass sie über Nacht laufen, in Seiten, mit eingebautem Back off.

Ein praktischer Punkt liegt unter allen drei Wegen: Vielleicht kannst du nichts davon selbst machen. Bei den meisten Salesforce Shops hat der Integrator den Zugang zum Business Manager und die API Zugangsdaten. Teil des Weggehens ist, die eigenen Daten herauszubekommen, und das kann heißen, die Partei, die du verlässt, um die Schlüssel zu bitten oder den finalen Export für dich laufen zu lassen. Stell diese Bitte früh und schriftlich, denn so etwas bewegt sich langsam.

Die Fallen, die beim Wachsen zubeißen

Jede Plattform hat ein paar Fallen, die erst auffallen, wenn du schon gebunden bist. Bei Salesforce sind das die, vor denen ich warnen würde, bevor du etwas unterschreibst, und die am stärksten dafür sprechen, deinen Shop stattdessen selbst zu besitzen.

Die Umsatzbeteiligung ist die erste und schwerste. Weil der Vertrag mit dem Umsatz skaliert, nimmt die Plattform von einem größeren Unternehmen einen größeren Anteil, und zwar unabhängig davon, ob deine Margen mit dem Umsatz gewachsen sind. Ein guter Black Friday ist auch für Salesforce ein guter Black Friday. Bei einem eigenen Shop sind die Plattformkosten in etwa flach: Hosting und Wartung schert es nicht, ob du vier Millionen oder neun umgesetzt hast. Der ganze Sinn des Umzugs ist, aufzuhören, einen Anteil am eigenen Erfolg zu zahlen.

Die zweite wird am meisten unterschätzt: Du hast die Schlüssel selten selbst. Das Modell aus Cartridges und Integrator führt dazu, dass das Wissen, wie dein Shop funktioniert, bei einer Agentur liegt, und der Admin Zugang auch. Das ist bequem, solange die Beziehung gut ist, und teuer, wenn nicht. Bevor du sonst etwas tust, finde heraus, wer sich als Administrator im Business Manager anmelden kann, und ob das du bist.

Die dritte ist die Bindung an die Storefront. Salesforce Storefronts bauen auf der Storefront Reference Architecture, SFRA, als Stapel von Cartridges über einer Basis Cartridge, die du laut Vorgabe nie direkt bearbeiten sollst.¹⁰ Die Vorlagen sind in ISML geschrieben, einer proprietären Erweiterung von HTML, die es nur auf dieser Plattform gibt, und eine funktionierende Storefront braucht mindestens eine eigene Cartridge.¹¹ Nichts von diesem Code kommt mit, wenn du gehst. Das Design lässt sich neu bauen, aber es muss neu gebaut werden, und niemand soll so tun, als würde das Frontend mit umziehen.

Die vierte ist die Zahlung, und sie gehört zuerst markiert, weil sie am schwersten ist. Gespeicherte Karten und Token liegen beim Zahlungsdienstleister, der im Checkout verdrahtet ist, nicht im Salesforce Site Archiv. Ob die gespeicherte Karte eines Kunden mitkommt, hängt ganz am Dienstleister und seiner Zertifizierung, und manchmal ist die ehrliche Antwort, dass Kunden ihre Karten neu eingeben. Das ist ein eigenes Thema, und der Spoke zu Zahlungstoken und gespeicherten Karten behandelt es sauber. Entscheide die Zahlungsfrage, bevor du das Migrationsdatum entscheidest.

Die fünfte ist leiser, kostet aber echtes Geld: URLs und Suchrankings. Deine Salesforce Storefront hat eine URL Struktur, und manche dieser Adressen tragen jahrelange Links und Rankings. Zieh den Shop ohne vollständige Weiterleitungstabelle um, und du wirfst das am Umschalttag weg. Jede alte URL braucht eine dauerhafte Weiterleitung auf ihr neues Zuhause, eine Mappingarbeit, die ich als Teil der Produkt und Katalogmigration behandle, weil in den Produkt und Kategorieseiten der meiste Wert steckt.

Der ehrliche Umzug auf einen eigenen Solidus Shop

Ein Umzug von Salesforce auf einen eigenen Solidus Shop ist kein Knopfdruck, und ich tue nicht so. Es ist ein Bau und eine Datenmigration, parallel geführt, und er lohnt sich, wenn der Shop, den du am Ende besitzt, das tut, was du brauchst, zu flachen statt steigenden Kosten.

Die Daten selbst folgen den Wegen, die der Rest dieser Serie schon im Detail beschreibt, also verlinke ich lieber, als zu wiederholen. Kundenkonten und Adressen kommen als Datensätze mit, Passwörter werden zurückgesetzt statt mitgenommen, so wie es der Spoke zu Kundenkonten und Adressen beschreibt. Der Katalog, der Teil, der am saubersten umzieht, folgt dem Leitfaden zu Produkt und Katalogdaten. Die Bestellhistorie kommt als schreibgeschützte Aufzeichnung der Vergangenheit mit, genug für den Kundenservice und dafür, dass ein Kunde sieht, was er gekauft hat, wie es der Spoke zur Bestell und Kaufhistorie festhält. Zahlungen und gespeicherte Karten sind der schwere Teil, zuerst entschieden, gemäß dem Spoke zu Zahlungstoken.

Was du auf der anderen Seite gewinnst, ist Eigentum im schlichten Sinn. Solidus ist eine Rails Anwendung unter einer quelloffenen Lizenz, es gibt also keine Plattformgebühr, keine Umsatzbeteiligung und keine Edition, die dir deinen eigenen Checkout freischaltet. Die Storefront, der Checkout und die Geschäftslogik sind gewöhnlicher Anwendungscode, den dein Entwickler lesen und ändern kann, und der Shop läuft auf einem Hosting, das du wählst. Wenn du das längere Argument willst, warum dieses Eigentum zählt und wer auf einer gehosteten Plattform wirklich deine Daten hält, führt es wem deine Geschäftsdaten eigentlich gehören aus. Wie die Zahlen über die Zeit stehen, rechnet die Gesamtkostenbetrachtung über fünf Jahre durch, und der breitere Plattformvergleich stellt Salesforce neben die anderen.

Ein durchgerechnetes Beispiel

Ich mache es an einem erfundenen Unternehmen konkret, weil ein echtes Beispiel klarer ist als eine Liste von Grundsätzen.

Auwald ist eine Naturkosmetikmarke in Linz, die direkt an Konsumenten in Österreich und nach Deutschland verkauft. Sie wurde vor vier Jahren von einem Integrator auf Salesforce Commerce Cloud gesetzt, als man den Gründerinnen sagte, sie bräuchten eine Enterprise Plattform, um vor dem Handel glaubwürdig zu wirken. Der Shop hat sich gut entwickelt: Der Onlineumsatz ist von etwa 4 Millionen auf etwa 9 Millionen Euro gewachsen. Genau dieses Wachstum ist das Problem. Weil der Plattformvertrag mit dem Umsatz skaliert, ist die Rechnung mit dem Umsatz gewachsen, und die jährlichen Plattformkosten verschlingen jetzt ein Stück Marge, das die Gründerinnen lieber in Produkt und Leute stecken würden. Sie betreiben eine Storefront, in zwei Sprachen, mit einem recht gewöhnlichen Katalog und keiner zweiten Marke in Sicht. Sie zahlen für eine Engine, die zwanzig Marken tragen soll, und fahren eine.

Wenn ich mir einen Shop wie Auwald ansehe, sind die ersten Fragen nicht die nach dem Design. Es sind die harten. Wer hält die Schlüssel zum Business Manager, die Gründerinnen oder die Agentur? Welcher Zahlungsdienstleister steckt im Checkout, und bewegt er gespeicherte Karten in einen neuen Shop oder nicht? Laufen Abos oder wiederkehrende Abbuchungen, denn die sind das Schwerste beim Umziehen und müssen gemappt sein, bevor ein Datum steht. Erst wenn diese Antworten da sind, folgt der Rest: ein Solidus Bau mit dem echten Design der Marke, der Katalog über die Data API und das Site Archiv exportiert, Kunden und Bestellhistorie migriert wie die Spokes es beschreiben, eine vollständige Weiterleitungstabelle von den alten URLs und ein geprobter Umschalttag im ruhigen Monat nach dem Weihnachtsgeschäft.

Der ehrliche Pitch an Auwald ist nicht, dass Solidus größer wäre als Salesforce. Das ist es offensichtlich nicht. Er ist, dass sie einen Shop besitzen würden, der das tut, was sie tatsächlich nutzen, zu Kosten, die nicht weiter steigen, bloß weil sie ein gutes Jahr hatten.

Wann Bleiben die richtige Entscheidung ist

Ich täte dir einen schlechten Dienst, wenn ich nur in eine Richtung argumentierte. Es gibt Shops, denen ich raten würde, genau dort zu bleiben, wo sie sind.

Wenn du wirklich mehrere Marken oder mehrere Regionen auf einer Commerce Engine fährst und das abzuschalten hieße, alles neu zu bauen und dann selbst zu betreiben, leistet die Plattform echte Arbeit für dich. Wenn du ein internes Commerce Team hast, das jeden Tag in den Werkzeugen lebt, ist die Komplexität keine Steuer, sondern Fähigkeit, die du nutzt. Wenn deine Bestellmengen groß genug sind, dass der Maßstab und der Support von Salesforce mehr wert sind als der Anteil, den du zahlst, kann die Rechnung fürs Bleiben sprechen. Und wenn die Umsatzbeteiligung für deine Zahlen weniger ausmacht als ein eigener Bau plus ein fähiges Team im Betrieb kosten würde, dann würde ein Umzug dich Geld kosten, und das sage ich dir.

Die Frage ist nie, ob Salesforce eine gute Plattform ist. Es ist eine gute Plattform. Die Frage ist, ob du das Unternehmen bist, für das sie bepreist wurde.

Wenn die Rechnung keinen Sinn mehr ergibt

Wenn die Plattformrechnung angefangen hat, schneller zu wachsen als der Shop, und du deinen eigenen Checkout nicht ändern kannst, ohne ein Ticket aufzumachen, lohnt es sich zumindest, echte Zahlen neben die Alternative zu legen. Bring deinen Vertrag, die Plattformkosten des letzten Jahres und dein Zahlungssetup in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Ich sage dir ehrlich, ob sich ein Umzug für deinen Shop auszahlt oder ob du dort, wo du bist, besser aufgehoben bist. Manchmal ist die Antwort zu bleiben, und das sage ich auch.

Footnotes

1. eWeek, Salesforce Moves into E Commerce with Demandware Buy (Übernahme von Demandware für rund 2,8 Milliarden US Dollar, 2016), https://www.eweek.com/cloud/salesforce-moves-into-e-commerce-with-demandware-buy/ ↩

2. Salesforce, B2C Commerce pricing (Editionen Growth, Plus und Premium, jährlich abgerechnet, Preise auf Anfrage), abgerufen am 14. November 2026, https://www.salesforce.com/products/b2c-commerce-pricing/ ↩

3. Salesforce Trailhead, Business Manager Import and Export (Site Import und Export als XML Snapshots gegen veröffentlichte Schemata für Katalog, Kunden und Bestellungen, Gutscheincodes als CSV, auf eine andere Instanz rückspielbar), abgerufen am 14. November 2026, https://trailhead.salesforce.com/content/learn/modules/b2c-import-export/b2c-business-manager-import-export ↩

4. Salesforce Trailhead, Configure Import and Export (Importanalyse und Merge Modus, ein Bestellimport aktualisiert keine bestehenden Bestellungen), abgerufen am 14. November 2026, https://trailhead.salesforce.com/content/learn/modules/b2c-import-export/b2c-configure-import-export ↩

5. Salesforce Developers, B2C Commerce OCAPI Data API (Datenressourcen für Kataloge, Kunden und Bestellungen), abgerufen am 14. November 2026, https://developer.salesforce.com/docs/commerce/b2c-commerce/references/ocapi-data-api ↩

6. Salesforce Developers, The Advantages of SCAPI (OCAPI seit April 2026 als veraltet markiert, SCAPI für neue Projekte empfohlen), abgerufen am 14. November 2026, https://developer.salesforce.com/docs/commerce/commerce-api/guide/why-use-scapi.html ↩

7. Salesforce Developers, OCAPI Versioning and Deprecation Policy (kein Enddatum gesetzt, mindestens zwei Jahre Vorlauf vor einer Abschaltung, nach der Markierung nur Sicherheits und Fehlerkorrekturen), abgerufen am 14. November 2026, https://developer.salesforce.com/docs/commerce/b2c-commerce/references/b2c-commerce-ocapi/versioninganddeprecationpolicy.html ↩

8. Salesforce Developers, Load Shedding and Rate Limiting (HTTP 429 mit Retry-After Header, wenn ein Ratenlimit erreicht ist), abgerufen am 14. November 2026, https://developer.salesforce.com/docs/commerce/commerce-api/guide/throttle-rates.html ↩

9. Salesforce Developers, Governance and Quotas (Quotas für API Aufrufe, Ressourcenverbrauch und Skriptausführung), abgerufen am 14. November 2026, https://developer.salesforce.com/docs/commerce/commerce-solutions/guide/b2c-governance-and-quotas.html ↩

10. Salesforce Developers, SFRA Features and Components (Cartridge Stapel über einer Basis Cartridge, die nicht direkt bearbeitet werden soll), abgerufen am 14. November 2026, https://developer.salesforce.com/docs/commerce/sfra/guide/b2c-sfra-features-and-comps.html ↩

11. Salesforce Trailhead, Reference Architecture and Cartridges (ISML als proprietäre Erweiterung von HTML, eine funktionierende Storefront braucht eine eigene Cartridge), abgerufen am 14. November 2026, https://trailhead.salesforce.com/content/learn/modules/b2c-cartridges/b2c-cartridges-ref-architecture ↩