Shopware Major-Upgrade: planbar auf die aktuelle 6er-Linie
Ein Versionssprung ist kein Update, sondern ein Projekt: Erweiterungen, Templates, Datenbank und Serverumgebung müssen gemeinsam bewegt werden. Wir planen den Weg, proben ihn zweimal auf Staging und führen den Cutover mit definiertem Rückweg durch — Festpreis nach kostenfreier Systemanalyse.
5
Phasen im Upgrade-Projekt
2
Probeläufe vor dem Cutover
48 h
Rollback-Fenster nach dem Go-live
24/7
Monitoring in der Stabilisierung
Solange ein Shop innerhalb seiner Hauptversion bleibt, ist Aktualisieren Routine: Changelog lesen, auf Staging testen, im Wartungsfenster einspielen. Beim Sprung auf eine neue Hauptversion ändert sich die Statik. Schnittstellen, auf die Erweiterungen aufsetzen, werden ersetzt; das Template-System bekommt neue Regeln; die Datenbank wird durch Migrationen umgebaut; und die Serverumgebung muss die von der Zielversion geforderte PHP- und Datenbankversion mitbringen. Wer das im laufenden Betrieb versucht, riskiert genau die Bestellstrecke, die den Umsatz trägt. Diese Seite beschreibt, wie wir ein Major-Upgrade der Shopware Community Edition als eigenes Projekt aufsetzen — und wie es sich zur laufenden Shopware-Wartung verhält.
Der Weg eines Major-Upgrades
Minor oder Major: warum der Unterschied zählt
Innerhalb einer Hauptversion gilt eine einfache Zusage: Schnittstellen bleiben stabil, Erweiterungen laufen weiter, das Template-System verhält sich wie gewohnt. Deshalb lassen sich Minor- und Patch-Releases in einem normalen Wartungszyklus einspielen — mit Backup, Staging-Test und Rollback-Punkt, wie auf der Seite Shopware-Wartung beschrieben. Ein Major-Upgrade hebt diese Zusage bewusst auf, weil es genau die Stellen verändert, die vorher unberührt bleiben mussten.
Praktisch heißt das: Eine Erweiterung, die eine entfernte Schnittstelle nutzt, funktioniert nach dem Sprung nicht mehr — sie muss aktualisiert, ersetzt oder abgelöst werden. Eine Template-Überschreibung, die eine geänderte Vorlage kopiert hat, zeigt danach entweder alte Inhalte oder gar nichts. Und eine Datenbankmigration, die auf halber Strecke abbricht, hinterlässt einen Zustand, aus dem nur ein Backup zurückführt. Nichts davon ist ungewöhnlich oder dramatisch — es ist der Grund, warum ein Major-Upgrade eine eigene Planung braucht statt eines Wartungsfensters.
| Aspekt | Minor-/Patch-Release | Major-Upgrade |
|---|---|---|
| Schnittstellen | Bleiben innerhalb der Hauptversion stabil | Werden erweitert, ersetzt oder entfernt |
| Erweiterungen | Laufen in der Regel unverändert weiter | Jede Erweiterung wird einzeln bewertet |
| Theme und Templates | Überschreibungen bleiben meist gültig | Überschreibungen werden gegen neue Vorlagen abgeglichen |
| Datenbank | Kleine, schnelle Migrationen | Umfangreiche Migrationen mit Laufzeit und Reihenfolge |
| Serverumgebung | Unverändert | PHP- und Datenbankversion oft anzuheben |
| Vorgehen | Wartungsfenster im laufenden Vertrag | Eigenes Projekt mit Analyse, Probelauf und Cutover |
| Rückweg | Rollback-Punkt aus dem Wartungszyklus | Geplanter Rückweg mit definiertem Zeitfenster |
Wann ein Major-Upgrade tatsächlich ansteht
Keine Sicherheitsupdates mehr
Erhält die eingesetzte Hauptversion keine Sicherheitsaktualisierungen mehr, bleiben bekannte Lücken dauerhaft offen. Ab diesem Punkt ist das Upgrade die einzige belastbare Antwort — Hintergrund auf der Seite Sicherheitsupdates.
PHP-Version läuft aus
Wenn die genutzte PHP-Version das Ende ihres Supports erreicht, zieht das den Shop mit. Die Reihenfolge — erst Laufzeitumgebung, dann Anwendung — beschreibt unser Beitrag PHP-EOL-Management.
Erweiterungen sterben aus
Anbieter stellen die Pflege für alte Hauptversionen ein und veröffentlichen neue Funktionen nur noch für die aktuelle Linie. Wer bleibt, verliert nach und nach die Auswahl.
Nachweise und Prüfungen
Auditoren, Versicherer und Zahlungsdienstleister fragen nach unterstützten Softwareständen. Eine abgekündigte Hauptversion ist in solchen Prüfungen regelmäßig ein Befund.
Performance-Grenze erreicht
Wenn Caching, Datenbanktuning und Serverausbau ausgereizt sind, liegt der nächste spürbare Sprung häufig in der neueren Plattformgeneration statt in weiterer Optimierung.
Geplante Weiterentwicklung
Neue Vertriebskanäle, Schnittstellen oder Zahlarten setzen oft eine aktuelle Basis voraus. Das Upgrade wird dann zur Voraussetzung des Projekts, nicht zum Projekt selbst.
Der teuerste Weg ist das Aufschieben
Der Upgrade-Pfad in fünf Phasen
Von der Analyse bis zur Stabilisierung
- 1
Systemanalyse und Bestandsaufnahme
Wir erfassen den vollständigen Ist-Zustand: Ausgangsversion, Erweiterungsbestand mit Herkunft und Pflegestand, Theme- und Template-Überschreibungen, individuelle Entwicklungen, angebundene Systeme, Datenmengen und die Serverumgebung. Ergebnis ist ein Bericht mit Zielversion, Risiken und dem Aufwand je Teilbereich. Diese Analyse ist kostenfrei.
- 2
Kompatibilitätsmatrix und Entscheidungen
Jede Erweiterung bekommt eine von drei Einstufungen: kompatibel mit der Zielversion, Ersatz nötig oder ersatzlos entfernen. Für individuelle Entwicklungen wird der Anpassungsaufwand geschätzt. Sie entscheiden auf dieser Grundlage, was mitgeht — und was die Gelegenheit ist, Ballast loszuwerden.
- 3
Aufbau der Zielumgebung und erster Probelauf
Wir stellen die Zielumgebung mit passender PHP- und Datenbankversion bereit, führen das Upgrade mit einer Kopie der Echtdaten durch und protokollieren, wo Migrationen abbrechen, wie lange sie laufen und welche Erweiterungen sich anders verhalten als erwartet. Der erste Lauf dient dem Finden von Problemen, nicht dem Erfolg.
- 4
Zweiter Probelauf und Abnahme
Nach der Korrektur wiederholen wir den kompletten Durchlauf mit frischen Daten und messen dabei die reale Dauer jedes Schritts. Bestellstrecke, Zahlung, Versand, Suche, Kundenkonto und angebundene Systeme werden systematisch geprüft. Aus den gemessenen Zeiten entsteht der Ablaufplan für den Cutover mit einem realistischen Zeitfenster.
- 5
Cutover und Stabilisierung
Der Umstieg läuft nach schriftlichem Ablaufplan in einem Zeitfenster mit geringer Besucheraktivität, inklusive Abbruchkriterien und Rückweg. Nach der Freigabe beobachten wir Fehlerraten, Antwortzeiten und Bestellabschlüsse engmaschig, halten den Rollback-Punkt 48 Stunden vor und arbeiten die verbliebenen Feinheiten ab.
Die Erweiterungsmatrix entscheidet über den Aufwand
Der Kern eines Major-Upgrades liegt selten im Core selbst, sondern im Bestand der Erweiterungen. Ein gewachsener Shop trägt häufig zwanzig bis vierzig davon: Zahlarten, Versanddienste, Preis- und Rabattlogik, Suchergänzungen, Schnittstellen zur Warenwirtschaft, dazu Anpassungen, die einmal für einen konkreten Anlass gebaut wurden und seitdem mitlaufen. Jede dieser Komponenten muss beantwortet bekommen, ob sie in der Zielversion existiert, ersetzt werden kann oder ersatzlos entfällt.
Diese Bewertung machen wir vor dem ersten technischen Schritt, weil sie den Aufwand des gesamten Projekts bestimmt. Erfahrungsgemäß ist ein spürbarer Teil des Bestands schlicht überflüssig — Erweiterungen, die seit Jahren keine Funktion mehr erfüllen, deaktivierte Reste früherer Projekte oder zwei Lösungen für dasselbe Problem. Ein Upgrade ist ein guter Moment, das aufzuräumen, weil ohnehin jede Komponente einzeln angefasst wird.
Jede Komponente bekommt eine Entscheidung
Statt einer Liste von Unbekannten entsteht eine Matrix mit drei möglichen Ausgängen je Erweiterung. Was keinen Weg in die Zielversion hat, wird vor dem Cutover ersetzt oder abgelöst — nicht danach unter Zeitdruck.
- Kompatibel: Version für die Zielversion vorhanden und gepflegt
- Ersatz nötig: Funktion bleibt, Umsetzung wechselt
- Entfällt: Funktion wird nicht mehr gebraucht oder ist im Core enthalten
- Individuell: Anpassungsaufwand wird je Entwicklung geschätzt
Theme, Templates und individuelle Entwicklungen
Überschreibungen im Theme sind der zweite große Posten. Sie funktionieren, solange die zugrunde liegende Vorlage unverändert bleibt — und genau das ist beim Versionssprung nicht mehr gegeben. Wir gleichen deshalb jede Überschreibung gegen die Vorlage der Zielversion ab und entscheiden fallweise, ob sie übernommen, neu aufgesetzt oder gestrichen wird. Häufig zeigt sich dabei, dass eine Anpassung inzwischen im Standard enthalten ist und ersatzlos entfallen kann.
- Vollständige Erfassung aller Theme- und Template-Überschreibungen mit ihrem ursprünglichen Zweck
- Abgleich gegen die Vorlagen der Zielversion, inklusive geänderter Blocknamen und Variablen
- Prüfung, welche Anpassung im Standard der Zielversion bereits abgedeckt ist
- Übernahme individueller Entwicklungen auf die neuen Schnittstellen, mit Test je Funktion
- Kontrolle der Barrierefreiheits- und Consent-Bausteine im Frontend nach der Übernahme
- Prüfung von strukturierten Daten, Weiterleitungen und URL-Struktur vor der Freigabe
Datenmigration und Cutover
Die Datenbankmigration ist der Teil, der sich nicht abkürzen lässt. Ihre Dauer hängt an Artikelzahl, Bestellhistorie, Kundendatenbestand und Medienarchiv und lässt sich nicht schätzen, sondern nur messen. Genau dafür sind die beiden Probeläufe da: Der erste zeigt, wo Migrationen abbrechen oder unerwartete Datenzustände vorfinden; der zweite liefert belastbare Laufzeiten für den Ablaufplan. Erst danach steht fest, ob der Cutover in ein nächtliches Zeitfenster passt oder ob Teilschritte vorgezogen werden müssen.
Der Cutover selbst folgt einem schriftlichen Ablaufplan mit Uhrzeiten, Zuständigkeiten, Prüfpunkten und Abbruchkriterien. Vor dem Start entsteht die vollständige Sicherung, aus der der Rückweg führt; nach jedem Abschnitt gibt es eine kurze Kontrolle, bevor der nächste beginnt. Freigegeben wird erst, wenn Bestellstrecke, Zahlung, Versandberechnung, Suche und Kundenkonto geprüft sind. Wie sich ein solches Zeitfenster ohne Umsatzausfall legen lässt, beschreibt unser Beitrag Wartungsfenster: Shop-Updates ohne Umsatzausfall.
Der Rückweg wird vorher geplant, nicht improvisiert
Ein Cutover ohne definierten Rückweg ist eine Wette. Wir legen vor dem Start fest, an welchen Punkten abgebrochen wird, wie lange der Rückweg dauert und wer ihn auslöst. Der Rollback-Punkt bleibt 48 Stunden nach der Freigabe verfügbar.
- Vollständige Sicherung unmittelbar vor dem ersten Schritt
- Abbruchkriterien je Abschnitt schriftlich vereinbart
- Gemessene Rückweg-Dauer aus dem zweiten Probelauf
- Rollback-Punkt 48 Stunden nach dem Go-live verfügbar
Nach dem Go-live: die Stabilisierungsphase
Ein Upgrade endet nicht mit der Freigabe. In den ersten Tagen zeigen sich Effekte, die auf Staging nicht sichtbar werden: reales Besucherverhalten, echte Zahlungsvorgänge, Suchanfragen mit unerwarteten Begriffen, Schnittstellen mit Datensätzen aus dem Tagesgeschäft. Wir beobachten diese Phase eng und arbeiten Auffälligkeiten der Reihe nach ab, statt sie zu sammeln.
Fehlerraten und Antwortzeiten
Fehlerprotokolle und Antwortzeiten werden gegen die Werte vor dem Upgrade verglichen. Abweichungen fallen so am Tag ihres Entstehens auf, nicht Wochen später — Grundlage ist unser Monitoring.
Bestellabschlüsse im Blick
Die Zahl der abgeschlossenen Bestellungen ist der ehrlichste Indikator nach einem Upgrade. Ein stiller Bruch in der Bestellstrecke zeigt sich hier zuerst.
Performance nachziehen
Caching, Indizes und Bildauslieferung werden auf die neue Version abgestimmt. Details zum Vorgehen auf der Seite Performance-Wartung.
Suche und Sichtbarkeit
Weiterleitungen, URL-Struktur und strukturierte Daten werden geprüft, damit der Versionssprung nicht als Sichtbarkeitsverlust in den Suchergebnissen endet.
Härtung auf neuem Stand
Sicherheits-Header, Dateirechte und Zugangsschutz werden auf die neue Version übertragen und überprüft, statt aus der alten Konfiguration übernommen zu werden.
Rückkehr in den Regelbetrieb
Nach der Stabilisierung übergeben wir in den normalen Wartungszyklus mit festen Update-Fenstern — beschrieben auf der Seite Shopware-Wartung.
Steht bei Ihnen ein Versionssprung an?
Wir sehen uns Ausgangsversion, Erweiterungsbestand und Serverumgebung an und sagen Ihnen, wie groß der Sprung wirklich ist — bevor Sie ein Budget dafür festlegen.
Was ein Major-Upgrade kostet
Einen Pauschalpreis für Versionssprünge zu nennen, wäre unseriös: Der Aufwand hängt an der Ausgangsversion, der Zahl und Qualität der Erweiterungen, dem Umfang individueller Entwicklungen und der Datenmenge. Deshalb steht am Anfang die kostenfreie Systemanalyse. Aus ihr entsteht ein Festpreisangebot mit Leistungsumfang, Zeitplan und den Punkten, die bewusst nicht enthalten sind. Erst danach entscheiden Sie. Eine Übersicht aller übrigen Konditionen — laufende Wartung, Soforthilfe, Bereinigung — finden Sie auf der Seite Preise.
Erst analysieren, dann kalkulieren
- Systemanalyse mit Kompatibilitätsmatrix: kostenfrei und unverbindlich
- Upgrade-Projekt: Festpreis nach Analyse, mit Leistungsumfang und Zeitplan
- Betrieb danach: SLA-Wartung ab 199 € pro Monat netto
- Begleitende Einzelarbeiten ohne Vertrag: 95 € pro Stunde im 15-Minuten-Takt
Alle Preise netto zzgl. USt. Das Upgrade-Projekt wird getrennt vom Wartungsvertrag angeboten; der laufende Betrieb danach läuft über die SLA-Stufen.
Selbst upgraden, aufschieben oder begleiten lassen?
Drei Umgangsweisen mit einem anstehenden Versionssprung
Alle drei kommen in der Praxis vor. Der Unterschied liegt darin, wer das Risiko trägt und wann es sichtbar wird.
Im eigenen Team upgraden
- Enthalten: Das Team kennt die eigenen Anpassungen aus erster Hand
- Enthalten: Kein externer Abstimmungsaufwand
- Nicht enthalten: Ein Versionssprung ist ein einmaliges Ereignis — Routine fehlt
- Nicht enthalten: Probeläufe brauchen eine Umgebung, die erst gebaut werden muss
- Nicht enthalten: Bei Problemen in der Nacht des Cutovers gibt es keine Vertretung
Auf der alten Version bleiben
- Enthalten: Keine Projektkosten im laufenden Jahr
- Enthalten: Der Shop läuft zunächst unverändert weiter
- Nicht enthalten: Ohne Sicherheitsupdates bleiben bekannte Lücken dauerhaft offen
- Nicht enthalten: Der spätere Sprung wird mit jedem Jahr größer und teurer
- Nicht enthalten: Neue Zahlarten und Schnittstellen stehen nicht mehr zur Verfügung
Begleitetes Upgrade-Projekt
- Enthalten: Kostenfreie Analyse mit Kompatibilitätsmatrix vor jeder Zusage
- Enthalten: Zwei Probeläufe mit Echtdaten, bevor der Cutover terminiert wird
- Enthalten: Schriftlicher Ablaufplan mit Abbruchkriterien und Rückweg
- Enthalten: Stabilisierungsphase mit Monitoring und Nachkontrolle
- Nicht enthalten: Braucht Vorlauf — kurzfristige Termine sind selten sinnvoll
Drei typische Ausgangslagen vor einem Upgrade
Illustrative, anonymisierte Projektverläufe aus unserer Praxis (Projekterfahrung) — konkrete Kennzahlen und Referenzen nennen wir im persönlichen Gespräch.
Wie ein normales Update innerhalb der Hauptversion abläuft, beschreibt Shopware-Updates sicher einspielen. Warum Probeläufe eine eigene Umgebung brauchen, erklärt Staging-Umgebungen für sichere Shop-Updates, und welche Tests nach einem Versionssprung sinnvoll sind, zeigt Update-Tests: Regressionen nach Shop-Updates vermeiden. Ob die neue Umgebung die erwartete Last trägt, klärt vorab ein Lasttest für Spitzenlast. Ist ein System bereits kompromittiert, ist nicht das Upgrade der erste Schritt, sondern die Seite WordPress gehackt beziehungsweise der Notfall-Support.
Das Wichtigste in Kürze
- Ein Major-Upgrade ist kein Wartungsfenster, sondern ein Projekt mit Analyse, Probeläufen, Cutover und Stabilisierung
- Den Aufwand bestimmt der Erweiterungsbestand — deshalb steht die Kompatibilitätsmatrix vor dem ersten technischen Schritt
- Zwei Probeläufe mit einer Kopie der Echtdaten liefern die realen Laufzeiten für den Ablaufplan des Cutovers
- Der Rückweg wird vorher festgelegt: Abbruchkriterien je Abschnitt, Rollback-Punkt 48 Stunden nach dem Go-live
- Systemanalyse kostenfrei, danach Festpreis; der Betrieb danach läuft über die SLA-Wartung ab 199 € pro Monat netto