Von Sylius zu einem eigenen Shop wechseln

Was Sylius ist, und warum das der fairste Artikel der Serie ist

Sylius ist ein quelloffenes Ecommerce Framework auf Basis von Symfony, dem PHP Anwendungsframework, veröffentlicht unter der freizügigen MIT Lizenz.¹ Du installierst es auf deinem eigenen Server, verbindest es mit einer MySQL, MariaDB oder PostgreSQL Datenbank, und der Code und die Daten gehören dir, zum Lesen, Ändern und Behalten.² Es gibt keinen Anbieter, der es abschalten kann, keine Umsatzbeteiligung und keine Tarifstufe, die dir deinen eigenen Checkout erst freischaltet. Wenn du auf Sylius bist und es dir gute Dienste leistet, ist die ehrliche Überschrift dieses Artikels kurz: Du solltest vermutlich bleiben. Hier gibt es nichts zu retten.

Ich sage das offen, weil es stimmt, und weil es der einzige Grund ist, warum der Rest des Artikels lesenswert ist. Der größte Teil der Migrationsserie handelt davon, eine Plattform zu verlassen, die dir etwas vorenthält: ein gehostetes System, das dir nur die Exporte gibt, die es selbst wählt, ein Theme, das du nicht mitnehmen kannst, ein Checkout, den du nicht anfassen darfst. Sylius ist nichts davon. Es ist ein Framework, das dir gehört, genau wie das, worauf ich baue, Solidus, ein Framework ist, das dir gehört. Der Unterschied zwischen beiden ist nicht der Besitz. Es ist Sprache und Ökosystem. Das ist also der eine Artikel der Serie, in dem ich keinen Vermieter mit einem Haus vergleiche. Ich vergleiche zwei Häuser, die beide dir gehören, gebaut von zwei verschiedenen Gewerken.

Dadurch ist die Entscheidung, Sylius zu verlassen, eine bewusste technische Wahl und keine Flucht, und der ganze Artikel ist in diesem Geist geschrieben. Ich werde genau sein bei dem, was Sylius gut macht, ehrlich bei den ein, zwei Dingen, die wirklich gebunden sind, und klar dabei, wer überhaupt nicht wechseln sollte.

Sylius und Solidus sind ebenbürtig, nicht Sieger und Verlierer

Hier ist der Rahmen, den ich dich bitten möchte festzuhalten, weil das Marketing rund um jede Migration ihn gerne verwischt. Sylius und Solidus sind dieselbe Art von Sache. Beide sind quelloffene Commerce Frameworks, die eine Entwicklerin zu einem Shop zusammensetzt und die dann dir gehören. Sylius ist in PHP auf Symfony geschrieben. Solidus ist in Ruby auf Rails geschrieben. Keines ist ein Produkt, das du installierst und zu einem fertigen Shop durchklickst, und beide geben dir Bestellungen, Produkte, Varianten, Lager, Aktionen, Zahlungen, Versand und Steuern als Bausteine mit einer Verwaltung darüber.²

Die eigentliche Entscheidung, wenn mich jemand nach dem Verlassen von Sylius fragt, lautet also nie "welches Framework ist besser", denn diese Frage hat keine ehrliche Antwort. Es ist eine Reihe viel praktischerer Fragen:

• In welcher Sprache und welchem Ökosystem lebt der Rest deines Unternehmens schon? Wenn deine internen Werkzeuge, dein Kundenportal und dein Team Ruby und Rails sind, teilt ein Rails Shop Code, Konventionen, Personalmarkt und Deployment mit all dem. Wenn sie PHP und Symfony sind, läuft dasselbe Argument andersherum, und es läuft darauf hinaus, auf Sylius zu bleiben.
• Wer wird für den Shop verantwortlich sein, und kannst du dafür jemanden einstellen? Ein Shop ist eine lange Beziehung zu dem, der ihn pflegt. Der entscheidende Faktor ist oft schlicht, in welchem Ökosystem du eine Entwicklerin finden und halten kannst, in deiner Nähe und zu einem Preis, der passt.
• Zieht der umgebende Stack in eine Richtung? Ein Unternehmen, das sich über alles, was es betreibt, auf Rails standardisiert, hat einen echten Grund, auch seinen Shop dort haben zu wollen, damit es eine Werkzeugkette gibt, einen Satz Tests, eine Art zu deployen, statt einer PHP Insel, die getrennt gepflegt wird.

Beachte, dass nichts davon "Sylius ist schlecht" heißt. Sylius ist ein ernstzunehmendes, aktiv entwickeltes Projekt. Version 2.0 kam im November 2024, die erste Hauptversion seit 2017, mit einer neu geschriebenen Bootstrap Verwaltung, Symfony UX im Storefront und einer modernen API.³ Die neueste stabile Version ist zum Zeitpunkt des Schreibens 2.3, die Symfony 8 unterstützt, und Punktversionen erscheinen stetig.⁴ Das Projekt ist auch gut abgesichert: In einem Ende 2025 vereinbarten und heuer abgeschlossenen Geschäft hat die Gruppe hinter Sylius gemeinsam mit BitBag PrestaShop übernommen, als Teil einer größeren europäischen quelloffenen Commerce Gruppe.⁵ Das ist ein Zeichen von Gesundheit, kein Grund zur Flucht. Ich erwähne es nur, damit du weißt, dass das Projekt nicht verschwindet, und damit dir niemand einen Wechsel mit der falschen Geschichte verkauft, Sylius sei aufgegeben.

Wenn die Antwort nach alledem immer noch Rails ist, lies weiter. Wenn nicht, schließ den Tab mit meinem Segen.

Was dir gehört, und das Wenige, das wirklich gebunden ist

Weil Sylius selbst gehostet und quelloffen ist, spricht die wichtigste Tatsache beim Verlassen ganz für dich: Es gibt nichts zu retten. Die Datenbank gehört dir, der Anwendungscode gehört dir, und eine Entwicklerin kann jede Tabelle und jede Zeile ohne die Erlaubnis von irgendwem lesen. Verglichen mit einer gehosteten Plattform, wo der schwere Teil einer Migration darin besteht, die Daten überhaupt herauszubekommen, hat ein Sylius Umzug kein Datenproblem zu lösen. Die Arbeit ist der Neubau des Verhaltens in einer neuen Sprache, nicht das Herauslösen von Informationen.

Die ehrliche Tabelle für Sylius sieht daher anders aus als die, die ich für eine gehostete Plattform zeichne. Fast alles steht in der Spalte "gehört dir". Nur eine kurze Liste ist gebunden, und selbst die ist locker gebunden.

Was	Auf Sylius	Wohin es auf Solidus geht
Produkte, Varianten, Optionen, Preise, Taxons, Bilder, Lager	Deins, in deiner eigenen Datenbank, direkt lesbar	Das Solidus Produktmodell, siehe Produkt und Katalogdaten
Kundenkonten und Adressen	Deins, aber Passwörter sind gehasht und nicht wiederverwendbar	Neu aufgebaut mit Reset oder Prüfung beim ersten Login, siehe Kundenkonten
Bestell und Kaufhistorie	Deins, vollständig	Eine nur lesbare Historie im neuen Shop
SEO Schlüssel und URLs	Deins, in deinen eigenen Tabellen	Eine Weiterleitungstabelle im neuen Shop
Zahlungskonfiguration und gespeicherte Karten	An das Gateway über Payum gebunden, nicht an Sylius	Neu aufgebaut rund um dein eigenes Gateway Konto, siehe Zahlungstoken
Sylius Plus Module, falls lizenziert	Kommerzielle Funktionen, die du neu umsetzt	Als eigener, getesteter Code gebaut
Eigene Plugins, Theme und Geschäftslogik	Deins in PHP, läuft aber nicht auf Rails	Neu umgesetzt und getestet in Ruby

Die zwei Zeilen, bei denen es sich zu verweilen lohnt, sind die letzten beiden und die zu den Zahlungen, weil sie die einzigen Stellen sind, an denen ein Sylius Shop etwas trägt, das man eine Bindung nennen könnte, und in jedem Fall ist sie mild.

Die Wahrheit über Export und API: es gibt kein Exportproblem

Das ist der Abschnitt, der auf einer gehosteten Plattform lang und angespannt ist und auf Sylius kurz und ruhig. Dir gehört die Datenbank, der stärkste Weg hinaus ist also schlicht ein Datenbankabzug. Alles, was der Shop weiß, liegt in von Doctrine verwalteten Tabellen, die eine Entwicklerin direkt lesen kann, und für einen großen Katalog oder eine komplexe Bestelltabelle ist das der Weg, den ich tatsächlich nehme, weil nichts versteckt und nichts wegsummiert ist.

Sylius liefert außerdem eine echte API, und hier lohnt sich Genauigkeit, denn das ist eine echte Stärke und keine widerwillige. Seit Version 2.0 werden die Verwaltung und das Storefront von einer einzigen API bedient, die auf API Platform aufsetzt, dem Symfony API Framework.³ Die Pfade liegen unter einem Versionspräfix und einem Kontext, verwaltende Operationen also unter /api/v2/admin/ und Storefront Operationen unter /api/v2/shop/, und die API veröffentlicht ihre eigene OpenAPI Spezifikation, erzeugt aus der laufenden Konfiguration, sodass die Dokumentation dem Code folgt, statt von ihm abzudriften.⁶ Anders gesagt, anders als bei einer gehosteten Plattform, wo du ein Exportformat rückentwickelst, hast du auf Sylius eine dokumentierte, hauseigene Schnittstelle über deine eigenen Daten, wann immer du eine willst.

Zwei ehrliche Anmerkungen. Erstens setzt Sylius dieser API kein plattformseitiges Ratenlimit, weil keine Plattform zwischen dir und ihr steht: Jede Grenze, an die du stößt, ist die deines eigenen Servers, die du kontrollierst. Das ist die Dividende von Open Source. Zweitens, und gerade weil die Datenbank direkt da ist, migriere ich einen Sylius Shop selten über die API. Für einen einmaligen Umzug ist ein direktes Lesen der Tabellen schneller und vollständiger, als eine API zu durchblättern. Die API zählt mehr für das, was danach kommt: Ein Solidus Shop bringt seine eigene REST API mit, wenn der Grund, warum du auf einem Framework bist, also eine mobile App, ein Marktplatz oder ein zweites Storefront ist, behältst du diese Fähigkeit auf der anderen Seite, und warum das die eigentliche Voraussetzung für eine App ist, habe ich in Headless und API first Solidus beschrieben.

Die Schlussfolgerung für Sylius ist ungewöhnlich für diese Serie: Der Umzug ist kein Datenextraktionsprojekt. Er ist ein Neuumsetzungsprojekt. Die Daten kommen fast per Definition sauber herüber. Was Zeit kostet, ist der Neubau des Verhaltens, das heute in PHP lebt, in Rails.

Passwörter ziehen nie um, und das ist gut so

Kein Passwort kommt in lesbarer Form herüber, weder von Sylius noch von irgendeiner fähigen Plattform, weil Sylius das Passwort selbst nie speichert. Die Authentifizierung läuft über die Security Komponente von Symfony, die jedes Passwort mit einem modernen Einwegverfahren wie bcrypt oder argon2id hasht und nur den Hash schreibt, nie das Passwort.⁷ Ein Hash lässt sich nicht in das Passwort zurückverwandeln, das ihn erzeugt hat, es gibt also nichts, was man übernehmen könnte und womit sich eine Kundin anmelden könnte, und das ist ein Merkmal eines sauber gebauten Shops, kein Verlust.

Der Plan drumherum ist der gewöhnliche, vollständig ausgeführt im Leitfaden zu Kundenkonten. Jedes Konto, mit Namen, Adressen und Bestellhistorie, wird im neuen Solidus Shop angelegt. Beim ersten Besuch setzt die Kundin entweder über einen Einmallink ein neues Passwort oder, falls du die alten Hashes mitnimmst, lässt den alten Hash einmal prüfen und dann still durch das Format des neuen Shops ersetzen, sodass sie es nie bemerkt. So oder so sieht nie jemand ein Passwort im Klartext, und das Konto, zu dem die Kundin zurückkehrt, hängt an ihrer gesamten Historie.

Wo die kleinen Bindungen tatsächlich sind

Weil die Daten frei sind, binden einen Sylius Shop wirklich nur die Teile des Verhaltens und die kommerziellen Funktionen, die darauf sitzen. Es sind drei, und jede verdient es, ehrlich benannt zu werden.

Die erste ist Sylius Plus. Das Framework selbst ist frei und MIT lizenziert, aber Sylius verkauft eine kommerzielle Edition, Sylius Plus, als Satz von Modulen, die du obendrauf lizenzierst: eine B2B Suite, eine Marktplatz Suite, erweiterte Mehrfachshops, Retourenverwaltung, Lager aus mehreren Quellen, Treue, rollenbasierten Verwaltungszugriff, Teillieferungen, Angebotsanfragen, einen Produktkonfigurator und Abonnements.⁸ Es ist eine modulare kommerzielle Lizenz, gelistet ab etwa 800 Euro im Jahr und nach deinem Onlineumsatz skaliert, wobei jedes Modul einzeln gekauft wird, wie du es brauchst.⁸ Wenn dein Shop von einem dieser Module abhängt, ist genau diese Fähigkeit das, was du neu umsetzt statt kopierst, denn es ist proprietärer Code, den du lizenzierst, statt ihn zu besitzen. Die gute Nachricht ist, dass genau das die Art von Funktionen sind, die ein Solidus Bau als vollwertigen Anwendungscode behandelt: eine Händlerpreisliste, einen Retourenablauf, Lager über mehrere Standorte. Sie werden Teil des Shops, der dir gehört, mit Tests, statt einer Lizenz, die du immer wieder verlängerst.

Die zweite sind die Plugins und die eigene Logik. Ein echter Sylius Shop mit Ehrgeiz ist Kern Sylius plus ein Stapel von Plugins und Bundles, teils öffentlich, teils für dich geschrieben, die die eigentlichen Regeln deines Geschäfts halten: wie Händlerkunden bepreist werden, die eigenwillige Rundung, auf der dein Buchhalter besteht, das Zusatzfeld an einer Bestellung, die Art, wie das Etikett eines bestimmten Transporteurs erzeugt wird. Diese Logik ist PHP, und PHP läuft nicht auf Rails. Sie muss gelesen, verstanden und neu gebaut werden. Auf einem gut gepflegten Sylius Shop ist das angenehme Arbeit, weil die Logik unter Versionskontrolle steht und oft Tests hat, das Gegenteil der Archäologie, zu der dich eine gehostete oder alte Plattform zwingt. Aber es ist trotzdem der Großteil des Projekts, und es ist der ehrliche Grund, warum ein Umzug von Framework zu Framework echtes Geld kostet, obwohl die Daten frei sind.

Die dritte sind die Zahlungen, die ich gesondert nehme, weil sie die eine Falle sind, die sich auf jeder Plattform gleich verhält.

Zahlungen und gespeicherte Karten

Sylius wickelt Zahlungen über Payum ab, eine PHP Zahlungsabstraktion, mit einem Gateway dahinter wie Stripe, PayPal, Adyen oder einem lokalen Acquirer.³ Was für eine Migration zählt, ist nicht, wie Sylius mit dem Gateway spricht, sondern wer die Karte hält. Die Antwort ist nie Sylius: Es ist dein Zahlungsanbieter. Sylius speichert eine Referenz, das Gateway speichert die Karte.

Diese eine Tatsache entscheidet, ob wiederkehrende Kunden ihre gespeicherten Karten behalten oder sie neu eingeben müssen. Wenn dein Shop Karten schon über sein eigenes Stripe Konto oder ein gleichwertiges belastet, gehören die gespeicherten Karten diesem Konto, und der neue Solidus Shop verbindet sich mit demselben Konto, sodass die Karten einfach dort bleiben, wo sie sind, und nichts verloren geht. Sitzen die Karten dagegen in einem Anbieter, den du nur über eine bestimmte Sylius Integration erreicht hast, bedeutet ihr Umzug eine Übertragung von Anbieter zu Anbieter, die der empfangende Verarbeiter nur von einem anderen Halter annimmt, der nach der höchsten Stufe des Kartensicherheitsstandards zertifiziert ist, und diese Übertragung schließt die Abonnements und die Zahlungshistorie neben den Karten nie ein.

Das ist das Wichtigste, was zuerst zu klären ist, nicht zuletzt, und der Leitfaden zu Zahlungstoken geht jeden Fall durch. Entscheide deinen Zahlungsanbieter, bevor eine Zeile des neuen Shops geschrieben ist, denn diese eine Entscheidung bestimmt, ob der Umzug für deine Kunden unsichtbar ist oder sie alle bittet, eine Karte neu einzugeben. Wenn dir das Thema Unbehagen bereitet, ist die versteckten Gefahren beim Wechseln von Payment Gateways die warnende Fassung. Wenn dein Sylius Shop auf wiederkehrender Basis verkauft, behandle die Abomandate als den härtesten Teil von allen und sprich sie am ersten Tag an, denn ein laufendes Mandat liegt beim Gateway und braucht zum Umzug oft dessen Mitwirkung.

SEO Schlüssel und die Weiterleitungsliste

Jedes Produkt, jede Taxon und jede Inhaltsseite auf einem Sylius Shop hat eine URL, und manche von ihnen tragen Jahre an Verlinkungen und Rankings. Die gute Nachricht ist wieder, dass diese Schlüssel in Tabellen liegen, die du direkt lesen kannst, der erste Entwurf einer Weiterleitungsliste ist also eine Datenbankabfrage statt eines Durchkrabbelns der Live Seite.

Die Disziplin danach ist auf jeder Plattform dieselbe, und sie ist die Stelle, an der die meisten Migrationen still Geld verlieren. Jede Adresse, die im letzten Jahr einen Besuch oder einen Link bekommen hat, muss mit einer dauerhaften Weiterleitung auf ihr neues Zuhause abgebildet werden, direkt auf die Endseite zeigend statt über eine Kette, und mindestens ein Jahr bestehen bleiben. Die ganze Methode, und warum der Rankingverlust, den man dem Umzug anlastet, fast immer verpasste Weiterleitungen sind und nicht der Umzug selbst, steht im Leitfaden zu Produkt und Katalogdaten. Auf den Shops, die ich baue, liegen die Weiterleitungen in der Anwendung selbst als bearbeitbare Tabelle, sodass sie jedes künftige Deployment überleben und deine eigenen Leute eine hinzufügen können, wenn sie in den Suchergebnissen eine verirrte entdecken.

Ein durchgerechnetes Beispiel

Machen wir es konkret mit einem erfundenen Shop. Mühlviertel Braubedarf (muehlviertelbraubedarf.example) ist ein Linzer Betrieb, der Hausbrauer Sets, Malze und Ausrüstung verkauft, mit einer gesunden Händlerseite, die Kleinbrauereien und Schanklokale auf Rechnung beliefert. Er macht rund 1,6 Millionen Euro Onlineumsatz, führt grob 4.000 Produkte, sobald Größen und Gebindemengen gezählt sind, und läuft seit vier Jahren auf Sylius. Der Shop ist nicht kaputt. Er funktioniert, die Daten sind sauber, und die Inhaberin mag es, dass er ihr gehört.

Was sich geändert hat, ist der Rest ihres Geschäfts. Über diese vier Jahre hat ihr Team eine Lager App, ein Händlerportal und ein Werkzeug zur Bestandsprognose gebaut, und alle drei sind Ruby on Rails, weil das die Sprache ist, in der die Entwicklerin arbeitet, die sie eingestellt hat und der sie vertraut. Der Shop ist nun das einzige PHP System, das sie betreibt. Jede Änderung daran bedeutet eine zweite Werkzeugkette, eine zweite Deployment Pipeline und in der Praxis einen zweiten Auftragnehmer, den sie nur für den Shop auf Abruf hält. Ihre Sylius Installation stützt sich außerdem auf zwei Plus Module, die B2B Suite für die Händlerpreise und das Abonnementmodul für einen monatlichen Malzklub, ein Teil ihres Shops ist also kommerzieller Code, den sie lizenziert statt besitzt. Sie hat entschieden, dass sie lieber einen Stack, eine verantwortliche Entwicklerin und eine eigene Anwendung hätte.

So läuft der Umzug, und beachte, wie ruhig vieles davon ist. Der saubere Teil kommt zuerst und beruhigt alle. Ein voller Datenbankabzug, und daraus bilden sich die 4.000 Produkte mit ihren Varianten, Preisen, Beständen und Bildern über ein paar Wochen sorgfältigen Abgleichs auf den Solidus Katalog ab. Die Kundendaten, einschließlich der Händlerkonten, kommen mit ihren Adressen und der Bestellhistorie herüber, Passwörter ausgenommen. Die Bestellhistorie wird als nur lesbare Referenz hereingeholt, drei Jahre tief, die älteren Datensätze im archivierten Export aufgehoben. Die SEO Schlüssel werden direkt aus der Datenbank in den ersten Entwurf der Weiterleitungsliste gelesen, etwa 5.000 Zeilen, die dann eine Person prüft.

Dann die Teile, die die eigentliche Arbeit kosten, angesprochen in Woche eins, nicht in Woche zehn. Die Händlerpreise, die in der Plus B2B Suite lagen, werden zu einer getesteten Funktion des neuen Shops, in Rails geschrieben, die ihre Preislogik mit dem Händlerportal teilt, das ihr Team schon gebaut hat. Der Malzklub, der am Plus Abonnementmodul und einem Payum Gateway hing, ist die zuerst gestellte Frage: Weil der Shop schon über sein eigenes Stripe Konto belastet, verbindet sich der neue Solidus Store mit demselben Konto, die gespeicherten Karten und die laufenden Mandate bleiben gültig, und was der gruseligste Teil hätte sein können, wird beherrschbar. Das eigene Plugin, das die Etiketten ihres Transporteurs erzeugte, wird gelesen, verstanden und neu gebaut. Zwölf Wochen nach dem ersten Workshop stellt Mühlviertel Braubedarf an einem ruhigen Dienstagmorgen um, lässt die alte Sylius Installation dreißig Tage unangetastet als Rückfalloption laufen und legt sie erst dann still. Ein Jahr später ist der Shop eine gepflegte Rails Anwendung neben der Lager App und dem Händlerportal, mit einer Entwicklerin, die das Ganze kennt, und ohne kommerzielle Modullizenzen zum Verlängern.

Dieses Beispiel ist erfunden, aber die Form ist die echte: Ein Sylius Umzug gelingt oder scheitert an der Neuumsetzung und der Zahlungsentscheidung, nie daran, die Daten herauszubekommen.

Der ehrliche Umzugsplan

Auf die Knochen reduziert läuft das Verlassen von Sylius für einen eigenen Solidus Shop so. Erstens, die Erhebung: Liste die Plugins und Bundles und schreib auf, was jedes wirklich tut, notiere, von welchen Sylius Plus Modulen du abhängst, wähle den Zahlungsanbieter und benenne die eine Person im Unternehmen, der die Daten gehören. Zweitens, der Bau: Stell den Solidus Shop auf, schreib die Importskripte und lass sie immer wieder gegen eine Kopie der echten Datenbank laufen, bis der Import langweilig ist. Drittens, bilde den Katalog und die Kunden ab, was auf Sylius der leichte Teil ist, und setze die Logik der Plugins und Plus Module als getestete Rails Funktionen neu um, was die eigentliche Arbeit ist. Viertens, bau die Weiterleitungsliste aus den Schlüsseltabellen und prüfe jede Zeile. Fünftens, ein Parallelbetrieb von ein paar Wochen mit eingefrorenem Katalog, mit zwei Proben des finalen Imports. Sechstens, stell an einem ruhigen Wochentagmorgen um, gib eine echte Testbestellung über jede Zahlungsart auf, prüf die wichtigsten Weiterleitungen von Hand und lass den alten Shop dreißig Tage als Rückfalloption, bevor du etwas stilllegst.

Durch alles hindurch gilt das Prinzip aus dem Pfeiler, was sich überträgt und was nicht: Zieh den Shop um, wie er ist, mach ihn stabil, und verbessere ihn erst dann. Eine Migration zugleich zu einem Redesign zu machen, verdoppelt das Risiko und macht es unmöglich zu sagen, welche Änderung einen Einbruch verursacht hat.

Wer auf Sylius bleiben sollte

Mir ist es lieber, die Arbeit zu verlieren, als dir einen Umzug zu verkaufen, den du nicht brauchst, und auf Sylius wiegt diese Warnung schwerer als irgendwo sonst in dieser Serie, weil Sylius ein gutes Framework ist, das dir schon gehört. Hier ist also, wann du bleiben solltest, und ich meine es ernst.

Bleib auf Sylius, wenn dein Team in PHP und Symfony investiert und damit zufrieden ist. Ein Framework Umzug lohnt sich, wenn er deinen Stack vereint, und er ist Verschwendung, wenn er ihn spaltet: ein zufriedenes Symfony Team auf Rails zu zerren oder eine Rails Entwicklerin einzustellen, die allein neben einem PHP Team sitzt, ist genau der Fehler, den dieser Artikel am liebsten verhindert. Bleib, wenn der Rest deines Geschäfts PHP ist, denn dann ist Sylius das System, das mit allem anderen eine Sprache teilt. Bleib, wenn dein Shop sich stark auf ein Sylius Plus Modul stützt, das genau das tut, was du brauchst, und du zufrieden bist, es zu lizenzieren. Bleib, wenn dich nichts tatsächlich blockiert und das einzige Jucken ist, dass Rails interessant aussieht, denn Interesse ist kein Geschäftsgrund.

Wechsle zu einem eigenen Solidus Shop, wenn der Zug echt ist: wenn der Rest deines Stacks Ruby und Rails ist und der Shop die einsame PHP Insel, wenn du eine verantwortliche Entwicklerin und eine Werkzeugkette statt zwei willst, wenn der Shop Code mit Rails Systemen teilen soll, die du schon betreibst, oder wenn du deine B2B, Retouren und Abofunktionen lieber selbst besitzt, als sie zu lizenzieren. Für die Geldseite dieser Entscheidung rechnet die Gesamtkosten über fünf Jahre beim Wechsel zu Solidus die Zahlen durch, der Plattformvergleich stellt die Optionen nebeneinander, und wem gehören eigentlich deine Geschäftsdaten ist das Prinzip darunter. Wenn du andere selbst gehostete Shops im selben Atemzug abwägst, habe ich denselben ehrlichen Leitfaden für das Verlassen von PrestaShop geschrieben, das übrigens inzwischen zur selben Gruppe gehört wie Sylius. Solidus selbst ist quelloffen unter der BSD Lizenz, der Shop, den ich dir baue, trägt also keine Lizenzgebühr und keine eigene Bindung.⁹

Der Workshop

Wenn du einen Sylius Shop führst und ernsthaft abwägst, ob du wechseln sollst, bring ihn in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Bring deine Pluginliste, deine Sylius Plus Lizenzen, falls du welche hast, und alles, was du über die eigene Logik weißt. Gemeinsam klären wir, was sauber umzieht, was das meiste ist, was in Rails neu umgesetzt werden muss, was die eigentlichen Kosten sind, und ob ein Umzug deinem Geschäft wirklich dient oder nur deiner Neugier. Weil Sylius und Solidus ebenbürtig sind, kann ich dir die geradeste Antwort der ganzen Serie geben, und ziemlich oft lautet sie, genau dort zu bleiben, wo du bist.

Footnotes

1. Sylius Quellcode Repository, das Sylius Ecommerce Framework auf Basis von Symfony, veröffentlicht unter der MIT License, Copyright Sylius Sp. z o.o., GitHub, geprüft am 14. November 2026, https://github.com/Sylius/Sylius ↩

2. Sylius Dokumentation, Before You Begin und Systemvoraussetzungen (selbst gehostet, PHP 8.2 oder höher mit den Erweiterungen gd, exif, fileinfo, intl und sodium, eine von MySQL 8.0, MariaDB 10.4.10 oder PostgreSQL 13.9, gebaut auf Symfony mit Doctrine ORM), geprüft am 14. November 2026, https://docs.sylius.com/public/getting-started/before-you-begin.md ↩ ↩²

3. Sylius, Sylius 2.0 is live (die erste Hauptversion seit 2017, eine neu geschriebene Bootstrap Verwaltung, Symfony UX im Storefront, eine vereinheitlichte API auf API Platform 4 und Zahlungen über bestehende Payum Gateways), 12. November 2024, https://sylius.com/blog/sylius-2-is-live/ ↩ ↩² ↩³

4. Sylius Releases, darunter v2.3.2 als neueste stabile Version und die 2.3 Reihe mit Unterstützung für Symfony 8, GitHub, geprüft am 14. November 2026, https://github.com/Sylius/Sylius/releases ↩

5. cyber_Folks, Abschluss der Übernahme von PrestaShop gemeinsam mit Sylius und BitBag, als europäische quelloffene Commerce Gruppe mit mehr als 700.000 Kunden, Investor Relations, geprüft am 14. November 2026, https://investors.cyberfolks.pl/en/?p=3794 ↩

6. Sylius Dokumentation, Customizing the API (eine vereinheitlichte API auf Basis von API Platform, verwaltende Operationen unter /api/v2/admin/ und Storefront Operationen unter /api/v2/shop/, mit einer aus der laufenden Konfiguration erzeugten OpenAPI Spezifikation), geprüft am 14. November 2026, https://docs.sylius.com/the-customization-guide/customizing-api ↩

7. Symfony Dokumentation, Hashing and verifying passwords (Passwörter werden über den auto Hasher mit einem modernen Einwegverfahren wie bcrypt oder argon2id gehasht, nie in lesbarer Form gespeichert), geprüft am 14. November 2026, https://symfony.com/doc/current/security/passwords.html ↩

8. Sylius Plus, die kommerzielle Edition (eine modulare kommerzielle Lizenz, gelistet ab etwa 800 Euro im Jahr und nach dem Onlineumsatz skaliert, mit Modulen wie einer B2B Suite, einer Marktplatz Suite, erweiterten Mehrfachshops, Retourenverwaltung, Lager aus mehreren Quellen, Treue, rollenbasiertem Zugriff, Teillieferung, Angebotsanfrage, einem Produktkonfigurator und Abonnements), geprüft am 14. November 2026, https://sylius.com/plus/ ↩ ↩²

9. Solidus Quellcode Repository, das Solidus Ecommerce Framework auf Ruby on Rails unter der BSD 3 clause License, GitHub, geprüft am 14. November 2026, https://github.com/solidusio/solidus ↩