Von Shopware zu einem eigenen Solidus Shop wechseln

Was Shopware ist, und wer es hinter sich lässt

Shopware 6 ist ein modernes, leistungsfähiges Shopsystem, und das will ich klar sagen, bevor ich irgendetwas anderes sage. Es ist eine offene Commerce Plattform auf Basis des Symfony Frameworks mit einer Administration in Vue, und sein Kern steht unter der permissiven MIT Lizenz.¹ Shopware ist stark in Österreich, Deutschland und der Schweiz, das Ökosystem kennt die rechtlichen Anforderungen im deutschsprachigen Raum, und fast jede Agentur in der Region arbeitet damit. Wenn du einen klassischen Katalog auf Shopware betreibst und er seine Arbeit tut, ist dieser Artikel kein Grund zu wechseln. Ein kleiner oder mittelgroßer Shop bleibt sehr oft zu Recht, wo er ist.

Das Unternehmen, für das ich schreibe, ist jenes, das Shopware entwachsen ist. Meist flieht diese Inhaberin nicht vor einer schwachen Software. Sie jagt etwas Konkretes: die volle Kontrolle über den ganzen 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 ist, die ihr von Anfang bis Ende gehört, statt ein Produkt, das der Roadmap eines anderen folgt. Das ist der ehrliche Leitfaden für 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 führe die Migration durch, und das Ergebnis gehört dir.

Für die Konzepte, die gleich bleiben, egal von wo du wechselst, wie Kundendaten umziehen, was mit Produkten und URLs passiert, warum gespeicherte Karten und Abos das Harte sind, verlinke ich die tiefen Leitfäden, statt sie zu wiederholen. Beginne mit der Säule, was sich überträgt und was nicht. Dieser Artikel dreht sich um Shopware selbst: seine Editionen, seinen Export und seine Fallen.

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

Der Aufbau von Shopware ist das Erste, das du verstehen solltest, denn dort entsteht der meiste Druck zu wechseln. Es gibt einen offenen Kern und eine Leiter kostenpflichtiger Pläne darüber.²

Die Community Edition ist kostenlos, mit null ausgewiesen, und ihr Kern ist quelloffen unter der MIT Lizenz.²¹ Darüber stehen 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 kostenpflichtigen Pläne ergänzen Funktionen wie Retourenmanagement, erweiterte Produktsuche, B2B Komponenten wie Angebote und Freigabeprozesse und kundenspezifische Preise, und Shopware hält fest, dass der Preis sich am Bruttowarenwert und weiteren individuellen Faktoren orientiert.² Die gedruckten Zahlen sind also eine Untergrenze, kein Angebot.

Es gibt eine Bedingung an der kostenlosen Edition, die Inhaber oft erfüllen, ohne damit zu planen. Nach Shopwares Fair Usage Policy muss ein Unternehmen, dessen verknüpfte Shops über die vorangegangenen 365 Tage 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 ist eindeutig, dass sie die Open Source Lizenz nicht berührt: die Community Edition bleibt vollständig quelloffen unter MIT, du behältst den vollen Zugriff auf den Quellcode und kannst die Software unabhängig weiterbetreiben.³ Was ein Shop oberhalb der Grenze ohne bezahlten Plan verliert, ist der Account und der Extension Store, nicht der Code. Das ist eine faire Unterscheidung, und sie ist es wert, sorgfältig gelesen zu werden, nicht durch die Zusammenfassung eines Anbieters und nicht durch die eines Mitbewerbers.

Dann ist da die Wahl des Betriebsmodells, die entscheidet, wie viel vom Stack wirklich 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 ist schnell gestartet, und Shopware übernimmt Updates und Infrastruktur, aber sie ist, in Shopwares eigenen Worten, stärker standardisiert und bietet weniger Spielraum für tiefe Anpassung, während das Modell Platform as a Service für Händler gedacht ist, die individuelle Anpassungen und eine eigene Serverinfrastruktur brauchen.⁴ Die Linie, die für einen Wechsel zählt, 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. Wenn du in der verwalteten Cloud bist und dein Wachstum nun eigene Logik verlangt, hast du die Decke, die Shops zum vollen Besitz der Anwendung drängt, bereits erreicht.

Die Wahrheit über Export und API

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

Die eingebaute Funktion Import/Export in der Administration erledigt den Großteil eines Katalogumzugs. Sie arbeitet mit CSV, mit den Dateien in UTF-8 und durch Semikola getrennt, und sie bringt Standardprofile mit, die du duplizieren und anpassen kannst.⁵ Die Objekttypen, die sie abdeckt, sind breit: Produkte, Variantenkonfiguration, Kategorien, Kunden, Bestellungen, Medien, Eigenschaften, Cross Selling, erweiterte Preise, Newsletterempfänger, Aktionen und Aktionscodes.⁵ Ein Profil bildet jede Spalte der CSV auf ein Feld in der Datenbank ab, und genau das ist die Zuordnungsarbeit, die unter jeder Migration steckt.⁵

Zwei Grenzen solltest du kennen, bevor du dich darauf verlässt. Der Import fügt Informationen hinzu, 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 zeigt nur die letzten 30 Tage, sie ist also ein Arbeitswerkzeug, kein Prüfprotokoll.⁵ Keines davon ist ein Fehler. Es ist einfach 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.⁶⁸ Es gibt zusätzlich eine Sync API für Massenschreibvorgänge.⁶ Für eine Migration zählt die Admin API, denn sie lässt mich den langen Rest auslesen, den die CSV Profile nicht sauber abbilden, und die Zahlen laufend gegen die Quelle prüfen.

Auf einer selbst gehosteten Community Edition hast du zusätzlich direkten Zugriff auf die Datenbank, 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 bist. Passwörter sind das Eine, das durch nichts davon als wiederverwendbares Geheimnis reist, aus demselben Grund auf jeder Plattform. Warum, und was du dagegen tust, steht im Leitfaden zu Kundenkonten. Kurz gesagt setzen die Kunden ihr Passwort einmal neu, als geplanter Schritt, 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. Die kommen nicht in einer 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 ganzen Migration. Die ehrlichen Möglichkeiten, vom erneuten Anschluss desselben Gateways bis zur geplanten Neueingabe, stehen im Leitfaden zu Zahlungstoken. Markiere das am ersten Tag, nicht in der letzten Woche.

Abos sind ein Plugin oder eine kommerzielle Funktion. Shopware trägt die wiederkehrende Abrechnung nicht im kostenlosen Kern, sie kommt aus einer Erweiterung oder steckt im kostenpflichtigen 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 diesem Plugin eigen ist. Es gibt keinen allgemeinen Export dafür. 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 geht ihn durch.

SEO URLs und der Weiterleitungsplan. Shopware baut seine eigenen SEO URLs, und an einem wachsenden Shop hängen Jahre an Links und Rankings. Verlierst du diesen Plan beim Umschalten, verlierst du Besuche, die im Dashboard aussehen, 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, das du im Projekt ausgibst. Die Mechanik steht im Leitfaden zu Produkt und Katalogdaten, der die Weiterleitungsarbeit abdeckt, weil Produkt und Kategorie URLs den Großteil davon ausmachen.

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 ein paar Jahre sammelt ein Shop Plugins für Preisregeln, Rechtstexte, Feeds, eine Kassenanbindung, eine Anbindung an ein ERP und das genaue Verhalten des Checkouts. 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 aufgeschrieben 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 mehr 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 jedes Ding sitzt.

Weg von Shopware zu einem eigenen Solidus Shop: was mitkommt, was gebunden ist, und der Plan

Daten oder Funktion	Auf Shopware	Der Plan auf Solidus
Produkte, Varianten, Kategorien, Preise, Medien	Exportieren sauber als CSV über Import/Export Profile oder die Admin API[^7]	Auf den Solidus Katalog abbilden, siehe den Produkt Leitfaden
Kundenkonten und Adressen	Export als CSV, ohne die Passwörter[^7]	Importieren, dann ein einmaliges Zurücksetzen des Passworts, siehe den Kunden Leitfaden
Bestell und Kaufhistorie	Als Objekttyp im Export verfügbar[^7]	Als schreibgeschützte Historie für Support und Kundenkonto laden
Gespeicherte Karten und Zahlungstoken	Beim Gateway gehalten, nicht in deiner Datenbank	Wo möglich dasselbe Gateway wieder anschließen, sonst Neueingabe planen, siehe den Token Leitfaden
Abos und wiederkehrende Abrechnung	In einem Plugin oder dem kommerziellen Funktionsumfang, kein allgemeiner Export	In Solidus mit Mithilfe des Gateways neu bauen, siehe den Abo Leitfaden
SEO URLs	Shopwares eigene URL Struktur	Ein vollständiger Weiterleitungsplan, eine Zeile pro alter URL
Storefront, Plugins, Integrationen	Shopware Theme, Plugins, App Logik	Neu gebaut als Rails Anwendung, die ganz dir gehört

Solidus ist, wo 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 speisen 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 kann. 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 im deutschsprachigen Raum, ohne die ein Shop hier nicht auskommt, Kauf auf Rechnung, SEPA, EPS, gibt es einen eigenen Leitfaden.

Ein durchgerechnetes Beispiel

Nimm ein erfundenes Unternehmen: Alpenwerk Ausrüstung (alpenwerk.example), ein Linzer Shop für Arbeitskleidung und Baustellenausrüstung mit Handel und Gewerbe, der heuer 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 nun ü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 löst. Und der Inhaber will, dass der Shop Code mit einem internen Lagerwerkzeug teilt, was eine Produkt Roadmap nie vorrangig behandeln wird. Nichts davon ist Shopware als schwach. 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: Alpenwerk 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 beginnt. 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 werden als Solidus Anwendungscode mit ausführbaren Tests gebaut. Der Weiterleitungsplan, rund dreitausend Zeilen, entsteht aus der Suchauswertung und wird von einer benannten Person bei Alpenwerk geprüft. Abos fallen hier nicht an, und genau deshalb hat die ehrliche erste Frage Wochen gespart: der eine Ort, an dem sie sich hätten verstecken 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 Alpenwerk auf, dafür zu zahlen. Das Ergebnis ist eine Rails Anwendung, die Alpenwerk 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 tut, was du brauchst. Du bekommst ein leistungsfähiges System ohne Lizenzgebühr, und ein eigener Bau wäre ein Kosten ohne passenden Ertrag.² Bleib, wenn dein Team in der Shopware Administration produktiv ist und die einzige Klage das Abo ist, das du über der Fair Usage Grenze schuldest, und dieses Abo tragbar ist. Bleib vorerst, wenn du 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 kauft, die du nicht nutzt, 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.

Wenn du eine zweite Meinung zu deinen eigenen Zahlen willst, 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.

Footnotes

1. Shopware, Repository shopware/shopware auf GitHub: offene Commerce Plattform auf Symfony und Vue, Kern unter der MIT Lizenz, abgerufen am 14. November 2026, https://github.com/shopware/shopware ↩ ↩²

2. Shopware, Pricing: Editionen (Community Edition, Rise, Evolve, Beyond), ausgewiesene Monatspreise ohne Umsatzsteuer, Betriebsmodelle (SaaS, PaaS, selbst gehostet) und das FAQ zur Fair Usage Policy, abgerufen am 14. November 2026, https://www.shopware.com/en/pricing/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

3. Shopware, Fair Usage Policy: key facts for Community Edition merchants (die Bedingung von 1 Million Euro Bruttowarenwert über die vorangegangenen 365 Tage, und dass die Richtlinie die quelloffene MIT Lizenz nicht berührt), März 2025, https://www.shopware.com/en/news/fair-usage-policy-community-edition/ ↩ ↩² ↩³

4. Shopware, Shopware in der Cloud: SaaS stärker standardisiert mit weniger Spielraum für tiefe Anpassung, PaaS für Händler mit individuellen Anpassungen und eigener Infrastruktur, abgerufen am 14. November 2026, https://docs.shopware.com/en/shopware-6-en/in-the-cloud ↩

5. Shopware, Dokumentation zu Import/Export: CSV in UTF-8 mit Semikola, Profile und Zuordnungen, die abgedeckten Objekttypen, dass der Import ergänzt und nicht entfernt, und eine Historie von 30 Tagen, abgerufen am 14. November 2026, https://docs.shopware.com/en/shopware-en/settings/importexport ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

6. Shopware Entwicklerdokumentation, Integrations API Übersicht: die Admin API, die Store API und die Sync API, abgerufen am 14. November 2026, https://developer.shopware.com/docs/guides/integrations-api ↩ ↩² ↩³ ↩⁴

7. Shopware Entwicklerdokumentation, Konzept der Admin API: CRUD Operationen für jede Entität, für Integration im Hintergrund und Synchronisation, abgerufen am 14. November 2026, https://developer.shopware.com/docs/concepts/api/admin-api ↩ ↩²

8. Shopware Entwicklerdokumentation, Konzept der Store API: die kundenseitige Oberfläche für Headless Frontends, abgerufen am 14. November 2026, https://developer.shopware.com/docs/concepts/api/store-api ↩

9. Solidus, Repository solidusio/solidus auf GitHub: ein quelloffenes Commerce Framework auf Ruby on Rails unter der BSD Lizenz mit drei Klauseln, das eine REST API mitbringt, abgerufen am 14. November 2026, https://github.com/solidusio/solidus ↩