Shopware 5 ist am 31. Juli 2024 aus dem aktiven Support gefallen. Das war vor zwei Jahren. Wenn Ihr Shop heute noch Shopware 5 fährt, zögern Sie nicht mehr, Sie betreiben produktive Software ohne Support. Das Risiko steigt gleichzeitig auf drei Ebenen: Sicherheit, Infrastruktur und das Plugin-Ökosystem, von dem Ihr Shop abhängt.
Dies ist keine freundliche Erinnerung. Zwei Jahre freundliche Erinnerungen sind bereits vorbei. Es ist eine ehrliche Bestandsaufnahme dessen, 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, nutzt nicht mehr unterstützte Produktivsoftware.
Ist Shopware 5 im Jahr 2026 noch sicher?
Nein, nicht in einem sinnvollen Sinn. “Sicher” ist kein Binärwert. Es 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 heißt: 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. Ihr Shop ist das Ziel.
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 schlicht 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 drei 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 Maßnahmen” zum Schutz personenbezogener Daten, “unter Berücksichtigung des Stands der Technik”. Software zwei 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 nicht, ob man die alte Version künstlich am Leben hält. Sie lautet: Wie verbringt man die nächsten sechs Monate. Jede Agenturstunde, die in die Verlängerung der Shopware-5-Lebenszeit fließt, ist eine Stunde, die nicht ins Plugin-Inventar, in die Datenbereinigung und in die Integrationskarte fließt, also in die Posten, die tatsächlich die Migrationskosten bestimmen. Händler, die sauber durch diese Phase kommen, behandeln die Zwischenzeit als Migrationsanlauf, nicht als verlängerte Lebenserhaltung.
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äßige 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 abzuschließen.
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, 5.7.18 vom Juni 2023, unterstützt bis einschließlich 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 acht Monate davon entfernt, keine Patches mehr zu bekommen.
Dadurch entsteht ein Stack, in dem jede Schicht ohne Support ist. Ihr Shop läuft auf PHP, das niemand patcht, oben drauf eine Shopware-Version, die niemand patcht, und Plugins, die niemand aktualisiert. Das sind keine drei separaten Risiken. Das ist ein kumuliertes Risiko, in dem eine einzige CVE in irgendeiner Schicht den gesamten Stack umwerfen kann.
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 zwölfwöchige Frist gesetzt: Upgrade oder Wechsel der Plattform. Ab diesem Punkt gab es keinen entspannten Weg mehr. Die Wahl war nicht “Shopware 5 oder Shopware 6”. Die Wahl war “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 keine einheitliche Codebasis, die Shopware AG pflegt. Es sind tausende unabhängige Pakete von Agenturen, Freelancern und Plugin-Anbietern. 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äßigen 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.
Der Teil, den Händler unterschätzen, ist: Ihr Shop hat keinen einzelnen “Shopware 5 ist kaputt”-Moment. Er hat vierzig kleine Brüche über achtzehn Monate, jeder 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: Neun von dreiundzwanzig Drittanbieter-Plugins hatten seit über zwei Jahren keine Updates bekommen, drei 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. Das ist kein funktionierender Shop. Das ist ein Shop, der auf gutem Willen und Flickwerk läuft.
”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 keine aktuelle Version. Sie erschien im Juli 2017. Sie liegt fünf 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, ja, aber sie müssten aus jeder Shopware-5-Startversion neu gebaut werden, weil Shopware 6 ein komplettes Rewrite ist, unabhängig von der Ausgangsversion.
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. Die ehrliche Version ist unordentlicher und nützlicher. Das ist der Ablauf, den ich auf jeder Migration fahre.
- Plugin-Inventar ist der erste Arbeitstag. Nicht der Code. Das Inventar. 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 Großteil 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öße der Medienbibliothek, Struktur der CMS-Inhalte. Der Shopware Migration Assistant handhabt die Kern-Entitäten gut, aber 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, kein Big Bang. 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 fünfundzwanzig Plugins und sauberen Daten migriert in zwei bis drei Monaten. Ein mittlerer Shop mit fünfzig Plugins, ERP-Anbindung und internationalem Katalog läuft vier bis sechs Monate. Alles mit Custom-B2B-Logik, schweren Integrationen oder großen historischen Datenmengen läuft sechs Monate plus. Es gibt keine Zwei-Wochen-Migration für einen echten Produktivshop.
Die Kostentreiber sind vorhersehbar: Plugin-Rebuilds sind der größte 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.
Shopware 5 End-of-Life: Häufige 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. Es bedeutet, dass die Software rund um Ihren Shop (PHP-Versionen, Payment-SDKs, Drittanbieter-Plugins) Stück für Stück ausfällt, während der Shop selbst ungepatcht gegen neue Schwachstellen läuft.
Wie lange dauert eine Migration von Shopware 5 auf Shopware 6? Zwei bis drei Monate für kleine Shops, vier bis sechs Monate für mittelgroße Shops mit Integrationen, sechs 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, ist die Frage nicht mehr, ob migriert werden muss. Sie lautet: wie, 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, sprechen wir.
