Von Swell zu einem eigenen Shop wechseln

Die Mail, mit der ein Abschied von Swell anfängt

Geschrieben wird sie fast immer von jemandem, der den eigenen Shop sehr gut kennt. Die Entscheidung für Swell war bewusst, der Storefront ist selbst gegen dessen API gebaut, und das läuft seit zwei, drei Jahren. Der Vorwurf lautet selten, Swell tauge nichts. Er lautet, aus dem Shop seien zwei Systeme geworden, die nur ein Vertrag zusammenhält: ein Storefront, der dem Unternehmen gehört, und ein Commerce Backend, das es mietet. Zwei Rechnungen, zwei Roadmaps, zwei Gruppen von Leuten, die jeweils nur ihre Hälfte verstehen. Die Frage in der Mail ist, ob das nicht in einer einzigen Anwendung leben könnte, die dem Unternehmen selbst gehört, auf genau dem Web Framework, das das Storefront Team ohnehin schätzt.

Eine berechtigte Frage, und die ehrliche Antwort ist nicht automatisch ja. Swell ist eine leistungsfähige moderne Plattform, und für viele Shops ist Bleiben die richtige Wahl. Dieser Text richtet sich an das Unternehmen, dem dieses Nebeneinander zu eng geworden ist und das stattdessen eine einzige eigene Rails Anwendung möchte. Ich versuche, präzise zu sein bei dem, was ein Wechsel tatsächlich bedeutet. Die Konzepte, die für jede Migration gelten, stehen in den ausführlichen Leitfäden, dort verlinke ich sie. Zuerst zu lesen ist was sich übertragen lässt und was nicht.

Was Swell ist und wer bleiben sollte

Swell ist eine headless Commerce Plattform. Du erhältst eine gehostete Datenbank mit den üblichen Ecommerce Modellen, ein Admin Dashboard und eine API. Den Storefront für die Kundschaft baust du selbst, in der Regel als eigene Frontend Anwendung, die über die API mit Swell spricht, und das Commerce Backend betreibt Swell auf eigener Infrastruktur, sodass du dafür nie einen Server oder eine Datenbank bereitstellst.¹ Das ist ein durchdachtes Modell. Es passt zu einem Team, das vorn eigenen Code steuern möchte, ohne hinten die Commerce Engine selbst betreiben zu müssen.

Deshalb vor allen Details zuerst die Gegenfrage: Wer sollte nicht wechseln? Wenn du zufrieden einen eigenen Storefront gegen ein gehostetes Backend fährst, wenn Katalog und Regeln ohne Reibung in das Datenmodell von Swell passen und wenn die monatliche Rechnung in deiner Größe bequem bleibt, dann leistet Swell genau das, wofür es gedacht ist, und eine Migration wäre Mühe, um am selben Punkt herauszukommen. Die headless Teilung ist dann dein Vorteil und nicht deine Belastung.

Gemeint ist hier das Unternehmen, für das aus dieser Teilung eine Belastung geworden ist. Es will eine Anwendung, ein Deployment, eine Codebasis und eine Person, die für das Ganze verantwortlich ist, statt eines Storefronts hier und einer Commerce Plattform dort, in die es nicht hineinschauen kann. Oft läuft der Storefront bereits in Ruby on Rails oder soll es, und Solidus, ein quelloffenes Commerce Framework auf Rails,² macht Katalog, Checkout, Verwaltung und Storefront zu einem einzigen eigenen Ding. Der Hebel ist Passung und Eigentum, keine Rettung. An deine Daten kommst du. Die eigentliche Frage ist, ob dir der gesamte Stack als Eigentum den Aufbau wert ist.

Was dir gehört und was auf Swells Infrastruktur liegt

Zieh die Grenze deutlich, bevor du planst.

Dein Storefront Code gehört dir, weil er von dir stammt. Domain, Gestaltung und Inhalte gehören dir. Und deine Daten gehören dir in dem praktischen Sinn, dass die API sie vollständig herausgibt. Nicht dir gehört der Ort, an dem sie liegen. Datenbank, Commerce Logik, Verwaltung, Kartenspeicher und die bedienende API laufen auf der Infrastruktur von Swell, und dein Storefront ist darauf angewiesen, dass diese Infrastruktur läuft und bei jedem Seitenaufruf antwortet.¹ Genau diese Abhängigkeit verschiebt ein Umzug. Danach liegen die Daten in deiner eigenen Postgres Datenbank, in deiner eigenen Anwendung, auf Hosting, das du kontrollierst.

Zu jeder Zeile, die Daten bewegt, gibt es einen ausführlichen Leitfaden: Kundenkonten und Adressen, Produkt und Katalogdaten, Bestell und Kaufhistorie, Zahlungstoken und gespeicherte Karten und Abonnements und wiederkehrende Zahlungen. Ihre Mechanik wiederhole ich hier nicht. Dieser Text handelt von dem, was an Swell besonders ist.

Export und API in der Praxis

Swell sperrt deine Daten nicht weg, und das gehört klar gesagt, weil der ehrliche Hebel eben keine Geiselhaft deiner Daten ist. Der Ausgang ist die Backend API. Sie bietet vollen Zugriff auf jedes Modell im Shop, ist eine schlichte REST Schnittstelle, die JSON entgegennimmt und zurückliefert, unter der Basis https://api.swell.store, und für sie gibt es offizielle Bibliotheken für Node und PHP.³ Die Standardmodelle decken die erwartbaren Commerce Objekte ab, darunter Produkte und Bestellungen, und jedes eigene Modell, das du ergänzt hast, taucht über dieselbe Schnittstelle auf, weil Swell die Endpunkte aus den Modelldefinitionen erzeugt.⁴ Zusätzlich kannst du das Schema selbst auslesen, Modell für Modell, sodass ein Migrationsskript jedes jemals ergänzte Feld findet, statt zu raten.⁴

Dieser Punkt wiegt bei Swell schwerer als bei einer starren Plattform. Swell erlaubt dir, das Datenmodell zu erweitern: Du kannst den Standardmodellen Felder hinzufügen oder im Dashboard unter Developer und dann Models neue Modelle anlegen, und installierte Apps haben womöglich eigene ergänzt.⁴ Ein Produkt in deinem Swell Shop ist deshalb kein generisches Produkt. Es kann Felder tragen, die es nur bei dir gibt, und die Migration muss sie aufspüren, ihre Bedeutung verstehen und entscheiden, wohin jedes im Solidus Modell gehört. Das Schema auszulesen ist der Weg, kein Feld stillschweigend zu verlieren, auf dem das Geschäft aufsetzt.

Zwei Grenzen sind zu bedenken. Erstens: Der Export ist ein Lesen über die API, kein einzelner Download Knopf. Die Migration ist also eine Reihe von Skripten, die sich durch die Modelle blättern, kein Nachmittag mit einer Tabelle. Zweitens das Rate Limit. Die Backend API ist pro Shop und getrennt je Umgebung begrenzt, über Durchsatz und Gleichzeitigkeit, und Anfragen werden gewichtet statt eins zu eins gezählt, sodass eine Aggregation oder eine stark erweiterte Abfrage mehr kostet als ein einfaches Lesen.⁵ Überschreitest du die Grenze, landen Anfragen in einer Warteschlange statt einer Absage, und erst eine Anfrage, die länger als 60 Sekunden wartet, fällt mit einem HTTP 429 heraus.⁵ Praktisch heißt das: Der vollständige Export läuft als getaktete, wiederaufsetzbare Aufgabe, die in Stapeln liest und keinen großen Katalog in einem Schwung zieht. Leichte Lesezugriffe auf Produkte, Varianten, Kategorien, Attribute, Konten, Warenkörbe und Inhalte schöpfen aus einem eigenen Kontingent, was hilft, doch der vernünftige Plan bleibt, den Export an einer Kopie zu proben und ihm die Zeit zu lassen, die er braucht.⁵

Der Preis, der mit dir wächst

Das deutlichste Eigentumsargument für einen wachsenden Swell Shop steht auf der Preisseite. Die Pläne reichen von Starter mit 29 USD im Monat bis Unlimited mit 2.250 USD im Monat, und jeder Plan trägt zwei Dinge, die ein gemietetes Backend gern mitbringt: eine jährliche Umsatzgrenze und einen Zähler.⁶

Die Grenze ist ein Wert an Jahresumsatz, von 50.000 USD im Einstieg bis 5 Millionen USD bei Unlimited, und Umsatz oberhalb der Grenze deines Plans wird mit einem Prozentsatz belegt, von 2 % im kleinsten Plan bis hinunter zu 0,4 % im größten.⁶ Das ist keine Transaktionsgebühr pro Bestellung, und Swell stellt klar, bei Zahlungen über ein externes Gateway keinen Anteil zu nehmen, doch es koppelt die Plattformkosten daran, wie viel du verkaufst, also ausgerechnet an die Größe, die ein Shop steigern will. Der Zähler sitzt auf der API selbst: Jeder Plan enthält ein monatliches Kontingent an API Anfragen, von 100.000 bis 2 Millionen, und jede Anfrage darüber kostet 5 USD je weitere 100.000, mit vergleichbarer Mehrnutzung bei Funktionsaufrufen und Speicher.⁶ Für einen headless Shop ist das eine reale Zahl, denn dein eigener Storefront erzeugt diese Anfragen bei jedem Seitenaufruf und jeder Suche.

Nichts daran ist verdeckt oder unfair, und in kleiner Größe fällt es kaum ins Gewicht. Es wächst nur mit deinem Erfolg statt mit deinen Kosten. Ein eigener Solidus Shop kehrt diese Form um: höhere Kosten zu Beginn, danach Hosting und Wartung, die der Arbeit folgen und nicht dem Umsatz, ohne Lizenz und ohne Prozentsatz über einer Grenze.² Die vollständige Rechnung über fünf Jahre, mit konkreten Zahlen, steht in den Gesamtkosten über fünf Jahre, und der Vergleich Plattform für Plattform in dem Vergleichsartikel.

Der Kartenspeicher ist der harte Teil, wie stets

Swell betreibt einen eigenen Kartenspeicher. Speichert jemand eine Karte, tokenisiert Swell sie und legt die verschlüsselten Daten in diesem Speicher ab, und der Token hängt am Kundenkonto.⁷ Solange du auf Swell bist, ist das ein wirklich gutes Design, denn du kannst das Zahlungsgateway wechseln, ohne dass die Kundschaft ihre Karten erneut eingibt, und es ist der Grund, warum Swell Abonnements gegen jedes Gateway abrechnen kann, das gespeicherte Karten unterstützt.⁷ Zugleich ist es das Eine, das vor dem Weggang die meiste Planung verlangt.

Die Feinheit lohnt genaue Betrachtung, denn hier zählen Fairness und Präzision am meisten. Innerhalb von Swell ist der Speicher zwischen Gateways beweglich, aber es bleibt Swells Speicher. Vollständig von Swell weg bedeutet, diese gespeicherten Karten in einen Speicher zu überführen, den du kontrollierst, und rohe Kartennummern reisen niemals in einem Migrationsskript. Rechnet dein Swell Shop bereits über dein eigenes Gateway Konto ab, liegen die gespeicherten Karten vielleicht schon im Speicher dieses Gateways, dann verbindet sich der Solidus Shop mit demselben Konto und die Karten bleiben unberührt. Liegen sie dagegen in Swells Speicher, stehst du vor einem Transfer von Gateway zu Gateway, den der annehmende Abwickler nur von einem nach PCI DSS Level 1 zertifizierten Partner akzeptiert und der weder Abonnements noch Zahlungshistorie mitnimmt.⁸ Die ausführliche Fassung, samt der Fragen, die du dem Gateway zuerst stellst, findest du in dem Leitfaden zu Zahlungstoken. Markiere es in Woche eins, nicht in Woche zehn.

Abonnements liegen unmittelbar daneben, weil Swells wiederkehrende Abrechnung auf der gespeicherten Karte aufsetzt.⁷ Ein Abo ist nicht nur eine Zeile mit dem Vermerk monatlich. Es ist eine lebende Abrechnungsvereinbarung mit nächstem Buchungstermin, einem Takt und einer hinterlegten Zahlungsart, und es bucht weiter, während du umziehst. Du überführst die Zeitpläne und die Kundenabsicht, verankerst jedes Abo neu auf dem Gateway, über das der Solidus Shop abrechnet, und wählst einen Umzug, der nicht mitten in einen Abrechnungslauf fällt. Der Leitfaden zu Abonnements behandelt die Mechanik. Ist dein Shop abogetrieben, bestimmt dieser Teil den Zeitplan.

Storefront, SEO und Weiterleitungen

An dieser Stelle ist ein Swell Umzug leichter als der Abschied von einem geschlossenen Baukasten, und das sage ich gern. Weil Swell headless ist, gehören dir Storefront und URLs bereits. Es gibt kein Theme, das in einer Plattformsprache steckt und entwirrt werden müsste, und dein Frontend Code lässt sich häufig gegen Solidus weiterverwenden, mit darunter getauschter Datenschicht, statt von Grund auf neu entstehen zu müssen. Das spart echt, und es ist einer der Gründe, warum ein Wechsel von Swell zu Solidus sauberer ausfallen kann, als er klingt.

Die Kehrseite: SEO war auf Swell immer deine Aufgabe und bleibt es auf Solidus. Die Plattform besaß deine URL Struktur nicht, es gibt also kein anbietereigenes Pfadschema zu übersetzen, doch jede Adresse, die dein Storefront veröffentlicht, muss nach dem Umzug auflösen. Bilde jede alte URL auf ihre neue ab, nutze dauerhafte serverseitige Weiterleitungen direkt zum Ziel statt über eine Kette, und halte sie mindestens ein Jahr.⁹ Bei einem headless Aufbau ist die Liste meist kürzer und sauberer als bei einer Template Plattform, weil du die URLs selbst gesetzt hast, doch eine fehlende Zeile bleibt eine Seite, die am Umschalttag einen 404 liefert. Produkt URLs und die kanonische Behandlung stehen ausführlich in dem Leitfaden zu Produktdaten.

Eine Zeile fehlt noch. Kundendaten zu verlagern erfordert keine neue Einwilligung von jeder Person, aber der Shop bleibt Verantwortlicher dieser Daten, und jeder Auftragsverarbeiter, die alte Plattform, der neue Host und der Entwickler, braucht einen schriftlichen Vertrag nach Artikel 28.¹⁰ Übertrage Marketingeinwilligungen mit Zeitstempel und Wortlaut statt als bloßes Ja oder Nein, und bitte Swell nach dem letzten Export schriftlich um Löschung der alten Kopie. Wer was hält und warum Eigentum am Stack die Antwort verändert, behandelt wem deine Geschäftsdaten gehören.

Ein durchgerechnetes Beispiel: eine Leipziger Kaffeemarke zieht auf Solidus

Elsterweg Kaffee (elsterwegkaffee.example) ist ein erfundenes Leipziger Unternehmen, das Kaffee im Abo röstet und verschickt. Es setzt rund 1,2 Millionen Euro im Jahr um, führt etwa 400 Produkte, sobald Mahlgrade und Packungsgrößen als Varianten zählen, und betreibt grob 3.000 aktive Abos im wöchentlichen, zweiwöchentlichen und monatlichen Takt. Vor zwei Jahren hat die Gründerin einen schnellen eigenen Storefront gebaut und Swell dahintergesetzt, damals die richtige Entscheidung. Heute will das Unternehmen, dass Röstereisoftware, Großhandelsbestellung und Abo Shop eine Rails Anwendung sind, die der eigene Entwickler besitzt, und es ist es leid, über ein Backend zu grübeln, dessen Quellcode es nicht lesen kann.

Der Umzug beginnt mit den Fragen, die teuer werden, wenn man sie verfehlt, und bei diesem Shop drehen sie sich sämtlich um Geld in Bewegung. In Woche eins kläre ich, wo die gespeicherten Karten wirklich liegen. Elsterweg rechnet über das eigene Gateway Konto ab, die Karten liegen also im Speicher des Gateways und nicht in Swells Speicher gestrandet, womit aus dem härtesten Problem eine Verbindung statt eines Transfers wird.⁷⁸ Dann die Abonnements: Ich lese jedes Abo über die Backend API mit Takt, nächstem Buchungstermin und zugehöriger Person und lege den Umzug in das ruhigste Fenster des Abrechnungskalenders, damit niemand doppelt belastet und niemand übersehen wird.⁵

Katalog und Kundschaft sind der ruhige Teil. Eine getaktete Reihe von Skripten liest Produkte, Varianten, Kategorien und die eigenen Felder, die Elsterweg für Röstdatum und Herkunft angelegt hat, aufgespürt über das Auslesen des Schemas, sodass keines verloren geht, und schreibt sie als Produkte, Varianten und Option Types in Solidus.⁴ Kundenkonten und Adressen kommen auf demselben Weg herüber, ohne Passwörter, sodass jede Person beim ersten Besuch nach dem Start ein Passwort setzt oder sich neu anmeldet. Drei Jahre Bestellungen ziehen als nur lesbare Historie um, damit Support und Kundschaft zurückblättern können, während der volle Export für die Buchhaltung archiviert wird. Der Storefront, bereits der eigene Code des Unternehmens, wird auf Solidus gerichtet, mit neu geschriebener Datenschicht, und darum dauert dieser Aufbau Wochen statt Monate.

Der Umzug fällt auf einen ruhigen Dienstagvormittag außerhalb eines Abrechnungslaufs. Die Domain wandert auf die neue Anwendung, die Weiterleitungsliste wird von Hand gegen die wichtigsten Seiten geprüft, eine echte Abo Verlängerung und eine echte Einzelbestellung werden je Zahlungsart ausgeführt und erstattet, und der alte Swell Shop bleibt 30 Tage live und bezahlt als Weg zurück. Einen Monat später, nach einem sauberen Abrechnungszyklus und einem sauberen Monatsabschluss auf Solidus, wird der Swell Plan gekündigt und seine Löschung schriftlich verlangt. Elsterweg betreibt nun eine Anwendung: Rösterei, Großhandel, Abos und Shop, in eigenem Besitz, auf eigenem Hosting, ohne Umsatzgrenze und ohne API Zähler.

Der ehrliche Umzugsplan

Auf seine Form gebracht, ist der Plan dieselbe Disziplin, die jede Migration verlangt, nur mit den Swell Besonderheiten eingefügt.

Entscheide zuerst die Frage zu Zahlungen und Abonnements, denn sie setzt den Zeitplan und ist der einzige Teil, der mit dem Geld der Kundschaft schiefgehen kann. Lies das Schema, bevor du einen Import schreibst, damit die eigenen Felder, die deinen Shop zu deinem machen, nicht lautlos verschwinden. Führe den Export als getaktete, wiederaufsetzbare Aufgabe aus, die das Rate Limit respektiert, statt dagegen anzurennen. Verwende den Storefront weiter, wo es geht, denn er gehört dir, und tausch die Datenschicht darunter. Baue die Weiterleitungsliste, auch wenn sie kürzer ausfällt als sonst, und prüfe sie. Behalte drei Jahre Bestellungen, nicht alles. Lass beide Systeme parallel laufen, mit eingefrorenem Katalog, probe den letzten Import zweimal, schalte an einem ruhigen Vormittag außerhalb jedes Abrechnungslaufs um und halte Swell 30 Tage als Rückfallebene am Leben, bevor du kündigst.

Nichts davon ist allein für Swell eigen, außer dem Auslesen des Schemas, dem ratenbegrenzten Export und der Speicherfrage. Der Rest ist das Handwerk aus dem Pfeiler Leitfaden, und wenn dein Plan keine Person im Unternehmen hat, die Daten, eigene Felder und Abonnements versteht, ist es noch kein Plan.

Wann Bleiben auf Swell richtig ist

Ich verliere diese Arbeit lieber, als sie dem falschen Shop zu verkaufen, deshalb hier das Plädoyer fürs Bleiben.

Bleib, wenn die headless Teilung dir hilft, statt dich zu kosten, was für die meisten Shops in den meisten Größen stimmt. Bleib, wenn dein Umsatz bequem unter der Grenze deines Plans liegt und der API Zähler ein Rundungsfehler ist, denn dann ist der Preis, der im Großen wie eine Abgabe wirkt, schlicht eine faire Rechnung. Bleib, wenn dein Team klein ist und der Gedanke, Hosting, Updates und Sicherheit für den gesamten Stack selbst zu tragen, eher Last als Entlastung bedeutet. Bleib, wenn du eigentlich etwas am Storefront ändern willst, denn das geht auf Swell, ohne das Backend anzufassen. Eine Migration lohnt sich, wenn dir eine Anwendung von Ende zu Ende als Eigentum mehr wert ist, als der Aufbau kostet, und wenn du die Person benennen kannst, die sie besitzen wird. Kannst du das nicht, hinterlässt dir der Wechsel einen schönen neuen Shop voller Daten, für die niemand einsteht.

Der Workshop

Wenn du das abwägst, biete ich einen kostenlosen Workshop an, und die ersten zwei Wochen Arbeit gehen auf mich. Bring deinen Swell Plan und die aktuelle Rechnung mit, eine Notiz zu den eigenen Feldern und Apps, die du angelegt hast, und ob deine gespeicherten Karten in deinem eigenen Gateway oder in Swells Speicher liegen, und ich gehe mit dir durch, ob dir der ganze Stack als Eigentum etwas einbringt. Manchmal tut er es nicht, und dann sage ich es dir.