Shopware 5 ist am 31. Juli 2024 aus dem aktiven Support gefallen. Das war vor 2 Jahren. Wenn Ihr Shop heute noch Shopware 5 fährt, betreiben Sie produktive Software ohne Support, und das Risiko steigt gleichzeitig auf drei Ebenen: Sicherheit, Infrastruktur und das Plugin-Ökosystem, von dem Ihr Shop abhängt.
Zwei Jahre freundliche Erinnerungen sind bereits vorbei. Hier kommt die ehrliche Bestandsaufnahme: was Sie tatsächlich betreiben, warum jeder weitere Monat die Migration erschwert, und wie ein realistischer Weg nach Shopware 6 aussieht, basierend auf Migrationen, die ich persönlich umgesetzt habe.
Wann hat Shopware 5 das End-of-Life erreicht?
Shopware 5 hat am 31. Juli 2024 offiziell das End-of-Life erreicht. Laut offizieller Shopware-Dokumentation gilt seither ein rein reaktives Modell: Shopware untersucht Sicherheitsprobleme, die Kunden aktiv melden, und liefert bei Bedarf einen Bugfix. Proaktive Sicherheitsupdates, neue Features und aktive Entwicklung sind komplett eingestellt. Jeder Shop, der noch Shopware 5 betreibt, läuft ohne Hersteller-Support weiter.
Ist Shopware 5 im Jahr 2026 noch sicher?
Nein, nicht in einem sinnvollen Sinn. Sicherheit ist eine Funktion der Zeit. Wie lange ist diese Software ohne proaktives Security-Review geblieben, und wie viele Schwachstellen wurden seitdem in ihren Abhängigkeiten gefunden?
End-of-Life heisst: niemand scannt Shopware 5 mehr proaktiv auf Schwachstellen. Probleme werden nur noch behoben, wenn Kunden sie aktiv melden. Parallel hat sich der wirtschaftliche Anreiz umgekehrt. Eine Schwachstelle zu finden und verantwortungsvoll zu melden, bringt 2026 nichts. Eine Schwachstelle zu finden und an eine kriminelle Gruppe zu verkaufen, bringt echtes Geld.
Für Auditoren ist die Rechnung einfacher. PCI DSS Anforderung 6.3.3 verlangt, dass alle Systemkomponenten zeitnah durch Sicherheits-Patches gegen bekannte Schwachstellen geschützt werden. Nicht unterstützte Software kann diese Anforderung nicht erfüllen, weil keine Patches mehr erscheinen. Dass Ihr Zahlungsdienstleister die Kartendaten tokenisiert, ändert nichts daran. Sitzt ungepatchte Software auf einer Ebene, die die Cardholder Data Environment berührt, schreibt der Auditor einen Befund. Ich habe das in jährlichen Reviews gesehen und beobachtet, wie Agenturen in 3 Wochen eine Migrations-Roadmap bauen mussten, um den PCI-DSS-Status des Kunden zu retten.
Die DSGVO ist das leisere Risiko. Artikel 32 verlangt “geeignete technische und organisatorische Massnahmen” zum Schutz personenbezogener Daten, “unter Berücksichtigung des Stands der Technik”. Software 2 Jahre nach End-of-Life zu betreiben, scheitert an beiden Kriterien. Wenn ein Breach passiert, fragt die Aufsichtsbehörde, wann Sie wussten, dass die Software nicht mehr unterstützt wird, und was Sie dagegen unternommen haben. “Wir wussten es seit Juli 2024 und haben nichts getan” ist die schlechteste denkbare Antwort.
Die produktive Frage für einen Shopware-5-Händler im Jahr 2026 ist, wie man die nächsten 6 Monate verbringt. Jede Agenturstunde, die in die Verlängerung der Shopware-5-Lebenszeit fliesst, ist eine Stunde, die nicht ins Plugin-Inventar, in die Datenbereinigung und in die Integrationskarte fliesst, also in die Posten, die tatsächlich die Migrationskosten bestimmen. Händler, die sauber durch diese Phase kommen, behandeln die Zwischenzeit als Migrationsanlauf.
In dieser Zwischenzeit: was noch läuft, härten. Ein WAF-Regelsatz vor dem Shopware-5-Storefront, Admin-Zugang hinter IP-Allowlist mit 2FA auf dem Reverse Proxy, Log-Monitoring mit Alarm bei ungewöhnlicher Admin-Aktivität, regelmässige Offsite-Backups mit getesteten Restores und ein dokumentierter Incident-Response-Pfad. Nichts davon macht Shopware 5 sicher. Es verschafft Ihnen die Monate, die Sie brauchen, um die Migration ohne Breach in der Lücke abzuschliessen.
Läuft Shopware 5 noch auf aktuellem PHP?
Shopware 5 läuft auf PHP 7.4 bis 8.2, abhängig davon, auf welcher 5.x-Minor-Version Sie sind. Die letzte Shopware-5-Version unterstützt bis einschliesslich PHP 8.2. In der Praxis hängen die meisten Shopware-5-Shops, die ich auditiere, auf PHP 7.4 oder 8.0 fest, weil jedes Anfassen der Runtime Plugin-Inkompatibilitäten aufdeckt, für deren Behebung niemand auf einer sterbenden Plattform das Budget findet. Das ist die Falle.
Laut offizieller PHP-Versionsübersicht: PHP 7.4 ist am 28. November 2022 aus dem Support gefallen. PHP 8.0 am 26. November 2023. PHP 8.1 am 31. Dezember 2025. PHP 8.2 erhält noch bis zum 31. Dezember 2026 reine Security-Patches, danach fällt auch es aus dem Support. Selbst die neueste PHP-Version, die das letzte Shopware-5-Release unterstützt, ist Monate davon entfernt, keine Patches mehr zu bekommen.
Jede Schicht des Stacks ist ohne Support. Ihr Shop läuft auf PHP, das niemand patcht, oben drauf eine Shopware-Version, die niemand patcht, und Plugins, die niemand aktualisiert. Jede Schicht verstärkt die anderen. Eine einzige CVE in irgendeiner Schicht kann den ganzen Stack umwerfen.
Das Infrastruktur-Problem verstärkt sich auf eine Weise, die die meisten Händler erst sehen, wenn ihr Hoster eine Ankündigung zur Abschaltung schickt. Managed-PHP-Hoster nehmen PHP 7.4 systematisch aus dem Angebot. Einige haben den Support bereits komplett eingestellt. Wer ihn noch anbietet, verlangt Aufschläge für Legacy-PHP-Runtimes und deckelt Sie auf bestimmte Patch-Level. Jedes Quartal schrumpft die Menge der Hoster, die Ihren Stack überhaupt noch betreiben.
Eine Migration, die ich aktuell leite, startet von Shopware 5.3 auf PHP 7.2. Der Hoster des Kunden hat eine 12-wöchige Frist gesetzt: Upgrade oder Wechsel der Plattform. Ab diesem Punkt gab es keinen entspannten Weg mehr. Die Wahl wurde zu: Not-PHP-Upgrade, das Teile von Shopware 5 bricht, auf die wir angewiesen sind, oder Migration nach Shopware 6 unter echtem Zeitdruck. In dieser Position wollen Sie nicht sein.
Die Composer-Constraint-Ebene ist die nächste Falle. Shopware 5 fixiert Abhängigkeiten auf Versionen, die ihrerseits moderne Tools blockieren. Sie können Symfony-Komponenten nicht aktualisieren, Sie können kein aktuelles Monitoring einführen, Sie können keine modernen Payment-SDKs nutzen. Der Abhängigkeitsgraph ist in einem PHP-Zeitalter eingefroren, über das das Ökosystem längst hinaus ist.
Dies ist der Punkt, an dem “Shopware 5 läuft ja noch, es ist nichts kaputtgegangen” aufhört, beruhigend zu sein, und anfängt, ein Warnsignal zu sein.
Was passiert mit Drittanbieter-Plugins für Shopware 5?
Das Plugin-Ökosystem ist der Ort, an dem End-of-Life zuerst und am härtesten zuschlägt. Shopware-5-Plugins sind Tausende unabhängige Pakete von Agenturen, Freelancern und Plugin-Anbietern, ohne ein einzelnes Team, das alle pflegt. Die meisten haben innerhalb eines Jahres nach dem offiziellen EOL aufgehört, Updates zu liefern.
Die Erosion folgt einem vorhersehbaren Muster.
Zahlungsanbieter fallen zuerst. Klarna, Stripe, PayPal, Adyen und Mollie deprecaten alte SDK-Versionen in regelmässigen Abständen. Wenn Ihr Shopware-5-Payment-Plugin von einer SDK-Version abhängt, die der PSP nicht mehr unterstützt, scheitern Zahlungen. Nicht alle auf einmal, in der Regel. Spezifische Flows brechen zuerst: Refunds, SEPA-Mandate, 3D-Secure-Challenges. Der Shop nimmt weiter Bestellungen an, aber das Backoffice wird zunehmend manuell.
Steuer- und Compliance-Plugins brechen als nächstes. Umsatzsteuer-Anpassungen, die verpflichtende B2B-E-Rechnung in Deutschland, OSS-Meldeschema-Updates. All das erfordert Plugin-Updates, die Sie nicht mehr bekommen.
ERP- und PIM-Konnektoren verrotten leise. SAP, Dynamics, Akeneo und Pimcore veröffentlichen neue API-Versionen. Der Shopware-5-Konnektor, auf den Sie sich verlassen, wurde gegen eine API geschrieben, die sich seitdem geändert hat. Sync-Jobs fangen an, in Einzelfällen zu scheitern, dann breiter.
Theme-Abhängigkeiten brechen unauffällig. Emotion-Templates, die auf älteren jQuery-Versionen oder Smarty-Konfigurationen gebaut wurden, treffen auf Kompatibilitätsprobleme, sobald etwas modernisiert werden soll.
Was Händler unterschätzen, ist die Form. Ihr Shop sammelt 40 kleine Brüche über 18 Monate an statt einen grossen “Shopware 5 ist kaputt”-Moment. Jeder Bruch kostet einen Agenturtag zum Debuggen, eine Woche Workaround, und ein kumulativ sinkendes operatives Vertrauen in die Plattform.
Ich habe kürzlich einen Shopware-5-Shop auditiert, dessen Inhaber davon ausging, dass alles in Ordnung sei, weil der Umsatz stabil war. Die Integrationsebene erzählte eine andere Geschichte. 9 von 23 Drittanbieter-Plugins hatten seit über 2 Jahren keine Updates bekommen, 3 Payment-Flows brauchten wöchentlich manuelle Eingriffe, und der ERP-Sync lief auf einem undokumentierten Patch, den ein früherer Freelancer vor seinem Verschwinden aufgespielt hatte. Der Shop lief auf gutem Willen und Flickwerk.
”Wir sind zu weit zurück” ist der Einwand, der am teuersten kommt
Der häufigste Einwand von Shopware-5-Nachzüglern ist irgendeine Version von: “Wir sind auf einer alten Version, wir haben zu viel Custom Code, unsere Daten sind zu komplex, es ist zu spät.” Das ist die Ausrede, nicht die Realität.
Eine Migration, die ich aktuell leite, geht von Shopware 5.3 auf Shopware 6.7. 5.3 ist Jahre vor der heutigen Shopware-6-Architektur erschienen. Sie liegt 5 Major-Versionen zurück, und sie wird auf die neueste Shopware-6-Version migriert. Der Migration Assistant funktioniert. Die Daten mappen. Die Plugins müssen neu gebaut werden, aber das gilt für jede Shopware-5-Startversion, weil Shopware 6 ein komplettes Rewrite ist.
Das Volumen ist auch nicht der Blocker. Zwei abgeschlossene Shopware-5-auf-6-Migrationen bei mir haben Shops mit über 25.000 Bestellungen in der Historie bewegt. Einer davon trug zusätzlich über 12.000 SKUs über mehrere Kataloge. Bestellhistorie migriert sauber. Kundendaten migrieren sauber. Produktdaten migrieren mit den üblichen Einschränkungen bei Kategorie-Mappings und Custom Fields. Die Anzahl der Nullen in Ihrer Bestelltabelle entscheidet nicht, ob eine Migration möglich ist.
Auch die kommerzielle Logik hat sich zu Ihren Gunsten verschoben. Shopware AG rechnet den Wert bestehender Shopware-5-Subscriptions auf kommerzielle Shopware-6-Pläne an. Sie zahlen in der Übergangszeit nicht doppelt. Ihre Shopware-5-Subscription liefert weiter, was an Support noch übrig ist, während Sie die Migration fahren, und die Kosten rollen in den Shopware-6-Vertrag, wenn Sie umschalten.
Das Einzige, was Migration wirklich blockiert, ist die Entscheidung, sie weiter zu verschieben. Jeden Monat, den Sie warten, verrottet das Plugin-Inventar mehr, der Druck auf der Hoster-Seite steigt, und der Engineering-Aufwand wächst.
Wie eine ehrliche Shopware-5-auf-6-Migration tatsächlich aussieht
Die meisten “Shopware-5-Migration”-Inhalte online beschreiben eine aufgeräumte technische Sequenz. Echte Migrationen sind unordentlicher, und die Reihenfolge im Detail ist nützlicher. Das ist der Ablauf, den ich auf jeder Migration fahre.
Plugin-Inventar ist der erste Arbeitstag. Jedes Drittanbieter-Plugin, jedes Custom Plugin, jedes Theme-Override. Klassifiziert nach: für Shopware 6 weiter gepflegt, hat ein Äquivalent von einem anderen Anbieter, muss komplett neu gebaut werden, kann ersatzlos wegfallen. Dieses eine Dokument bestimmt den Grossteil des Budgets. Die Rebuild-Entscheidungen bestimmen auch, ob Ihr Shopware-6-Shop architektonische Schulden aus Shopware 5 mitnimmt oder sauber startet. Mein Beitrag zum Shopware-6-Plugin-Entwicklungsansatz beschreibt die Muster, mit denen neu gebaute Plugins die nächsten zehn Jahre Updates überstehen.
Datenaufnahme ist der zweite Tag. Bestellvolumen, Kundenanzahl, Produktanzahl, Custom Fields, Grösse der Medienbibliothek, Struktur der CMS-Inhalte. Der Shopware Migration Assistant handhabt die Kern-Entitäten gut. Mappings für Custom Fields und eigene Datenbanktabellen brauchen manuelle Definition.
Integrationskarte ist der dritte Tag. ERP-Anbindungen, PIM-Sync, Zahlungsanbieter, Versandanbieter, Fulfillment, Buchhaltung, Analytics. Jede einzelne wird neu gebaut oder umgehängt. Keine davon migriert automatisch.
Staged Cutover. Ich fahre beide Systeme parallel durch den Übergang. Shopware 5 nimmt weiter Bestellungen an, während Shopware 6 in einer Staging-Umgebung aufgebaut wird. Wir schneiden Stück für Stück um: Katalog zuerst, dann Kunden-Accounts, dann der Transaktions-Cutover. Ich habe diesen Ansatz in einer Plattform-Migration ohne Ausfallzeit umgesetzt, und dasselbe Muster gilt für jedes Shopware-5-auf-6-Projekt, das ich übernehme.
Zeitplan-Erwartungen sind wichtig, weil Händler oft mit unrealistischen ankommen. Ein kleiner Shop mit 25 Plugins und sauberen Daten migriert in 2 bis 3 Monaten. Ein mittlerer Shop mit 50 Plugins, ERP-Anbindung und internationalem Katalog läuft 4 bis 6 Monate. Alles mit Custom-B2B-Logik, schweren Integrationen oder grossen historischen Datenmengen läuft 6 Monate plus. Es gibt keine Zwei-Wochen-Migration für einen echten Produktivshop.
Die Kostentreiber sind vorhersehbar: Plugin-Rebuilds sind der grösste Posten, Datenbereinigung der zweite, Integrationen der dritte, Content-Parität (CMS, Übersetzungen, SEO-Redirect-Mappings) der vierte. Alles andere sind Kleinposten. Manche Plugins sind trivial zu ersetzen. Andere, etwa die individuelle Versandkostenberechnung mit Bin-Packing-Logik, die ich für einen Kunden gebaut habe, werden zu eigenständigen Projekten über mehrere Wochen.
Häufig gestellte Fragen
Wird Shopware 5 im Jahr 2026 noch unterstützt? Nein. Shopware 5 hat am 31. Juli 2024 das End-of-Life erreicht. Shopware AG untersucht nur noch Sicherheitsprobleme, die Kunden aktiv melden, und liefert bei Bedarf einen Bugfix. Es gibt keine proaktiven Updates, keine neuen Features und keine aktive Entwicklung mehr.
Kann ich direkt von Shopware 5.3 auf Shopware 6.7 migrieren? Ja. Ich setze genau diese Migration aktuell um. Der Shopware Migration Assistant überbrückt die Lücke, egal von welcher Shopware-5-Minor-Version Sie starten.
Bedeutet Shopware 5 End-of-Life, dass mein Shop aufhört zu funktionieren? Nicht sofort. Die Software rund um Ihren Shop (PHP-Versionen, Payment-SDKs, Drittanbieter-Plugins) fällt Stück für Stück aus, während der Shop selbst ungepatcht gegen neue Schwachstellen läuft.
Wie lange dauert eine Migration von Shopware 5 auf Shopware 6? 2 bis 3 Monate für kleine Shops, 4 bis 6 Monate für mittelgrosse Shops mit Integrationen, 6 Monate plus für B2B oder datenintensive Shops.
Lohnt sich die Migration für einen Shop mit geringem Volumen? Ja, wenn Sie den Shop überhaupt weiter betreiben wollen. Die Alternative ist eine erzwungene Migration unter Hoster- oder Compliance-Druck, die mehr kostet und Ihnen weniger Kontrolle über das Timing gibt.
Was jetzt zu tun ist
Wenn Sie 2026 Shopware 5 betreiben, lautet die Frage: wie migrieren, in welcher Reihenfolge und zu welchen Kosten.
Ich biete bezahlte Migrations-Audits speziell für Shops in dieser Situation an. Das Ergebnis ist ein konkretes Dokument: vollständiges Plugin-Inventar mit Rebuild- oder Ersatz-Entscheidungen, Datenaufnahme mit markierten Migrationsrisiken, Integrationskarte mit Kostenabschätzung für die Wiederanbindung, und ein stufenweiser Migrationsplan mit realistischen Zeitrahmen und Budget-Bandbreiten. Das Audit ersetzt Bauchgefühl durch einen Plan, mit dem Ihr Team und Ihre Stakeholder tatsächlich arbeiten können.
Ich habe Shopware-5-auf-6-Migrationen im Bereich von 25.000+ Bestellungen umgesetzt, und ich leite aktuell eine Shopware-5.3-auf-6.7-Migration, die zeigt: kein Ausgangspunkt ist zu weit zurück. Wenn Sie eine ehrliche Einschätzung wollen, was Ihre Migration tatsächlich kostet und wie sie sequenziert werden sollte, nehmen Sie Kontakt auf.
