Shopware 5 läuft aus: Der Upgrade-Pfad auf Shopware 6 und die Frontend-Frage

Der End-of-Life-Druck auf Shopware 5 steigt spürbar. Viele DACH-Bestandsshops laufen noch auf der alten Version, und für sie ist der Umstieg auf Shopware 6 keine Option mehr, sondern eine Frage des Wann. Was dabei oft unterschätzt wird: Ein Shopware-5-zu-6-Upgrade ist kein gewöhnliches Versions-Update. Es ist faktisch ein Replatforming, und genau deshalb ist der Moment des Umstiegs auch der Moment, in dem du über deine Frontend-Strategie mitentscheidest, ob du willst oder nicht.

Dieser Beitrag zeigt, was der Upgrade-Pfad konkret bedeutet, wo die größten Kostenblöcke liegen, und warum du die Frontend-Entscheidung jetzt bewusst treffen solltest statt sie im Theme-Rewrite untergehen zu lassen.

Warum Shopware 5 auf 6 ein Replatforming ist, kein Update

Wer einmal von Shopware 5 auf 6 gewechselt hat, kennt die unangenehme Wahrheit: Es gibt keinen sanften Migrationspfad. Die Architektur hat sich grundlegend geändert, und das hat handfeste Folgen:

• Kein Plugin aus Shopware 5 läuft unter Shopware 6. Jede Erweiterung muss neu entwickelt oder ersetzt werden, oft mit Subscription-Modell statt Einmal-Kauf. Ein typischer Shop hat 20 bis 50 Plugins, jedes davon ist ein Migrationsposten.
• Der Theme-Code ist komplett neu. Shopware 6 nutzt Twig statt Smarty und ein neues Theme-Inheritance-System. Dein altes Storefront-Theme ist nicht portierbar, es wird neu gebaut.
• DACH-Sonderlasten kommen obendrauf. Mehrwertsteuer-Logik, Kundengruppen, rechtliche Pflichtseiten, Consent-Setup und mehrsprachiges Routing scheitern regelmäßig an Details und treiben den Aufwand.

In Summe bedeuten das für mittelständische Shops typischerweise 10.000 bis 50.000 Euro und drei bis acht Monate Projektlaufzeit. Das ist die Größenordnung eines Replatformings, und es erklärt, warum viele Customer in diesem Moment fragen: Wenn ich ohnehin so viel anfassen muss, warum dann nicht gleich auf ein anderes Backend wechseln? Diese Frage ist berechtigt, aber sie führt für die meisten Shopware-Händler in die falsche Richtung, denn das Backend ist selten das eigentliche Problem.

Die eigentliche Entscheidung steckt im Frontend

Der teuerste und riskanteste Teil eines Shopware-5-zu-6-Upgrades ist nicht die Backend-Migration. Es ist der Theme-Rewrite. Genau hier liegt die Entscheidung, die du jetzt bewusst treffen solltest: Baust du dein Storefront erneut als klassisches Twig-Theme, das beim nächsten großen Versionssprung wieder zur Last wird? Oder entkoppelst du die Frontend-Schicht von Shopware, sodass das Backend austauschbar bleibt und der Theme-Aufwand einmalig wird?

Die zweite Variante ist der Kern von Composable Commerce, und für Shopware-Händler ist sie überraschend pragmatisch. Statt das Frontend in Shopware-Templates zu binden, setzt du eine Frontend-Schicht auf die Shopware-Store-API und steuerst Storefront, Kampagnen und Content unabhängig vom Backend. Die Grundlagen dieses Wegs haben wir in unserer Schritt-für-Schritt-Anleitung zur Shopware-Headless-Migration beschrieben.

Der entkoppelte Upgrade-Pfad: Frontend zuerst

Die elegante Reihenfolge dreht das klassische Upgrade-Projekt um. Statt Backend und Frontend gleichzeitig zu migrieren, gehst du in zwei sauber getrennten Schritten vor:

1. Frontend entkoppeln, bevor das Backend migriert. Eine Frontend Management Platform (FMP) wie Laioutr setzt sich auf deine bestehende Shopware-Store-API und liefert das Storefront. Marketing baut Pages im Editor mit Live-Preview, Engineering reviewt und erweitert über Components. Das Frontend ist damit unabhängig von der Shopware-Version.
2. Shopware 5 auf 6 isoliert migrieren. Weil das Frontend über die FMP läuft, betrifft das Backend-Upgrade nur die Commerce-Engine. Beim Umstieg wechselt im Wesentlichen die Connector-Anbindung, nicht das gesamte Storefront. Kein Theme-Rewrite, kein doppelter Plugin-Theme-Aufwand.

Der praktische Gewinn: Du trennst zwei Risiken, die sonst gleichzeitig auf dich zukommen. Das Frontend ist schon live und stabil, bevor du am Backend arbeitest, und der Backend-Wechsel wird zu einem überschaubaren, isolierten Projekt. Details zu den Routen und der Architektur findest du auf unserer Shopware-Headless-Frontend-Seite.

Was du beim Upgrade konkret gewinnst

Wer die Frontend-Schicht beim Shopware-Upgrade entkoppelt, löst nicht nur das Migrationsproblem, sondern auch eine Reihe von Dauer-Pains der Shopware-Frontend-Welt:

• Multi-Brand und Multi-Country auf einer Codebasis statt geforkter Themes pro Marke. Ein Fix ist überall live.
• Core Web Vitals ab Werk statt suboptimaler Twig-Theme-Performance. Mehr dazu auf unserer Performance-Seite.
• BFSG- und WCAG-Konformität ab Werk, sodass du dir den separaten Accessibility-Sprint sparst, der seit der BFSG-Pflicht ohnehin ansteht.
• Time-to-Market in Stunden statt Sprints, weil Marketing Landing-Pages direkt im Studio baut statt über Theme-Tickets.

Fazit: Die Frontend-Frage nicht dem Theme-Rewrite überlassen

Das Shopware-5-EOL zwingt zu einer Entscheidung, und das ist eine Chance. Wenn du ohnehin migrieren musst, ist es der richtige Moment, die Frontend-Schicht so aufzustellen, dass der nächste große Versionssprung kein erneutes Replatforming auslöst. Behalte Shopware als Commerce-Engine, entkopple das Frontend, und halte deine Architektur reversibel.

Wenn du vor dem Shopware-Upgrade stehst und wissen willst, wie der entkoppelte Pfad für deinen Shop konkret aussieht, sprich mit uns über dein Shopware-Frontend. Wir schauen auf deinen Plugin- und Theme-Stand und sagen dir ehrlich, wo Decoupling sich rechnet und wo nicht.