Shopware-Update ohne Überraschungen: die Checkliste für Minor- und Major-Updates

Ein Shopware-Update ist kein Knopfdruck, sondern ein kleines Projekt mit Vorbereitung, Durchführung und Test. Die gute Nachricht: Mit Backup, Staging-Kopie und einer festen Reihenfolge wird es planbar. Diese Checkliste zeigt, was ich vor, während und nach jedem Update prüfe – und wann ein Rollback die richtige Entscheidung ist.

Patch, Minor, Major – was ist der Unterschied?

Shopware 6 verwendet vierstellige Versionsnummern, zum Beispiel 6.7.3.1. Die Stellen bedeuten unterschiedlich viel Risiko:

• Patch (letzte Stelle, 6.7.3.0 auf 6.7.3.1): Fehlerbehebungen und Sicherheitsfixes. Kleines Risiko, sollte zeitnah eingespielt werden.
• Minor (dritte Stelle, 6.7.2 auf 6.7.3): neue Funktionen, keine beabsichtigten Brüche. Plugins laufen normalerweise weiter, es sei denn, sie nutzen interne oder experimentelle Schnittstellen.
• Major (zweite Stelle, 6.6 auf 6.7): Brüche in Schnittstellen sind erlaubt und dokumentiert. Plugins, Themes und Konfiguration können inkompatibel werden. Shopware veröffentlicht nach eigener Aussage jedes Jahr eine neue Major-Version.

Ein Beispiel aus dem Update auf 6.7: Die Administration wurde von Webpack auf Vite umgestellt. Plugins mit eigenen Admin-Komponenten brauchen deshalb getrennte Versionen für 6.6 und 6.7. Das ist der typische Fall, in dem ein Major-Update ohne Vorbereitung scheitert.

Vor dem Update: die Prüfliste

Haken Sie ab, was erledigt ist – der Stand bleibt in Ihrem Browser gespeichert, auch wenn Sie die Seite später wieder öffnen.

1. Aktuelle Version und Ziel festlegen. Welche Version läuft, welche ist das Ziel? Mehrere Majors überspringen Sie nicht in einem Schritt. Wenn Sie nicht sicher sind, wo Ihr Shop steht: Version-Check.
2. Systemanforderungen abgleichen. Für 6.7 verlangt Shopware PHP 8.2 bis 8.4, MySQL ab 8.0.17 oder MariaDB ab 10.11 sowie Node.js 20. Bei einem Major-Update empfiehlt Shopware, zuerst die PHP-Version anzuheben.
3. Plugin-Kompatibilität prüfen. Im Shopware Store steht bei jeder Erweiterung, mit welchen Versionen sie kompatibel ist. Bei Individual-Plugins fragen Sie den Hersteller oder Entwickler schriftlich an. Jedes Plugin ohne freigegebene Version ist ein Stopp-Signal.
4. Theme-Vererbung prüfen. Ein eigenes Theme, das vom Storefront-Theme erbt und nur einzelne Templates überschreibt, übersteht Updates meist gut. Je mehr Core-Templates komplett kopiert wurden, desto wahrscheinlicher sind kaputte Seiten nach dem Update. Die Liste der überschriebenen Templates sollte vor dem Update bekannt sein.
5. UPGRADE-Hinweise lesen. Shopware dokumentiert Brüche in der Datei UPGRADE.md und im Update-Guide der jeweiligen Version.
6. Backup erstellen – Datenbank und Dateien, und zwar eines, das Sie wiederherstellen können. Ein Backup, das nie getestet wurde, ist eine Hoffnung.
7. Staging-Kopie aufsetzen. Das Update läuft zuerst auf einer Kopie des Shops mit aktuellen Daten. Erst wenn dort alles funktioniert, wird produktiv aktualisiert.

Update per Administration oder per Composer?

In der Administration gibt es unter Einstellungen > System > Shopware Update einen Web-Updater. Er aktiviert den Wartungsmodus, lädt das Update, führt Migrationen aus und schaltet den Wartungsmodus wieder ab. Shopware empfiehlt ihn nur für kleine Installationen, weil Updates im Browser an Zeitlimits und Speichergrenzen scheitern können. Ich nutze ihn praktisch nie für Produktivshops.

Der empfohlene Weg ist Composer. Der Ablauf laut Shopware-Dokumentation: Update lokal oder auf Staging vorbereiten, testen, committen, Code deployen, dann auf dem Produktivserver in dieser Reihenfolge:

bin/console sales-channel:maintenance:enable --all
bin/console system:update:prepare
bin/console system:update:finish
bin/console sales-channel:maintenance:disable --all

Die Vorbereitung selbst besteht aus dem Anheben der Versionsvorgabe von shopware/core in der composer.json, gefolgt von composer update --no-scripts und composer recipes:update. Alternativ übernimmt das Werkzeug shopware-cli project upgrade diese Schritte und schreibt einen Bericht; mit --dry-run lässt sich vorab prüfen, was sich ändern würde. Wichtig: system:update:prepare und system:update:finish laufen erst, nachdem der neue Code auf dem Server liegt, denn die Datenbank-Migrationen müssen zur ausgerollten Version passen.

Nach dem Update: der Testlauf

Das Update ist fertig, wenn der Shop verkauft – nicht, wenn die Konsole „done“ sagt. Diese Punkte teste ich auf Staging und noch einmal produktiv, bevor der Wartungsmodus endet:

1. Storefront: Startseite, Kategorie, Produktseite, Varianten, mobile Darstellung, Konsole des Browsers ohne JavaScript-Fehler
2. Checkout: Gast und registriert, Versandkosten, Gutschein, jede aktive Zahlungsart bis zur Bestellbestätigung (im Testmodus des Anbieters)
3. E-Mails: Bestellbestätigung, Registrierung, Passwort vergessen – kommen sie an, stimmen Inhalt und Absender?
4. Suche und Listings: Suchergebnisse, Filter, Sortierung; bei Elasticsearch nach dem Update neu indexieren
5. Administration: Login, Produkt speichern, Bestellung öffnen, Plugin-Einstellungen
6. Schnittstellen: Warenwirtschaft, Zahlungs-Webhooks, Feeds – laufen die Hintergrundaufgaben, ist die Warteschlange leer?
7. Logs: var/log/ und Webserver-Logs auf neue Fehler

Rollback-Plan und Zeitfenster

Ein Rollback-Plan heißt: Sie wissen vorher, wie Sie zurückkommen, wer es entscheidet und wie lange es dauert. Bei Composer-Setups ist der Code-Stand über Git schnell zurückgesetzt; die Datenbank braucht das Backup von vor dem Update. Shopware beschreibt für Blue-Green-Deployments die Möglichkeit, ohne Datenbank-Wiederherstellung zurückzugehen – allerdings nur, wenn ausschließlich Shopware und keine Erweiterungen aktualisiert wurden.

1. Rollback-Kriterium festgelegt – z. B. „Checkout funktioniert nach 30 Minuten Fehlersuche nicht“.
2. Wer entscheidet – eine Person, telefonisch erreichbar.
3. Weg zurück geprobt – Code-Stand und Datenbank-Backup auf Staging einmal wiederhergestellt.
4. Zeitfenster gewählt – nicht Freitagabend, nicht vor Aktionen, Hoster und Hersteller erreichbar.

Mein Ablauf: Rollback-Kriterium vorher festlegen (zum Beispiel „Checkout funktioniert nach 30 Minuten Fehlersuche nicht“), dann konsequent zurück. Fehlersuche im laufenden Produktivbetrieb kostet Umsatz und Nerven.

Zum Zeitfenster: Patch-Updates lassen sich morgens unter der Woche einspielen, wenn jemand erreichbar ist. Minor- und Major-Updates lege ich auf umsatzschwache Zeiten, aber nicht auf Freitagabend – wenn etwas schiefgeht, will man Hersteller und Hoster erreichen. Vor Aktionszeiträumen friere ich Updates ein.

Häufige Fragen

Wenn Sie das nächste Update nicht allein durchführen möchten, finden Sie auf der Seite Shopware-6-Update, wie ich dabei vorgehe.