Shopware-Update-Checkliste: vorbereiten, durchführen, nachprüfen
Ein Shopware-Update besteht aus zwei Update-Befehlen, eingerahmt vom Wartungsmodus — und aus allem, was davor und danach geprüft werden muss. Die Checkliste in der Reihenfolge, in der sie abgearbeitet wird, mit dem, was system:update:finish tatsächlich tut.
Die Befehle sind beim Shopware-Update der kleinste Teil. Schwierig wird es an anderen Stellen: bei einem Plugin ohne Freigabe, an einer Sicherung, die nie zurückgespielt wurde, oder an einem Theme, das nach dem Update nicht mehr kompiliert. Diese Checkliste ordnet die Schritte in der Reihenfolge, in der sie abgearbeitet werden. Ob sich ein Wechsel auf 6.7 überhaupt lohnt, behandelt der Ratgeber Auf Shopware 6.7 wechseln oder bei 6.6 bleiben. Hier geht es um das Wie.
Phase 1: Bestandsaufnahme
Bevor irgendetwas geändert wird, steht fest, was da ist.
Kurz geprüft
- Aktuelle Version notieren:
bin/console --versionoder Administration unter Einstellungen > System. - Zielversion festlegen und die Upgrade-Hinweise (
UPGRADE.md) dieser Version lesen. Bei einem Hauptversionssprung zuerst die geforderte PHP-Version prüfen. - Plugin-Liste mit
bin/console plugin:listsichern: Name, Version, aktiv oder nicht. - Versionsgrenze je Plugin prüfen: Welche Shopware-Versionen erlaubt die
composer.jsondes Plugins? Shopware empfiehlt dafür als Vorprüfung den Upgrade-Assistenten der Shopware CLI im Probelauf (shopware-cli project upgrade --dry-run); er ändert keine Dateien. - Eigene Anpassungen auflisten: Theme, eigene Plugins, Änderungen an Vorlagen, Schnittstellen zu ERP, Zahlungs- und Versanddienstleistern.
- Wer hat Zugang zu Server, Datenbank und Konsole — und wer ist am Update-Tag erreichbar?
Die Versionsgrenze ist kein Formalismus. Wir haben am 27.10.2026 ein Testplugin mit der Grenze ~6.6.0 in Shopware 6.7.2.2 installieren wollen. Shopware lehnte ab: „Required plugin/package shopware/core ~6.6.0 does not match installed version == 6.7.2.2“. Was eine solche Angabe genau zusagt und was nicht, steht im Ratgeber Was eine Versionsangabe im Plugin wirklich zusagt.
Für jedes Plugin ohne passende Freigabe braucht es vor dem Update eine Entscheidung: neue Version, Ersatz, Anpassung oder Verzicht.
Phase 2: Sicherung, die zurückgespielt werden kann
Shopware empfiehlt vor jedem Update eine Sicherung von Datenbank und Dateien. Zwei Punkte entscheiden, ob sie im Ernstfall hilft:
- Vollständig. Datenbank, das Verzeichnis
public/mediaundfiles, die Konfiguration (.env,.env.local,config/) und der Code samtcomposer.jsonundcomposer.lock. - Ausprobiert. Eine Sicherung, die nie zurückgespielt wurde, ist eine Annahme. Spielen Sie sie einmal in die Testkopie ein. Dann kennen Sie auch die Dauer der Rücksicherung.
Phase 3: Update in der Testkopie
Das Update läuft zuerst in einer Kopie des Shops mit echten Daten. Mit Demodaten bleiben genau die Fälle unentdeckt, die im Live-Shop Probleme machen: große Tabellen, alte Datensätze, Sonderfälle aus Jahren Betrieb. Wie viel ein Versionssprung an der Datenbank ändert, zeigt unsere Untersuchung Was ein Versionssprung an der Datenbank wirklich tut.
Die Kopie braucht abgeschaltete Mails und Zahlungen im Testmodus, sonst bekommen echte Kunden Post vom Testsystem.
In der Kopie wird nach der Dokumentation von Shopware vorbereitet: Zielversion in der composer.json setzen, composer update, die Änderungen an den Rezepten prüfen, Plugins aktualisieren. Danach dieselben Befehle wie später im Live-Shop. So ist der Ablauf einmal vollständig durchgelaufen.
Kurz geprüft
- Laufzeit von
system:update:finishnotieren — sie bestimmt das Zeitfenster. - Ausgabe vollständig lesen, auch die Hinweise am Ende.
- Testkäufe mit jeder aktiven Zahlart und Versandart, als Gast und mit Kundenkonto.
- Bestellmail, Rechnung, Schnittstellen zu ERP oder Warenwirtschaft prüfen.
- Administration öffnen: Produkte, Bestellungen, Plugin-Einstellungen.
- Je Plugin prüfen, ob es noch tut, was es soll — nicht nur, ob es aktiv ist.
Phase 4: Update-Befehle und Wartungsmodus im Live-Shop
Nach dem Einspielen des neuen Codes nennt die Shopware-Dokumentation diese Reihenfolge: Wartungsmodus an, dann die beiden Update-Befehle system:update:prepare und system:update:finish.
bin/console sales-channel:maintenance:enable --all
bin/console system:update:prepare
bin/console system:update:finish
Die Befehle dürfen erst laufen, wenn der neue Code auf dem Server liegt. Die Migrationen müssen zum Code passen. Der Wartungsmodus bleibt danach an: Abgeschaltet wird er erst nach bestandener Nachkontrolle in Phase 5. Das verlangt auch die Shopware-Dokumentation.
Was system:update:finish tut
Im Quelltext von 6.6.10.6 und 6.7.2.2 erledigt der Befehl der Reihe nach (in 6.6.10.30 und 6.7.15.1 unverändert):
| Schritt | Was passiert | Worauf achten |
|---|---|---|
| Migrationen | database:migrate für den Kern, danach destruktive Migrationen im Modus safe | scheitert eine Migration, bricht der Befehl mit Fehler ab; die folgenden Schritte laufen dann nicht |
| Theme | aktive Themes werden neu kompiliert | ein fehlgeschlagenes Theme steht nur als Hinweis „could not be recompiled“ in der Ausgabe |
| Indexer | vorgemerkte Indexer laufen teils sofort, teils als Nachricht in der Warteschlange | ohne laufenden Hintergrundprozess bleiben sie liegen |
| Geplante Aufgaben | werden neu registriert | der Scheduled-Task-Runner muss danach laufen |
| Assets | assets:install | lässt sich mit --skip-asset-build überspringen |
Die Theme-Zeile ist der Grund, warum die Ausgabe gelesen werden muss: Ein kaputtes Theme beendet den Befehl nicht mit einem Fehler. Anders eine fehlgeschlagene Migration: In unserem Test am 02.11.2026 brach system:update:finish in 6.6.10.6 und 6.7.2.2 dann mit Exitcode 1 ab, Theme, Indexer und Assets kamen nicht mehr an die Reihe. Der Shop steht in diesem Fall zwischen alter und neuer Version, und der Rückweg aus Phase 6 wird zur Option. Und was in der Warteschlange landet, wird erst erledigt, wenn ein Worker sie abarbeitet. Wie das im Hintergrund zusammenhängt, beschreibt Was Shopware im Hintergrund erledigt.
Phase 5: Nachkontrolle, bevor der Shop wieder öffnet
Kurz geprüft
- Storefront: Startseite, Kategorie, Produkt, Suche, Warenkorb, Kasse.
- Ein echter Testkauf mit anschließender Stornierung.
- Administration lädt, Bestellungen sind sichtbar.
- Log unter
var/logauf neue Einträge der Ebeneerrorodercriticalprüfen. - Hintergrundprozesse: Warteschlange leert sich, geplante Aufgaben laufen.
- Schnittstellen: erste Bestellung kommt im ERP an.
Erst wenn alle Punkte bestanden sind, wird der Wartungsmodus abgeschaltet:
bin/console sales-channel:maintenance:disable --all
Danach im Browser ohne Freigabe-IP prüfen, dass der Shop wieder erreichbar ist.
Bleibt eine geplante Aufgabe nach dem Update stehen, hilft der Ratgeber Warum ein Scheduled Task nicht läuft.
Phase 6: Rückweg festlegen, bevor er gebraucht wird
Vor dem Live-Update steht schriftlich fest:
- Ab wann zurückgerollt wird — etwa wenn der Testkauf im Live-Shop nicht durchgeht.
- Wer das entscheidet.
- Wie: Sicherung einspielen, alten Code zurück, Cache leeren.
- Wie lange das dauert — bekannt aus der Probe in Phase 2.
Bestellungen, die zwischen Sicherung und Rücksicherung eingehen, wären danach weg. Deshalb bleibt der Shop im Wartungsmodus, bis die Nachkontrolle bestanden ist.
Das Update selbst sind zwei Shopware-Befehle zwischen Wartungsmodus an und aus. Die Sicherheit kommt aus der Kopie davor, der gelesenen Ausgabe dabei und der Nachkontrolle danach.
Wie wir Shopware-Shops laufend betreuen, beschreibt die Seite Shopware Support.
Häufige Fragen
- Wie lange dauert ein Shopware-Update?
- Das hängt von der Datenmenge, der Zahl der Plugins und dem Versionssprung ab. Eine belastbare Zahl liefert nur der Lauf in der Testkopie mit echten Daten. Diese Dauer plus Testkäufe und Puffer ergibt das Zeitfenster für den Live-Shop.
- Kann ich das Update über die Administration machen?
- Shopware bietet einen Updater unter Einstellungen > System > Shopware-Update. Die Shopware-Dokumentation empfiehlt ihn nur für kleine Shops, weil Zeit- und Speichergrenzen des Servers den Lauf abbrechen können. Für Produktivshops empfiehlt sie die Vorbereitung per Composer und die Befehle auf der Konsole.
- Muss der Shop während des Updates offline sein?
- Für die Befehle prepare und finish empfiehlt Shopware den Wartungsmodus für alle Verkaufskanäle. In unserem Test mit 6.7.2.2 griff er erst, als die gesammelte Cache-Invalidierung gelaufen oder der HTTP-Cache geleert war.
- Was mache ich mit einem Plugin ohne Freigabe für die neue Version?
- Vor dem Update klären: Gibt es eine neue Version, einen Ersatz oder kann es entfallen? Ein Plugin, dessen Versionsgrenze die neue Shopware-Version ausschließt, lässt sich dort nicht installieren. Deaktivieren allein löst das Problem nicht, wenn Daten oder Funktionen daran hängen.
- Brauche ich die Checkliste auch für kleine Patch-Updates?
- In verkürzter Form ja: Sicherung, Update in der Kopie, Testkauf, Live-Update, Nachkontrolle. Patch-Updates bringen laut Shopware auch Sicherheitskorrekturen. Gerade deshalb sollten sie zügig und nach einem festen Ablauf eingespielt werden.