Von Saleor zu einem eigenen Shop auf Solidus wechseln

Die Nachricht, mit der ein Saleor Wechsel beginnt

Saleor ist gute Software, deshalb klingt die Nachricht, die ich dazu bekomme, anders als bei einer geschlossenen Plattform. Sie sagt selten "wir kommen an unsere Daten nicht heran" oder "der Anbieter hält uns fest". Sie klingt eher so. Wir sind vor zwei Jahren auf Saleor gestartet, weil ein Entwickler es als GraphQL Shop mit einem React Storefront aufgesetzt hat, es läuft, aber der Entwickler ist weitergezogen, Leute für Python und GraphQL und einen eigenen Frontend zu finden ist schwer, und ich möchte eine Person, der das Ganze gehört. Oder: die Saleor Cloud Rechnung ist gewachsen, und ich bin mir nicht mehr sicher, ob sich die headless Maschinerie für einen Shop meiner Größe rechnet.

Das ist meine ehrliche Antwort für ein Unternehmen, das überlegt, Saleor für einen eigenen Shop auf Solidus zu verlassen, dem Open Source Ruby on Rails Framework, auf dem ich baue. Ich bleibe fair, denn Saleor verdient das. Der Code gehört dir wirklich, die Daten gehören dir, und für das richtige Team ist Saleor eine starke Wahl. Der Grund für einen Wechsel ist fast nie ein Lock in. Es ist die Passung. Darum geht es in diesem Artikel vor allem: was Passung hier bedeutet, was tatsächlich umzieht und wo die eigentliche Arbeit liegt.

Die tiefe, plattformunabhängige Detailtiefe, also wie Kundenkonten, Kataloge, Bestellungen und gespeicherte Karten grundsätzlich umziehen, verlinke ich zu den Datentyp Leitfäden dieser Serie, statt sie zu wiederholen. Beginne mit der Säule, was sich überträgt und was nicht.

Was Saleor ist, und wer bleiben sollte

Saleor beschreibt sich selbst klar. Die eigene Projektdatei nennt es eine headless E Commerce Plattform, gebaut mit Python, GraphQL, Django und React, veröffentlicht unter der BSD 3 Clause Lizenz.¹ Die Startseite des Repositorys nennt es eine GraphQL native, reine API Plattform für Composable Commerce und führt "Headless and API only" und "GraphQL only" unter den prägenden Eigenschaften.² Die Architekturübersicht sagt, die Engine sei in Python geschrieben und die API laufe als GraphQL über HTTP oder Message Queues, mit einem schlanken Kern und einem reichen Umfeld externer Anwendungen.³

Zwei Worte darin wiegen schwerer als der Rest. "Headless" heißt, Saleor liefert keinen fertigen Shop Frontend mit. Du baust den Storefront selbst, meist in React oder Next.js, gegen die GraphQL API, und du betreibst das Dashboard als eigene Anwendung. "Composable" heißt, der Backend ist ein Satz von Commerce Bausteinen, die du zusammensetzt und mit Apps und Webhooks erweiterst. Das ist ein bewusstes, modernes Design, und es ist in dem, wofür es gedacht ist, wirklich gut.

Wer sollte also auf Saleor bleiben? Ein Team, das Composable, ereignisgesteuerten GraphQL Commerce will, das mehrere Storefronts oder Verkaufskanäle auf einem Backend betreibt, das Python und Frontend Entwickler hat oder einstellen kann, und das zufrieden damit ist, diese Architektur zu besitzen. Wenn Saleor zu deinem Unternehmen passt und deine Leute darin produktiv sind, ist der Umzug auf Solidus ein seitlicher Schritt mit Kosten und ohne Gewinn. Das würde ich dir im Workshop sagen. Wenn du nur moderne Open Source Optionen gegeneinander abwägst, ist das ein Vergleich, keine Migration, und der Weg weg von Medusa liegt in derselben Kategorie.

Wer herauswächst, ist das umgekehrte Profil. Ein einzelner Shop, der die headless Trennung nicht braucht. Ein Inhaber, der einen verantwortlichen Builder möchte statt eines Python Backends, eines React Frontends und wem auch immer, der die beiden im Gleichschritt hält. Ein Unternehmen, das lieber im Rails und Solidus Umfeld lebt. Und ein Shop auf Saleor Cloud, der die Rechnung genau angeschaut hat.

Was dir gehört, und was wirklich festsitzt

Hier muss ich vorsichtig sein, denn das übliche Migrationsargument trifft nicht zu. Betreibst du die selbst gehostete Ausgabe, gehört dir alles: der Quellcode, die PostgreSQL Datenbank und jede Zeile darin. Die BSD Lizenz erlaubt dir sogar, eigene Änderungen privat zu halten, ohne Pflicht, sie zu veröffentlichen.⁴ Betreibst du Saleor Cloud, gehören dir immer noch deine Daten und du kannst gehen. Was dir nicht gehört, ist die laufende Infrastruktur, und die GraphQL API ist deine Tür hinein und hinaus. Saleors eigene Position ist, dass Cloud der beste Weg ist, das Produkt zu betreiben, und über die Gesamtkosten der günstigste,⁴ und für viele Teams ist das fair gesagt.

Nichts davon ist eine Falle. Falls dir jemand erzählt hat, Saleor zu verlassen bedeute, deine Daten zu verlieren, liegt er falsch, und wem deine Geschäftsdaten eigentlich gehören ist lesenswert, bevor du irgendeinem Anbieter in dem Punkt glaubst. Was im weichen Sinn "festsitzt", ist die Form der Sache: nur GraphQL, headless, ein Storefront, den du getrennt pflegst, die Saleor Cloud Preise, wenn du dort bist, und die gewöhnlichen Bindungen an Dritte, die jede Plattform hat, vor allem der Zahlungsanbieter, der deine Karten Token hält, und was auch immer deine Abonnements betreibt. Ich nehme sie der Reihe nach.

Export und API in der Realität

Saleor ist API first, und die API ist GraphQL, ohne REST Schnittstelle als Rückfallebene.² Das prägt jeden Export, den du machst.

Für den Katalog gibt es einen eingebauten Produktexport. Das Dashboard und die Mutation exportProducts erzeugen eine CSV oder XLSX Datei, bezogen auf alle Produkte, eine gefilterte Menge oder eine Liste von IDs, mit den Feldern und der Spaltenreihenfolge, die du wählst, und die fertige Datei kommt als Downloadlink per E Mail.⁵ Sie deckt Produkte und Varianten ab, samt Attributen, Lagermengen und Preisen je Kanal, und ist das sauberste einzelne Werkzeug im Kasten. Kunden oder Bestellungen exportiert sie nicht.

Die holst du über die GraphQL API mit geschriebenen Abfragen. Drei Grenzen bestimmen, wie. Paginierte Felder liefern höchstens 100 Einträge pro Seite, über Cursor basierte Paginierung, ein vollständiger Export ist also eine Schleife, die Cursorn folgt.⁶ Die Abfragekosten zählen nach der Zahl der angeforderten Objekte, nicht der zurückgegebenen, und der Server weist alles über seiner Obergrenze zurück und meldet die Kosten und das Limit in jeder Antwort.⁶ Beim Rate Limiting teilt sich das Bild: freie Saleor Cloud Sandboxes erlauben 120 Anfragen pro Minute und bezahlte 2.000, darüber liefert die API HTTP 429, während produktive Cloud Umgebungen und selbst gehostete Installationen kein festes Limit haben, wobei die Produktion Verkehr drosseln kann, der den Dienst beeinträchtigt.⁶ In der Praxis ist eine Migration aus der Cloud ein sorgfältiges, getaktetes Abgrasen der API, einmal geschrieben und so oft wiederholt, bis es langweilig ist.

Hostest du selbst, hast du einen kürzeren Weg dazu: direkten Zugriff auf die PostgreSQL Datenbank, der schnellste Weg, einen großen Katalog und die Bestellhistorie in Masse zu bewegen. In der Cloud gibt es keinen Datenbankzugriff, dort sind die GraphQL API und der Produktexport das ganze Werkzeug.

Eines kommt nie in nutzbarer Form mit, bei Saleor so wenig wie anderswo: Passwörter. Sie liegen gehasht vor, Kunden setzen also beim ersten Besuch im neuen Shop ein neues. Das ist eine Kampagne, die man plant, kein technisches Hindernis, und der Leitfaden zu Kundenkonten und Adressen zeigt, wie man sie fährt, ohne am Umstelltag das Postfach zu fluten.

Der ehrliche Hebel: eine Anwendung statt zwei

Headless ist ein Merkmal, kein Mangel. Es ist für einen kleineren Shop zugleich der Kern der Sache. Auf Saleor betreibst du mindestens die Python Engine, einen Storefront, den du gebaut hast und pflegst, und das Dashboard, dazu Apps und Webhooks ringsum für Zahlungen und den Rest.³ Das sind zwei oder drei Codebasen, zwei oder drei Deploy Pipelines und zwei Kompetenzprofile: Backend Python und GraphQL auf der einen Seite, ein JavaScript Storefront auf der anderen. Für ein großes Team mit mehreren Kanälen zahlt sich diese Trennung aus. Für einen einzelnen Shop sind es viele bewegliche Teile, die im Gleichschritt bleiben müssen, und der Tag, an dem der Entwickler geht, der beide verstanden hat, ist der Tag, an dem es anfängt zu schmerzen.

Ein Solidus Shop ist eine Ruby on Rails Anwendung. Solidus ist Open Source unter der BSD 3 Clause Lizenz, bringt eine REST API mit und ist eine gewöhnliche Rails Anwendung mit den Testwerkzeugen, dem Deploy Weg und dem Bewerberpool, den das bedeutet.⁷ Du kannst weiterhin headless gehen, wenn du es brauchst: headless und API first Solidus zeigt, wie derselbe Shop später eine mobile App oder einen zweiten Storefront bedient. Der Unterschied ist, dass du am ersten Tag nicht in diese Trennung gezwungen wirst für einen Shop, der sie nicht braucht. Eine Anwendung, ein verantwortlicher Builder, ein Ort, an dem du nachschaust, wenn etwas kaputtgeht. Das, weit mehr als jedes Datenargument, ist der Grund, warum eine bestimmte Art Saleor Shop auf Solidus besser aufgehoben ist.

Zahlungen, gespeicherte Karten und der Anbieter

Saleor verarbeitet Zahlungen nicht selbst. Es bindet Anbieter wie Adyen über Apps und Transaktions Webhooks ein, und die Kartendaten und die wiederverwendbaren Token liegen beim Anbieter, nicht in Saleor.⁸⁵ Das ist eine gute Nachricht für einen Umzug. Der beste Fall nimmt die schwerste Frage ganz vom Tisch: zahlt dein Shop bereits über ein eigenes Konto bei Stripe, Adyen oder ähnlich, verbindet sich der neue Solidus Shop mit demselben Konto und die gespeicherten Karten bleiben genau dort, wo sie sind.

Wechselst du dagegen im Zuge des Umzugs den Anbieter, reisen gespeicherte Karten nur zwischen Anbietern, die nach PCI DSS Level 1 zertifiziert sind, und selbst dann umfasst der Export nur die Karten, nicht die daran hängenden Abonnements oder die Zahlungshistorie.⁹ Das ist der Punkt, den man im ersten Gespräch anspricht, nicht in der letzten Woche, und der Leitfaden zu Zahlungstoken und gespeicherten Karten legt die Fragen vor, die du deinem Anbieter stellst, bevor du dich auf ein Datum festlegst.

Abonnements, falls du welche fährst

Saleors Kern ist ein Satz von Commerce Bausteinen, keine Abo Engine, deshalb läuft wiederkehrende Abrechnung auf Saleor meist über eine App oder einen externen Dienst, der über Webhooks eingebunden ist. Die praktische Folge für einen Umzug ist, dass "was genau die Abonnements betreibt, und wo liegen die Zeitpläne und die Mandate" die Frage ist, die du vor allem anderen beantwortest, denn ein aktives Abonnement ist das härteste Objekt jeder Migration. Der Leitfaden zu Abonnements und wiederkehrenden Zahlungen geht die Fälle durch, vom sauberen Umschalten bis zum langsamen Übergang, bei dem beide Systeme ein, zwei Abrechnungszyklen nebeneinander laufen.

SEO und die Weiterleitungskarte

Weil der Storefront auf Saleor dir gehört, gehören dir auch die URLs. Welche Pfade deine React oder Next.js Anwendung für Produkte, Kategorien und Inhalte nutzt, das sind die, die deine Rankings und deine eingehenden Links tragen, und sie müssen im neuen Shop sinnvoll landen. Die Regel ist dieselbe wie bei jedem Umzug: liste jede alte URL, die im letzten Jahr einen Besuch oder einen Link bekommen hat, bilde jede auf ihre neue Adresse ab und liefere eine dauerhafte Weiterleitung, in fast allen Fällen eine 301, die direkt auf das endgültige Ziel zeigt statt über eine Kette. Halte die Weiterleitungen mindestens ein Jahr, und dauerhaft, wenn du kannst.¹⁰ Der Leitfaden zu Produkt und Katalogdaten zeigt, wie der Katalog und seine URLs gemeinsam umziehen, woraus der Großteil der Weiterleitungskarte entsteht.

Der Umzug, auf die Datenleitfäden abgebildet

Hier die Form eines Saleor Umzugs auf einer Seite. Jede Zeile verweist auf den Leitfaden mit der Detailtiefe, damit dieser Artikel bei Saleor bleibt und nicht wiederholt, was jene abdecken.

Was	Wie es Saleor verlässt	Wo die Details stehen
Produkte, Varianten, Preise, Lager	Produktexport als CSV oder XLSX, oder direkter PostgreSQL Zugriff bei Eigenbetrieb	Produkt und Katalogdaten
Kunden und Adressen	GraphQL Abfragen, 100 pro Seite, über Cursor, Passwörter zurücksetzen statt migrieren	Kundenkonten und Adressen
Bestell und Kaufhistorie	GraphQL Abfragen als reine Lesehistorie, die letzten Jahre, nicht alles	Was sich überträgt und was nicht
Gespeicherte Karten und Token	Bleiben beim Anbieter, behältst du das Konto, bewegen sie sich gar nicht	Zahlungstoken und gespeicherte Karten
Abonnements	Hängt von der App oder dem Dienst ab, der sie betreibt, das zuerst planen	Abonnements und wiederkehrende Zahlungen
Storefront, URLs, Weiterleitungen	Auf Solidus neu gebaut, jede alte URL auf eine 301 abgebildet	Produkt und Katalogdaten

Der Shop bleibt durchgehend der Verantwortliche für seine Kundendaten, und die Plattform, der Hoster und ich sind jeweils Auftragsverarbeiter, die einen schriftlichen Auftragsverarbeitungsvertrag nach Artikel 28 der DSGVO brauchen.¹¹ Eine Migration braucht keine neue Einwilligung von jedem Kunden, aber sie braucht die Einwilligungsnachweise, mit ihren Zeitstempeln und ihrem Wortlaut, mitgenommen und nicht auf ein Ja oder Nein reduziert.

Ein durchgerechnetes Beispiel: Grazer Röstwerk

Das Grazer Röstwerk (roestwerk.example) ist eine erfundene Grazer Kaffeemarke mit rund 1,2 Millionen Euro Online Umsatz im Jahr. Sie röstet auf Bestellung, verkauft Bohnen und Brühgerät und fährt einen Kaffeeklub, der alle zwei oder vier Wochen liefert, grob ein Drittel des Umsatzes. Vor zwei Jahren hat ein Entwickler sie auf Saleor Cloud Select gebaut, mit einem Next.js Storefront und Stripe für Zahlungen, und es hat gut funktioniert.¹² Das Problem sind die Leute, nicht die Plattform. Dieser Entwickler arbeitet inzwischen auf eigene Rechnung und ist schwer zu buchen, die Inhaberin findet keine einzelne Person, die in Python und im React Storefront zugleich stark ist, und das Cloud Abo samt Kaffeeklub Werkzeug ist eine Position, die sie bemerkt. Sie will einen Shop, einen Builder und das Rails Umfeld, das sie für die internen Werkzeuge der Rösterei ohnehin nutzt.

Ich würde es in dieser Reihenfolge fahren. Zuerst die zwei Fragen, die ein Datum versenken können. Zahlungen: der Shop besitzt sein Stripe Konto bereits, der Solidus Aufbau verbindet sich also mit demselben Konto und die gespeicherten Karten bleiben einfach, was den schwersten Punkt vom Tisch nimmt. Abonnements: der Kaffeeklub läuft über eine App, die in Saleor eingebunden ist, also kläre ich vor allem anderen, wo die Zeitpläne und die Stripe Mandate tatsächlich liegen, und plane, den Klub als eigenes kleines Projekt umzuziehen, sehr wahrscheinlich mit beiden Systemen für einen Abrechnungszyklus, damit keine Verlängerung ausfällt.

Dann die Daten. Der Katalog kommt über Saleors Produktexport als CSV heraus, Varianten, Attribute, Lager und Preise je Kanal inklusive, und bildet sich sauber auf Solidus Produkte und Varianten ab.⁵¹³ Kunden und Bestellhistorie kommen über die GraphQL API, ein getaktetes Abgrasen, das den Cursorn 100 Datensätze auf einmal folgt und gut innerhalb der Grenzen des Select Tarifs bleibt,⁶ als reine Lesehistorie der letzten drei Jahre hereingeholt, der vollständige Export archiviert. Passwörter rührt niemand an, und jedes Konto wird im neuen Shop bereit zur Freischaltung neu angelegt, und eine Servicenachricht vor dem Umschalten sagt Klubmitgliedern und Kunden, was sie beim ersten Besuch tun.

Der Storefront wird als Teil der Solidus Anwendung neu gebaut, und das ist der Sinn der Übung: eine Rails Codebasis statt einer Python API und einer getrennten Next.js Anwendung. Die Weiterleitungskarte entsteht aus den Next.js Routen, jede Produkt, Sammlungs und Inhalts URL auf eine 301 im neuen Shop abgebildet und vor dem Start getestet. Ein dreiwöchiger Parallelbetrieb auf einer Staging Adresse, ein Katalogstopp während dieser Zeit, zwei Proben des finalen Imports und ein Umschalten an einem ruhigen Dienstagvormittag außerhalb der Röstsaison. Die alte Saleor Umgebung bleibt dreißig Tage unberührt stehen als Rückfall, dann ein letzter Export und die Kündigung.

Der ehrliche Teil: das erste Jahr kostet das Grazer Röstwerk mehr, als ein Jahr Saleor Cloud Select gekostet hätte. Dafür bekommt sie eine einzige eigene Rails Anwendung, kein monatliches Cloud Abo und keine Mehrkostengebühr auf Wachstum, und eine Person, die sie anruft. Für einen Shop ihrer Größe ist dieser Tausch es wert. Für einen Shop halb so groß, ohne Abonnement und mit einem zufriedenen Entwickler, wäre er es nicht, und das würde ich ihr ebenso sagen.

Wann du nicht wechseln solltest

Bleib auf Saleor, wenn die headless, GraphQL Architektur etwas ist, das du aktiv willst und nutzt: mehrere Storefronts, starke Nutzung des Ereignismodells, ein Team, das darin flüssig ist. Bleib, wenn deine einzige Klage die Cloud Rechnung ist und die Rechnung tragbar ist, denn eine Migration trägt ein Risiko, das eine tragbare Rechnung nicht trägt. Bleib, wenn du die Person auf deiner Seite noch nicht benennen kannst, die die Daten, die Varianten und die Klubkunden versteht, denn ohne diese Person bekommst du einen ordentlichen neuen Shop voller falscher Daten. Und wechsle nie in den Wochen vor deiner Hochsaison.

Wechsle, wenn der Shop eine einzelne Anwendung ist, die sich als Plattformteam ausgibt, wenn du einen verantwortlichen Builder und das Rails Umfeld willst, und wenn die Saleor Cloud Preise für einen Shop deiner Größe aufgehört haben, zum Wert zu passen. Willst du die Fünfjahresrechnung hinter dieser Entscheidung, arbeite ich sie in den Gesamtkosten eines Umzugs auf Solidus durch, und ich vergleiche die wichtigsten Plattformen ehrlich in Solidus gegen Shopify, Shopware, Magento und WooCommerce.

Zum Schluss

Saleor ist keine Plattform, vor der ich warne. Es ist ein fähiges, quelloffenes, GraphQL natives Projekt, und wenn es zu deinem Team passt, passt es. Die Unternehmen, denen ich davon weghelfe, sind jene, bei denen die Passung still auseinandergefallen ist: ein einzelner Shop, der das Gewicht einer Composable Architektur trägt, die er nicht braucht, ein Inhaber, der einen Builder statt zweier Disziplinen will, eine Cloud Rechnung, die nicht mehr aufgeht. Für sie ist ein eigener Solidus Shop weniger zu betreiben, leichter zu besetzen und ganz der ihre.

Klingt das nach deinem Shop, dann bring das echte Bild in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Ich sage dir ehrlich, ob sich ein Wechsel rechnet, und wenn Saleor weiterhin das richtige Zuhause für dich ist, sage ich das stattdessen.

Footnotes

1. Saleor, pyproject.toml (Projektbeschreibung "headless e-commerce platform built with Python, GraphQL, Django, and React" und license = "BSD-3-Clause"), GitHub, abgerufen am 14. November 2026, https://github.com/saleor/saleor/blob/main/pyproject.toml ↩

2. Saleor, Repository README (GraphQL native, reine API Plattform für Composable Commerce, "Headless and API only", "GraphQL only"), GitHub, abgerufen am 14. November 2026, https://github.com/saleor/saleor ↩ ↩²

3. Saleor Dokumentation, Architecture (Engine in Python geschrieben, GraphQL über HTTP oder Message Queues, schlanker Kern und externe Anwendungen), abgerufen am 14. November 2026, https://docs.saleor.io/overview/architecture ↩ ↩²

4. Saleor Dokumentation, Open source (die BSD Lizenz erlaubt private Änderungen, Saleor Cloud als bester und über die Gesamtkosten günstigster Weg beschrieben), abgerufen am 14. November 2026, https://docs.saleor.io/overview/why-saleor/open-source ↩ ↩²

5. Saleor Dokumentation, Exporting products (CSV oder XLSX, Umfang ALL, FILTER oder IDS, gewählte Felder, Downloadlink per E Mail), abgerufen am 14. November 2026, https://docs.saleor.io/developer/export/export-products ↩ ↩² ↩³

6. Saleor Dokumentation, Usage limits (Kosten nach angeforderten Objekten, Paginierung auf 100 Einträge je Seite begrenzt, freie Sandboxes 120 Anfragen pro Minute und bezahlte 2.000 mit HTTP 429, produktive Cloud und Eigenbetrieb ohne festes Limit), abgerufen am 14. November 2026, https://docs.saleor.io/api-usage/usage-limits ↩ ↩² ↩³ ↩⁴

7. Solidus, Repository solidusio/solidus (Open Source Rails E Commerce unter der BSD 3 Clause Lizenz, bringt eine REST API mit), GitHub, abgerufen am 14. November 2026, https://github.com/solidusio/solidus ↩

8. Saleor Dokumentation, Webhooks overview (synchrone und asynchrone Ereignisse, Local und External Apps, Transaktionsereignisse für Zahlungen), abgerufen am 14. November 2026, https://docs.saleor.io/developer/extending/webhooks/overview ↩

9. Stripe Dokumentation, Request a payment data export (Kartendaten nur an einen nach PCI DSS Level 1 zertifizierten Anbieter, ohne Abonnements und Zahlungshistorie), abgerufen am 14. November 2026, https://docs.stripe.com/get-started/data-migrations/pan-export ↩

10. Google Search Central, Site moves with URL changes (jede URL abbilden, 301 oder 308 nutzen, mindestens ein Jahr halten), abgerufen am 14. November 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩

11. Verordnung (EU) 2016/679 (DSGVO), Artikel 28 (Auftragsverarbeiter), EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679 ↩

12. Saleor, Cloud Preise (Select für 1.599 US Dollar im Monat bis 200.000 US Dollar GMV mit 0,8 % Gebühr auf Bestellungen darüber, Volume für 3.999 US Dollar, dazu eine dauerhaft kostenlose Sandbox), abgerufen am 14. November 2026, https://saleor.io/pricing ↩

13. Saleor Dokumentation, ProductVariant API Referenz (Varianten mit SKU, Attributen, Lagerbeständen und Preislisten je Kanal), abgerufen am 14. November 2026, https://docs.saleor.io/api-reference/products/objects/product-variant ↩