Shopware 6 Update sicher durchführen mit Staging & Backup

Shopware veröffentlicht für Shopware 6 jeden Monat eine neue Minor Version und bei Bedarf zusätzliche Patches. Laut GitHub Releases ist Version 6.7.15.1 vom 7. Oktober 2026 der aktuelle Stand. Am selben Tag erschien für die ältere Linie die Version 6.6.10.29. Für Shopbetreiber gehören Updates damit zum regelmäßigen Betrieb und brauchen einen festen Ablauf.

Dieser Leitfaden beschreibt den Ablauf anhand der offiziellen Dokumentation von Shopware. Er reicht vom Versionsschema über Staging und Backup bis zum Rollback, falls nach dem Update etwas nicht funktioniert.

Ein Shopware 6 Update bringt Code & Datenbank auf einen neuen Stand

Ein Shopware 6 Update ist der Wechsel einer Installation auf eine neuere Patch, Minor oder Major Version von Shopware 6. Dabei ändern sich Code und Datenbankstruktur, oft auch die Anforderungen an Plugins und Server. Das Update läuft über den Updater in der Administration oder wird lokal mit Composer vorbereitet und auf dem Server per Kommandozeile abgeschlossen.

Die Versionsnummer folgt laut Entwicklerdokumentation dem Schema 6.Major.Minor.Patch. Die führende 6 steht für die Produktlinie und grenzt Shopware 6 vom Vorgänger Shopware 5 ab. An der Position der Nullen lässt sich ablesen, um welche Art von Release es sich handelt. Die Version 6.5.0.0 war eine Major Version, 6.5.1.0 eine Minor Version und 6.5.0.1 ein Patch.

Release Zyklus & Support Phasen

Major Versionen erscheinen laut Shopware einmal im Jahr, Minor Versionen am ersten Montag jedes Monats. Patches kommen jederzeit, wenn ein Fehler oder eine Sicherheitslücke sie erfordert. Vor jeder Major Version gibt es einen Release Candidate, etwa zwei Monate vor dem geplanten Termin.

Shopware unterscheidet vier Support Phasen für jede Version. Die neueste Minor Version des aktuellen Major Zyklus gilt als gepflegt und bekommt bei Bedarf Patches. Die letzte Minor Version des alten Zyklus wechselt mit der nächsten Major Version in den Extended Support. Danach kommen Korrekturen nur noch über das Security Plugin, am Ende steht das Supportende.

Laut der Release Policy von Februar 2024 dauert der Extended Support ein Jahr. Danach folgt ein weiteres Jahr mit Sicherheitskorrekturen über das Security Plugin. Shopware 6.6.0.0 erschien am 2. April 2024, Shopware 6.7.0.0 am 17. Juni 2025.

Im November 2025 hat Shopware die nächste Major Version 6.8 auf 2027 verschoben. Der Extended Support für 6.6 läuft laut Ankündigung weiter, bis 6.8 verfügbar ist. Patches für 6.6.10 und 6.7 erscheinen deshalb derzeit parallel und oft am selben Tag.

Minor Updates & Major Updates verlangen unterschiedlich viel Vorbereitung

Laut der Anleitung für Updates bringen Minor und Patch Versionen neue Funktionen, Fehlerbehebungen und Sicherheitskorrekturen. Besondere Arbeit fällt meist nur an, wenn Plugins interne oder experimentelle Schnittstellen nutzen. Grundlage ist das Versprechen zur Abwärtskompatibilität, nach dem Minor und Patch Versionen kompatibel bleiben müssen. Code mit der Markierung @internal oder @experimental gilt nicht als öffentliche Schnittstelle und fällt nicht darunter.

Minor Versionen bringen auch neue Funktionen in den Core. Seit Version 6.7.14.0 ist etwa der MCP Server ohne Feature Flag aktiv, über den KI Agenten auf den Shop zugreifen können. Seine Schnittstellen bleiben bis 6.8.0 als experimentell markiert. Wie solche Anbindungen funktionieren, erklärt unser Beitrag zum Model Context Protocol.

Major Versionen entfernen alten Code und enthalten Breaking Changes. Plugins, Themes und Serverkonfiguration brauchen dann oft Anpassungen. Shopware empfiehlt, vor einem Major Update zuerst die PHP Version auf das neue Minimum anzuheben. Die Änderungen je Version stehen in der Datei UPGRADE-6.7.md im Repository von Shopware.

Auch Minor Versionen brauchen einen Test

Wie wichtig der Test vor dem Livegang bleibt, zeigen die Release Notes zu 6.7.15.1. Seit 6.7.14.0 werteten die meisten Bedingungen für Positionen im Rule Builder nur noch Produkte aus. Eigene Positionen und Gutschriften passten dadurch nicht mehr und konnten Versandarten ausblenden oder Aktionen blockieren. Version 6.7.15.1 behebt diesen Fehler wieder.

Dieselbe Version korrigiert das Aufräumen alter Theme Dateien nach einer neuen Kompilierung. Seiten aus einem HTTP Cache oder CDN verwiesen danach teils auf CSS und JavaScript Dateien, die nicht mehr existierten.

Staging & Backup kommen vor jedem Eingriff in den Live Shop

Die Update Anleitung von Shopware rät, jedes Update zuerst in einer Testumgebung durchzuspielen. Auch nach einem erfolgreichen Test soll vor dem Update des Live Shops ein weiteres Backup entstehen. Shopware selbst legt dabei keine Backups an, das übernehmen der eigene Server oder der Hosting Partner.

Staging Instanz mit echten Daten

Laut Entwicklerdokumentation kommt der Code der Staging Instanz aus demselben Git Repository wie der Live Shop und läuft auf einer eigenen Domain oder Subdomain. Für die Kopie der Datenbank rät Shopware zu shopware-cli project dump, mit --anonymize ohne personenbezogene Daten. MySQL, Redis und Elasticsearch oder OpenSearch sollen Live und Staging dabei nicht gemeinsam nutzen.

Seit Version 6.6.1.0 gibt es dafür den Befehl system:setup:staging. Er erledigt sechs Aufgaben, die eine Kopie sauber vom Live Shop trennen.

• Apps mit aktiven Verbindungen zu externen Diensten werden samt Integrationen gelöscht.
• Die Instance ID für die Registrierung von Apps wird zurückgesetzt.
• Der Versand von E-Mails wird abgeschaltet, damit keine echten Kunden Post bekommen.
• URLs der Verkaufskanäle werden auf die Staging Domain umgeschrieben, falls konfiguriert.
• Der Befehl prüft, dass in Elasticsearch oder OpenSearch noch keine Indizes existieren.
• Administration und Storefront zeigen einen Hinweis, dass es sich um Staging handelt.

Zahlungsanbieter stellt der Befehl nicht selbst in den Testmodus. Plugins können dafür auf das Ereignis SetupStagingEvent reagieren und ihre Einstellungen für Staging anpassen. Die Konfiguration des Befehls liegt in der Datei config/packages/staging.yaml.

Backup von Datenbank & Dateien

Vor dem Update werden Datenbank und Dateien gesichert, damit sich der alte Stand wiederherstellen lässt. Mit Blue Green Deployment ist ein Rollback auch ohne Rückspielen der Datenbank möglich. Shopware empfiehlt diesen Weg nur, wenn ausschließlich Shopware aktualisiert wurde und keine Erweiterungen gleichzeitig. Wie wir Server mit Backups und Monitoring betreiben, steht auf der Seite zu Software & Development.

Plugin Kompatibilität entscheidet über den Verlauf des Updates

Für die Vorabprüfung hat die Shopware CLI einen Upgrade Assistenten mit Testlauf. Der Befehl shopware-cli project upgrade --dry-run prüft, ob das Projekt bereit ist und Composer die Zielversion auflösen kann. Dateien im Projekt verändert er dabei nicht. Voraussetzung ist, dass alle Erweiterungen über Composer verwaltet werden.

Für Major Updates erstellt der Assistent außerdem eine Liste aller Erweiterungen mit ihrem Status. Daraus geht hervor, welche Plugins kompatible Versionen haben, ein Update brauchen oder den Wechsel blockieren. Erweiterungen ohne kompatible Version müssen vor dem Update ersetzt, angepasst oder deaktiviert werden.

Der Updater in der Administration zeigt für jede aktive Erweiterung einen von drei Zuständen. Sie ist bereits kompatibel, wird mit einem Update kompatibel oder ist mit der neuen Version nicht kompatibel. Inkompatible Erweiterungen deaktiviert der Updater auf Wunsch vor der Installation, diese Option ist voreingestellt. Ohne Deaktivierung kann das Update abbrechen oder den Zugang zum Shop blockieren.

Bei Major Updates wie von 6.4 auf 6.5 müssen laut Update Anleitung alle Erweiterungen deaktiviert werden. Für eigene Plugins nennt Shopware Rector für Shopware und Codemods für den Code der Administration. Eine Funktion für PhpStorm zeigt überschriebene Twig Blöcke an, die nach einem Update Anpassung brauchen können.

Wann reicht das Update über die Administration?

Das Update über die Administration eignet sich laut Shopware nur für kleine Shops. Der Updater übernimmt Wartungsmodus, Download, Migrationen und das Abschalten des Wartungsmodus. Bei größeren Shops drohen im Browser Timeouts, Speichergrenzen und andere Probleme mit Ressourcen. Für den Produktivbetrieb empfiehlt Shopware die lokale Vorbereitung mit Composer und ein Deployment auf den Server.

Updater in der Administration

Der Updater liegt in der Administration unter Einstellungen > System > Shopware Update. Er prüft zuerst erneut die Systemvoraussetzungen, grüne Haken zeigen bestandene Prüfungen an. Alles außerhalb des grünen Bereichs wird vor dem Update behoben. Die Schaltfläche zur Installation wird erst aktiv, wenn bestätigt ist, dass ein Backup existiert.

Update über Composer & bin/console

Lokal hebt man in der Datei composer.json die Version von shopware/core auf die Zielversion an. Danach folgen composer update --no-scripts und composer recipes:update, die Änderungen der Recipes werden einzeln geprüft. Alternativ übernimmt shopware-cli project upgrade diese Schritte und schreibt einen Bericht als Markdown Datei. Schlägt ein wichtiger Schritt fehl, stellt der Assistent composer.json und composer.lock wieder her.

Nach den Tests werden beide Dateien committet und über den gewohnten Prozess ausgeliefert. Auf dem Server laufen danach vier Befehle in fester Reihenfolge.

• bin/console sales-channel:maintenance:enable --all schaltet alle Verkaufskanäle in den Wartungsmodus.
• bin/console system:update:prepare lässt Erweiterungen ihre Vorbereitung für das Update ausführen.
• bin/console system:update:finish führt Datenbankmigrationen und weitere Schritte des Updates aus.
• bin/console sales-channel:maintenance:disable --all hebt den Wartungsmodus für alle Verkaufskanäle wieder auf.

Die Befehle laufen erst, wenn der neue Code auf dem Server liegt, denn die Migrationen müssen zur ausgelieferten Version passen. Vor dem Ende des Wartungsmodus prüft man Administration, Warenkorb, Checkout und alle Erweiterungen. Dazu gehören ein Blick in die Fehlerlogs und ein Vergleich der Ladezeiten mit dem Stand vor dem Update.

Das Security Plugin schließt Lücken zwischen zwei Updates

Das Shopware 6 Security Plugin ist ein kostenloses Plugin von Shopware für bestehende Installationen. Damit lassen sich bekannte Sicherheitslücken schließen, ohne Shopware selbst zu aktualisieren. Jede Korrektur gehört zu einem GitHub Security Advisory und greift nur, wenn die installierte Version betroffen ist. Auf einem vollständig gepatchten Shop bleiben die Korrekturen deshalb inaktiv.

Die Versionen des Plugins folgen den Versionslinien von Shopware. Version 4.x gilt für Shopware 6.7, 3.x für 6.6 und 2.x für 6.5, alle drei werden gepflegt. Die Version 1.x für Shopware 6.4 bekommt dagegen keine Pflege mehr.

Einzelne Server installieren das Plugin über den Extension Store in der Administration. Für Deployments mit CI oder mehreren Servern ist Composer vorgesehen, mit composer require store.shopware.com/swagplatformsecurity. Nach jedem Update des Plugins muss der Cache geleert werden, damit neue Korrekturen geladen werden.

Grenzen des Security Plugins

Das Plugin verlängert keinen Support für Versionen am Ende ihrer Laufzeit. Lücken in Bibliotheken wie Symfony oder Twig behebt es ebenfalls nicht. Dafür nennt die Dokumentation composer audit und ein gezieltes Update der betroffenen Pakete. Manche Lücken lassen sich über das Plugin nicht sicher schließen, dann verlangt das Advisory ein Update von Shopware.

Shopware rät deshalb, das Plugin auch auf einem aktuellen Shop installiert, aktiv und aktuell zu halten. In der Administration listet das Plugin jede Korrektur mit Beschreibung und Link zum zugehörigen Advisory. Wer eine Korrektur abschaltet, bestätigt das mit dem Administrator Passwort und öffnet die Lücke wieder. Die Dokumentation sieht das nur als vorübergehende Maßnahme vor.

Sicherheitsupdates 2026 in Zahlen

Im GitHub Repository von Shopware sind seit 2020 insgesamt 92 Security Advisories veröffentlicht, Stand Oktober 2026. Allein 2026 kamen 30 neue hinzu, davon 4 kritisch, 7 hoch, 16 mittel und 3 niedrig eingestuft. Am 25. August 2026 erschienen zehn Advisories auf einmal, drei davon kritisch. Darunter war eine SQL Injection in der Store API ohne Anmeldung, die alle Versionen vor 6.6.10.23 und 6.7 vor 6.7.13.1 betraf. Diese beiden Versionen schließen die Lücke.

Ein Rollback braucht einen Plan vor dem Update

Für Migrationen gibt es in Shopware keinen Rückwärtsschritt, die Dokumentation zu Migrationen hält das ausdrücklich fest. Ein migriertes Datenbankschema lässt sich also nicht per Befehl auf die alte Version zurückdrehen. Ein Rollback bedeutet deshalb, Code und Datenbank gemeinsam auf den Stand vor dem Update zu bringen. Je nach Auslieferung des Updates stehen drei Wege zur Wahl.

• Git und Deployment: Der vorherige Commit mit dem alten composer.lock wird erneut ausgeliefert, dazu kommt das Backup der Datenbank.
• Backup: Datenbank und Dateien werden aus der Sicherung zurückgespielt, Daten seit dem Backup fehlen danach.
• Blue Green Deployment: Der Wechsel zurück auf die alte Umgebung gelingt ohne Datenbank, wenn nur Shopware aktualisiert wurde.

Der Wartungsmodus hält das Risiko beim Rückspielen eines Backups klein. Solange er aktiv ist, entstehen über die Storefront keine neuen Bestellungen, die verloren gehen könnten. Die Entscheidung über einen Rollback fällt deshalb am besten vor dem Ende des Wartungsmodus. Dafür braucht es eine kurze Testliste mit Checkout, Zahlungsarten, Versand und den wichtigsten Plugins.

Ein fester Ablauf macht Shopware 6 Updates planbar

Ein sicheres Shopware 6 Update folgt immer derselben Reihenfolge aus Prüfung, Staging, Backup, Wartungsmodus, Update und Test. Minor Versionen und Patches gehören in einen monatlichen Rhythmus, das Security Plugin schließt Lücken dazwischen. Major Updates wie der kommende Wechsel auf 6.8 brauchen einen eigenen Plan für PHP, Plugins und Themes. Wie wir Shops bauen und betreuen, zeigen die Seiten zu E-Commerce und zu unserer Shopware Agentur.