Von Shopware zu einem eigenen Solidus Shop wechseln

Was Shopware ist, und wer darüber hinauswächst

Shopware 6 ist ein modernes und leistungsfähiges Shopsystem, und das sage ich mit voller Absicht zuerst. Es ist eine offene Commerce Plattform auf dem Symfony Framework mit einer Administration in Vue, und der Kern steht unter der permissiven MIT Lizenz.¹ Shopware ist stark in Deutschland, Österreich und der Schweiz, das Ökosystem kennt die rechtlichen Anforderungen hierzulande, und nahezu jede Agentur im Markt arbeitet damit. Wenn du einen klassischen Katalog auf Shopware fährst und er seine Aufgabe erfüllt, ist dieser Artikel kein Grund für einen Wechsel. Ein kleiner oder mittelgroßer Shop bleibt sehr häufig zu Recht dort, wo er ist.

Das Unternehmen, für das ich schreibe, ist das, das Shopware entwachsen ist. In der Regel flieht dieser Inhaber nicht vor einer schwachen Software. Er verfolgt etwas Bestimmtes: die volle Kontrolle über den gesamten Stack, einen Ausweg aus einer kommerziellen Lizenzstufe oder den laufenden Kosten des Extension Stores, oder den Wunsch, auf Ruby on Rails zu bauen, damit der Shop eine Anwendung wird, die ihm vollständig gehört, statt ein Produkt, das der Roadmap eines anderen folgt. Dies ist der ehrliche Leitfaden für genau diesen Wechsel, von Shopware zu einem eigenen Shop, den ich auf Solidus baue, dem quelloffenen Rails Framework für Commerce. Ich baue den Shop und übernehme die Migration, und das Ergebnis gehört dir.

Für die Konzepte, die gleich bleiben, egal von welcher Plattform du kommst, wie Kundendaten umziehen, was mit Produkten und URLs geschieht, warum gespeicherte Karten und Abos der schwierige Teil sind, verlinke ich die ausführlichen Leitfäden, statt sie zu wiederholen. Starte mit der Säule, was sich überträgt und was nicht. Hier geht es um Shopware selbst: seine Editionen, seinen Export und seine Fallen.

Was dir gehört, und was hinter einer bezahlten Stufe liegt

Der Aufbau von Shopware ist das Erste, das du begreifen solltest, denn dort entsteht der größte Teil des Drucks, zu wechseln. Es gibt einen offenen Kern und darüber eine Leiter bezahlter Pläne.²

Die Community Edition ist kostenlos, mit null ausgewiesen, und ihr Kern ist quelloffen unter der MIT Lizenz.²¹ Darüber liegen drei kommerzielle Pläne: Rise, ausgewiesen ab 600 Euro im Monat ohne Umsatzsteuer, Evolve ab 2.400 Euro im Monat ohne Umsatzsteuer, und Beyond zu einem individuellen Preis.² Die bezahlten Pläne fügen Funktionen hinzu wie Retourenmanagement, erweiterte Produktsuche, B2B Komponenten wie Angebote und Freigabeprozesse sowie kundenspezifische Preise, und Shopware hält fest, dass sich der Preis am Bruttowarenwert und weiteren individuellen Faktoren bemisst.² Die gedruckten Zahlen sind damit eine Untergrenze und kein Angebot.

An der kostenlosen Edition hängt eine Bedingung, die viele Inhaber erfüllen, ohne sie eingeplant zu haben. Nach der Fair Usage Policy von Shopware muss ein Unternehmen, dessen verknüpfte Shops in den vorangegangenen 365 Tagen mehr als 1 Million Euro Bruttowarenwert erzeugen, Rise, Evolve oder Beyond abonnieren, um den Zugang zum Shopware Account und zum Shopware Store zu behalten.²³ Die Richtlinie stellt klar, dass sie die Open Source Lizenz nicht antastet: die Community Edition bleibt vollständig quelloffen unter MIT, du behältst den vollen Zugriff auf den Quellcode und kannst die Software eigenständig weiterbetreiben.³ Was ein Shop oberhalb der Grenze ohne bezahlten Plan einbüßt, ist der Account und der Extension Store, nicht der Code. Das ist eine faire Unterscheidung, und sie verdient eine sorgfältige Lektüre, nicht die Zusammenfassung des einen Anbieters und nicht die eines Mitbewerbers.

Dazu kommt die Wahl des Betriebsmodells, die darüber entscheidet, wie viel vom Stack tatsächlich dir gehört. Shopware läuft selbst gehostet, auf Shopwares Platform as a Service oder als vollständig verwaltetes Software as a Service.² Die verwaltete Cloud startet schnell, und Shopware kümmert sich um Updates und Infrastruktur, aber sie ist, mit Shopwares eigenen Worten, stärker standardisiert und lässt weniger Spielraum für tiefe Anpassung, während das Modell Platform as a Service auf Händler zielt, die individuelle Anpassungen und eine eigene Serverinfrastruktur benötigen.⁴ Die Linie, auf die es bei einem Wechsel ankommt, ist eigener Code: Plugins, also Modifikationen am Kern in PHP, laufen auf dem selbst gehosteten Modell und auf Platform as a Service, nicht auf der verwalteten Cloud. Bist du in der verwalteten Cloud und verlangt dein Wachstum nun eigene Logik, hast du die Decke, die Shops zum vollständigen Besitz der Anwendung treibt, bereits erreicht.

Die Wahrheit über Export und API

Hier ist Shopware wirklich gut, und das spiele ich nicht herunter. Ein Wechsel weg von einem selbst gehosteten Shopware beginnt aus einer starken Position, denn du hast echten Zugriff auf deine eigenen Daten.

Die eingebaute Funktion Import/Export in der Administration bewältigt den Großteil eines Katalogumzugs. Sie arbeitet mit CSV, mit den Dateien in UTF-8 und durch Semikola getrennt, und sie liefert Standardprofile mit, die du duplizieren und anpassen kannst.⁵ Die Objekttypen, die sie abdeckt, sind umfangreich: Produkte, Variantenkonfiguration, Kategorien, Kunden, Bestellungen, Medien, Eigenschaften, Cross Selling, erweiterte Preise, Newsletterempfänger, Aktionen und Aktionscodes.⁵ Ein Profil ordnet jede Spalte der CSV einem Feld in der Datenbank zu, und genau diese Zuordnung steckt unter jeder Migration.⁵

Zwei Grenzen solltest du kennen, bevor du dich darauf stützt. Der Import ergänzt Informationen, er entfernt sie nicht, er ist also ein Ladewerkzeug und keine Synchronisation in beide Richtungen.⁵ Und die Historie von Import und Export in der Administration reicht nur 30 Tage zurück, sie ist ein Arbeitswerkzeug und kein Prüfprotokoll.⁵ Keines davon ist ein Mangel. Es ist schlicht die Form der Funktion, und eine Migration plant darum herum.

Für alles, was die CSV Funktion nicht erreicht, stellt Shopware zwei HTTP APIs bereit.⁶ Die Admin API unter dem Pfad /api bietet CRUD Operationen für jede Entität im System, darunter Produkte, Bestellungen, Kunden, Medien und Konfiguration, authentifiziert über OAuth mit Client Credentials, und sie ist für Integration im Hintergrund und Datensynchronisation gebaut.⁶⁷ Die Store API unter /store-api ist die kundenseitige Oberfläche, gebaut, damit Headless Frontends wie Single Page Apps oder native Apps den Shop über JSON ansprechen.⁶⁸ Hinzu kommt eine Sync API für Massenschreibvorgänge.⁶ Für eine Migration zählt die Admin API, denn mit ihr lese ich den langen Rest aus, den die CSV Profile nicht sauber abbilden, und prüfe die Zahlen laufend gegen die Quelle.

Auf einer selbst gehosteten Community Edition kommt der direkte Zugriff auf die Datenbank hinzu, und das ist die stärkste Exportlage überhaupt: dir wird nichts vorenthalten, weil du die Datenbank selbst hältst. Die verwaltete Cloud ist der schwächere Fall, in dem du über die Administration und die APIs arbeitest statt über die Datenbank, also kläre deinen Exportweg früh, wenn du in der Cloud sitzt. Passwörter sind das Einzige, das durch all das nicht als wiederverwendbares Geheimnis reist, aus demselben Grund auf jeder Plattform. Warum das so ist und was du dagegen tust, steht im Leitfaden zu Kundenkonten. Kurz gesagt vergeben die Kunden ihr Passwort einmal neu, als geplanter Schritt und nicht als Überraschung.

Die Fallen, die nur Shopware hat

Ein guter Export bedeutet keinen sauberen Ausstieg. Die Fallen liegen in den Teilen, die die CSV nie berührt.

Zahlungen leben in Handlern und Gateways, nicht in deiner Datenbank. Shopware verarbeitet Karten und lokale Zahlungsarten über Payment Handler, die mit einem Gateway sprechen, und die gespeicherten Karten und Token hinter wiederkehrenden Zahlungen oder dem Bezahlen mit einem Klick gehören diesem Gateway, nicht dem Shop. Sie kommen in keiner CSV heraus, und sie gehören nicht dir zum Kopieren. Ob sie überhaupt umziehen können, hängt vom Gateway ab, und das ist die einzige härteste Frage der gesamten Migration. Die ehrlichen Wege, vom erneuten Anschluss desselben Gateways bis zur geplanten Neueingabe, stehen im Leitfaden zu Zahlungstoken. Markiere das am ersten Tag und nicht in der letzten Woche.

Abos sind ein Plugin oder eine kommerzielle Funktion. Shopware trägt die wiederkehrende Abrechnung nicht im kostenlosen Kern, sie stammt aus einer Erweiterung oder steckt im bezahlten Funktionsumfang. Das heißt, die Abo Verträge, ihre Abrechnungstermine, ihre hinterlegten Mandate und die nächste Belastung liegen alle in den Tabellen eines bestimmten Plugins oder in einem Gateway, in einer Form, die nur diesem Plugin eigen ist. Einen allgemeinen Export dafür gibt es nicht. Laufende Abos umzuziehen, ohne eine einzige Belastung zu unterbrechen, ist die heikelste Arbeit jeder Migration, und ich behandle sie als eigenes Projekt im Umzug. Der Leitfaden zu Abonnements arbeitet ihn durch.

SEO URLs und der Weiterleitungsplan. Shopware erzeugt seine eigenen SEO URLs, und an einem wachsenden Shop hängen Jahre an Links und Rankings. Geht dieser Plan beim Umschalten verloren, verlierst du Besuche, die im Dashboard so wirken, als liefe der neue Shop schlechter. Jede alte URL, die einen Besuch oder einen Link verdient hat, braucht eine dauerhafte Weiterleitung auf ihr neues Ziel. Das ist eine Tabelle mit einer benannten verantwortlichen Person, und es ist das beste Geld im ganzen Projekt. Die Mechanik steht im Leitfaden zu Produkt und Katalogdaten, der die Weiterleitungsarbeit abdeckt, weil Produkt und Kategorie URLs den Großteil davon stellen.

Plugins halten Geschäftslogik, von der du nicht mehr weißt, dass du von ihr abhängst. Das Ökosystem ist Shopwares Stärke und zugleich seine Bindung. Über einige Jahre sammelt ein Shop Plugins für Preisregeln, Rechtstexte, Feeds, eine Kassenanbindung, eine Anbindung an ein ERP und das genaue Verhalten des Checkouts an. Nichts davon steht in der Katalog CSV. Jedes Plugin ist ein kleiner Lieferant, von dem du abhängst, und manche verschlüsseln Regeln, die niemand sonst irgendwo niedergeschrieben hat. Vor jedem Umzug erfasse ich sie und entscheide für jedes, ob das Verhalten als Anwendungscode neu gebaut, durch einen Dienst ersetzt oder gestrichen wird, weil es sich nicht länger lohnt.

Wie der Umzug auf Solidus wirklich aussieht

Die ehrliche Form des Umzugs ist diese: Katalog und Kunden kommen mit Zuordnungsarbeit mit, die Bestellungen kommen als lesbare Historie mit, und Zahlungen, Abos, Storefront und Integrationen werden neu gebaut. Die Tabelle zeigt am schnellsten, wo jede Sache sitzt.

Solidus ist der Ort, an dem ich das lande. Es ist ein quelloffenes Commerce Framework auf Ruby on Rails, lizenziert unter der BSD Lizenz mit drei Klauseln, und es bringt eine REST API mit, sodass der Shop, der dir gehört, auch eine mobile App oder eine zweite Storefront versorgen kann, ohne eine höhere Stufe zu buchen.⁹ Der ehrliche Preis ist, dass es keinen Theme Store und keinen Marktplatz mit Hunderten Plugins gibt, das erste Jahr also mehr kostet als zu bleiben, und du eine Entwicklerin brauchst, die Rails beherrscht. Dafür bekommst du eine Anwendung ohne Lizenzgebühr, ohne Planstufe, die deinen eigenen Checkout freischaltet, und ohne eine Grenze von 1 Million Euro, die du überschreitest. Der Checkout, die Preisregeln, die Abo Logik: jedes ist gewöhnlicher Anwendungscode mit Tests, kein Plugin und kein Angebot. Das Geld über fünf Jahre halte ich ehrlich im Artikel zu den Gesamtkosten, und die Plattformen stelle ich nebeneinander, Shopware eingeschlossen, im Plattformvergleich. Für die Zahlungsarten hierzulande, ohne die ein Shop nicht auskommt, Kauf auf Rechnung, SEPA, EPS, gibt es einen eigenen Leitfaden.

Ein durchgerechnetes Beispiel

Nimm ein erfundenes Unternehmen: Nordwerk Ausrüstung (nordwerk.example), ein Leipziger Shop für Arbeitskleidung und Baustellenausrüstung mit Handel und Gewerbe, der dieses Jahr rund 2,4 Millionen Euro im Jahr online umsetzt. Er betreibt seit vier Jahren Shopware 6 Community Edition, selbst gehostet. Drei Dinge sind zusammengekommen. Der Umsatz liegt inzwischen über einer Million Euro, also verlangt die Fair Usage Policy einen bezahlten Plan, um Shopware Account und Store zu behalten, für den ein Angebot deutlich im vierstelligen Bereich pro Monat vorliegt.²³ Die Gewerbeseite will Preislisten pro Kunde und monatliche Rechnungen, die der aktuelle Plugin Stapel umständlich abbildet. Und der Inhaber will, dass der Shop Code mit einem internen Lagerwerkzeug teilt, was eine Produkt Roadmap nie vorrangig behandeln wird. Nichts davon spricht gegen Shopware. Es ist ein Shop, der einer gemieteten Decke entwachsen ist und das Gebäude besitzen will.

So würde ich es führen. In der Erhebung erfasse ich jedes Plugin und entscheide sein Schicksal, lege fest, wer auf Seite des Shops die Daten besitzt, und kläre die Zahlungsfrage zuerst: Nordwerk nutzt ein Gateway für Karten und einen eigenen Anbieter für den Rechnungskauf, und der Plan ist, dasselbe Karten Gateway an den neuen Shop anzuschließen, damit die gespeicherten Karten bleiben, was ich schriftlich bestätige, bevor alles andere anläuft. Katalog, Varianten, Kunden und drei Jahre Bestellhistorie kommen über die Import/Export Profile und die Admin API heraus, und ich lasse die Importskripte gegen eine Kopie der Livedaten so lange laufen, bis die Zahlen exakt der Shopware Administration entsprechen.⁵⁷ Storefront, die gewerblichen Preislisten und die Rechnungslogik entstehen als Solidus Anwendungscode mit ausführbaren Tests. Der Weiterleitungsplan, rund dreitausend Zeilen, wird aus der Suchauswertung gebaut und von einer benannten Person bei Nordwerk geprüft. Abos fallen hier nicht an, und gerade deshalb hat die ehrliche erste Frage Wochen gespart: der eine Ort, an dem sie sich hätten verbergen können, war ein Plugin für Nachbestellungen, und das war ein gespeicherter Warenkorb, kein Abrechnungsvertrag.

Das Umschalten liegt an einem Dienstagvormittag im ruhigsten Monat des Shops. Das alte Shopware bleibt genau so, wie es ist, 30 Tage lang als Rückfallebene, und erst dann hört Nordwerk auf, dafür zu zahlen. Das Ergebnis ist eine Rails Anwendung, die Nordwerk gehört, ohne Lizenzstufe darüber und ohne einen Account Zugang, der an der nächsten Umsatzmarke verloren gehen kann.

Wann du auf Shopware bleiben solltest

Mehreren Shops würde ich raten zu bleiben, und das sage ich lieber jetzt als nachdem du Geld ausgegeben hast.

Bleib, wenn du bequem unter der Grenze von 1 Million Euro liegst, dein Katalog klassisch ist und die Community Edition samt einer Handvoll Plugins leistet, was du brauchst. Du bekommst ein leistungsfähiges System ohne Lizenzgebühr, und ein eigener Bau wäre ein Aufwand ohne passenden Ertrag.² Bleib, wenn dein Team in der Shopware Administration produktiv ist und die einzige Klage das Abo ist, das du oberhalb der Fair Usage Grenze schuldest, und dieses Abo tragbar ist. Bleib vorerst, wenn du wenige Wochen vor deiner Hauptsaison stehst, eine Migration gehört in die ruhigen Monate und nie vor den Andrang.

Wechsle, wenn der Shop der Ort ist, an dem du dich behauptest, und die Plattform zu dem geworden ist, das dir im Weg steht: wenn eine bezahlte Planstufe dir Funktionen verkauft, die du nicht nutzt, nur um die eine freizuschalten, die du brauchst, wenn der Plugin Stapel Geschäftslogik hält, die du lieber besitzen und testen würdest, oder wenn du das Rails Modell willst, damit der Shop eine Anwendung unter deinen eigenen ist. Das ist ein echter Grund, und es ist der, für den ich baue.

Willst du eine zweite Meinung zu deinen eigenen Zahlen, bring sie in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Ich sage dir ehrlich, ob sich der Abschied von Shopware für dich rechnet, und wenn nicht, sage ich das auch.