Ein B2B-Shop fällt selten an dem Tag aus, an dem jemand ein Update einspielt. Er fällt an dem Tag aus, an dem jemand anders entscheidet, wann das Update stattfindet: ein veröffentlichter CVE, ein Hoster, der eine PHP-Version abschaltet, ein Plugin-Hersteller, der die Pflege einstellt. Die Termine dafür stehen längst im Kalender. Shopware 6.5 erhält Sicherheitsfixes bis zum 28. Februar 2027, und exakt am selben Tag endet auch der erweiterte Support für 6.6 (Shopware Release Policy). Aktiv gepflegt wird seit dem 17. Juni 2025 die 6.7-Linie (Shopware Release Policy), die nächste Hauptversion 6.8 ist erst für 2027 geplant (Shopware News). Daraus folgt kein Panik-Upgrade. Daraus folgt eine Betriebsdisziplin: planbare Shop-Wartung mit einem Fenster, das Sie selbst legen — statt es von einer Sicherheitslücke legen zu lassen.
Die Fristen stehen längst im Kalender
Shopware veröffentlicht nach eigener Release Policy eine Hauptversion pro Jahr, Minor-Releases jeden ersten Montag im Monat und Patches bei Bedarf (Shopware Release Policy). Wichtiger als die Kadenz sind die vier Zustände, die eine Version durchläuft. Maintained ist die jeweils letzte Minor-Version des aktuellen Hauptzyklus — sie bekommt bei Bedarf Patches. Extended Support erhält die letzte Minor-Version eines abgelösten Zyklus: ausgewählte Bugfixes und Sicherheitsupdates. Security fixes only bedeutet, dass Korrekturen nur noch über ein Security-Plugin ausgeliefert werden und nicht mehr als reguläres Patch-Update. End of Life heißt: keine regulären Korrekturen mehr (Shopware Release Policy).
Der zweite Punkt hat eine Konsequenz, die in Wartungsverträgen gern übersehen wird: Aktiv gepflegt ist die letzte Minor-Version — nicht die Linie als Ganzes. Ein Shop, der auf 6.7.4 stehen bleibt, während 6.7.12 die aktuelle Minor ist, sitzt nicht auf einer aktiv gepflegten Version, sondern nur noch im Security-Fix-Regime (Shopware Release Policy). Wer 6.7 als Ziel definiert, definiert damit implizit auch einen monatlichen Rhythmus. Genau das ist der Unterschied zwischen einem einmaligen Upgrade-Projekt und einer dauerhaft gepflegten Shopware-Installation.
| Shopware-Linie | Status im Juli 2026 | Nächste Frist |
|---|---|---|
| 6.4 | End of Life | Sicherheitsfixes endeten am 14.05.2025 (Shopware Release Policy) |
| 6.5 (6.5.8.x) | nur Sicherheitsfixes über das Security-Plugin | 28.02.2027 (Shopware Release Policy) |
| 6.6 (6.6.10.x) | erweiterter Support: ausgewählte Bugfixes und Sicherheitsupdates | 28.02.2027, danach Sicherheitsfixes bis 28.02.2028 (Shopware Release Policy) |
| 6.7 (aktuelle Minor) | aktiv gepflegt, Minor-Release jeden ersten Montag im Monat | Sicherheitshorizont der 6.7-Minors: 28.02.2028 (Shopware Release Policy) |
| 6.8 | angekündigt, noch nicht veröffentlicht | für 2027 geplant, verschoben von 2026 (Shopware News) |
Der 28. Februar 2027 ist ein Doppeltermin
Zwei Uhren laufen: Shopware und PHP
Die Shopware-Version ist nur die eine Uhr. Die zweite tickt darunter und oft schneller: PHP. Für PHP 8.2 endet der Sicherheitssupport am 31. Dezember 2026 (PHP.net, Supported Versions) — also rund zwei Monate vor dem Ende der 6.5-Sicherheitsfixes. Ein Shop auf 6.5 mit PHP 8.2 verliert damit die Plattform unter sich, bevor die Anwendung darüber ausläuft. PHP 8.3 erhält Sicherheitsfixes bis zum 31. Dezember 2027, PHP 8.4 bis zum 31. Dezember 2028 und PHP 8.5 bis zum 31. Dezember 2029 (PHP.net, Supported Versions).
Shopware 6.7 läuft laut Update Guide auf PHP 8.2, 8.3 und 8.4 und verlangt zusätzlich Node.js 20 oder höher, MySQL ab 8.0.17 oder MariaDB ab 10.11; einzelne Datenbankversionen sind ausdrücklich als problematisch markiert, konkret MySQL 8.0.20 und 8.0.21 sowie MariaDB 10.11.5 und 11.0.3 (Shopware Update Guide). Redis ab 7.0 ist optional (Shopware Update Guide). Rechnet man beide Uhren zusammen, ergibt sich eine naheliegende Zielkombination: 6.7 auf PHP 8.4 deckt den Support-Horizont der 6.7-Minors bis Februar 2028 vollständig ab, ohne dass mitten im Zeitraum ein PHP-Wechsel nötig wird. Ein solcher Sprung berührt auch die Performance-Konfiguration des Shops — Caching-Verhalten und Opcache-Einstellungen gehören mit auf die Prüfliste.
- PHP 8.2: Sicherheitsfixes bis 31.12.2026 (PHP.net) — die früheste der hier relevanten Fristen
- PHP 8.3: Sicherheitsfixes bis 31.12.2027 (PHP.net) — trägt über den 28.02.2027 hinaus
- PHP 8.4: Sicherheitsfixes bis 31.12.2028 (PHP.net) — deckt den 6.7-Horizont vom 28.02.2028 ab
- Shopware 6.7: unterstützt PHP 8.2, 8.3 und 8.4 (Shopware Update Guide)
- Datenbank: MySQL ab 8.0.17 oder MariaDB ab 10.11, mit ausdrücklich problematischen Einzelversionen (Shopware Update Guide)
Die frühere Uhr bestimmt das Fenster
Ist-Aufnahme: was wirklich im Shop steckt
Bevor irgendjemand über Aufwand spricht, braucht es eine ehrliche Bestandsaufnahme. Ehrlich heißt: nicht das, was in der Dokumentation steht, sondern das, was auf dem Produktivsystem läuft. In gewachsenen B2B-Shops weichen beide Stände regelmäßig voneinander ab, weil über Jahre hinweg Anpassungen direkt am System vorgenommen wurden, die niemand mehr im Blick hat (Projekterfahrung). Sechs Dinge gehören auf das Blatt, bevor ein Termin genannt wird.
Kernversion und Patchstand
Nicht nur 6.6 oder 6.7, sondern die exakte Minor und der Patchstand. Davon hängt ab, ob der Shop aktiv gepflegt wird oder bereits im Security-Fix-Regime läuft.
PHP- und Datenbankversion
Die konkrete PHP-Version des Webservers und der CLI, dazu MySQL- oder MariaDB-Version. Beide haben eigene Fristen, die vor der Shopware-Frist liegen können.
Plugin-Inventar
Jede installierte Erweiterung mit Version, Hersteller und Kompatibilitätsstatus zur Zielversion — inklusive der Plugins, die installiert, aber deaktiviert sind.
Eigene Erweiterungen
Der Anteil selbst geschriebener Plugins bestimmt den Testaufwand stärker als die Zahl der Fremd-Plugins, weil hier kein Hersteller die Anpassung übernimmt.
Template-Overrides
Überschriebene Twig-Blöcke und angepasste Storefront-Templates sind die eigentliche Kostenstelle jedes Hauptversionswechsels — dazu unten mehr.
Schnittstellen und Jobs
ERP-Sync, Preisimporte, Cronjobs, Message-Queue-Worker und Webhooks: alles, was ohne Klick im Hintergrund läuft und beim Upgrade still ausfallen kann.
Die Template-Overrides verdienen den Sonderplatz. Ein Hauptversionswechsel ändert Storefront-Templates und Admin-Architektur; überschriebene Blöcke, die auf alten Strukturen aufsetzen, müssen einzeln nachgezogen werden. Für 6.7 kommt hinzu, dass die Administration von Webpack auf Vite umgestellt wurde — Plugins mit Admin-Komponenten brauchen deshalb getrennte Versionen für 6.6 und 6.7 (Shopware Update Guide). Dazu gehört der Wechsel auf Vue 3 ohne Kompatibilitätsmodus und von Vuex auf Pinia sowie eine überarbeitete Caching-Schicht mit verzögerter Invalidierung (Shopware Update Guide). Für den Betrieb heißt das: Ein Plugin, das für 6.6 kompiliert wurde, ist damit noch kein 6.7-Plugin. Wie stark solche Anpassungen die Suche und Navigation im Shop prägen, zeigt der Beitrag zur Onsite-Suche mit Artikelnummern — Suchkonfigurationen sind ein typischer Kandidat für stille Regressionen nach einem Upgrade.
- Exakte Kernversion inklusive Patchstand vom Produktivsystem auslesen, nicht aus der Dokumentation übernehmen
- PHP-Version für Webserver und CLI getrennt prüfen — sie weichen häufiger voneinander ab als erwartet
- Plugin-Inventar mit Kompatibilitätsmatrix zur Zielversion erstellen, deaktivierte Erweiterungen eingeschlossen
- Selbst geschriebene Erweiterungen und ihre Berührungspunkte zum Kern auflisten
- Überschriebene Templates und Twig-Blöcke zählen und einzeln bewerten
- Cronjobs, Queue-Worker und Schnittstellen dokumentieren, inklusive der Systeme am anderen Ende
- Hosting-Rahmen klären: Betriebssystem, Datenbankversion, Node-Version, verfügbare Ressourcen
Das Risiko liegt nicht im Kern, sondern im Ausbau
Der Shopware-Kern wird von einem Hersteller getestet, der ein erhebliches Interesse daran hat, dass ein Upgrade funktioniert. Was der Hersteller nicht testen kann, ist das, was Sie um den Kern herum gebaut haben. Und genau dort liegt in einem B2B-Shop der Umsatz. Ein B2C-Shop verliert bei einem Template-Fehler einen Warenkorb; ein B2B-Shop verliert bei einem Fehler in der Preislogik das Vertrauen einer Einkaufsabteilung, die den Preis auf dem Bildschirm mit dem Rahmenvertrag abgleicht.
Nach einem Upgrade testet man nicht die Startseite. Man testet die vier Dinge, die im B2B den Auftrag auslösen: den richtigen Preis, das richtige Recht, den richtigen Bestand und den Weg zurück ins ERP.
Die kritischen Bereiche sind in jedem B2B-Projekt dieselben. Die ERP-Anbindung überträgt Bestellungen, Kunden, Bestände und Belege — bricht sie, merkt es zuerst die Buchhaltung, nicht der Shop. Die Preis- und Staffellogik entscheidet, welcher Kunde welchen Preis in welcher Menge sieht, und ist in vielen Installationen über eigene Erweiterungen gelöst. Die Kundengruppen- und Rechtelogik steuert, wer Preise überhaupt sehen, wer bestellen und wer freigeben darf. Und die Punchout- oder OCI-Anbindung hängt an Session-Handling und Warenkorbübergabe — ein Bereich, den ein Standard-Testlauf normalerweise nicht berührt.
- ERP-Sync: Bestellexport, Kunden- und Artikelimport, Belegrückläufe, Fehler- und Wiederholungslogik
- Preislogik: kundenindividuelle Preise, Staffeln, Rabattgruppen, Netto- und Bruttodarstellung je Kundengruppe
- Rechtelogik: Kundengruppen, Rollen im Firmenkonto, Budget- und Freigabegrenzen, Sichtbarkeit von Sortimenten
- Punchout und OCI: Katalogeinstieg aus dem Beschaffungssystem, Warenkorbrückgabe, Session-Verhalten
- Bestände und Lieferzeiten: Verfügbarkeitsanzeige je Lager, Lieferzeitberechnung, Teillieferungen
- Belegprozesse: Auftragsbestätigung, Rechnung, Gutschrift und ihre Nummernkreise
Die Upgrade-Strecke
Eine belastbare Upgrade-Strecke besteht aus wenigen, aber unverhandelbaren Schritten. Shopware selbst empfiehlt den Weg über Composer statt über den Browser-Updater, weil er stabiler ist und Timeouts vermeidet, und weist ausdrücklich darauf hin, dass Shopware keine eigenen Backups anlegt — die muss der Betrieb separat sicherstellen (Shopware Update Guide). Ebenso empfohlen: eine Testumgebung, in der das Update vorab durchgespielt wird, und ein Backup auch dann, wenn im Test alles glattlief (Shopware Update Guide).
- Staging-Klon mit anonymisierten Echtdaten: Ein Testsystem mit Beispieldaten beweist wenig. Erst der Klon mit realem Datenvolumen, echten Preisstrukturen und echten Kundengruppen — personenbezogene Daten dabei anonymisiert — zeigt Migrationsdauer und Datenprobleme.
- Dependency-Update vor dem Kern-Update: Erst Plugins und eigene Erweiterungen auf ihre zielkompatiblen Stände heben, dann den Kern. Andersherum debuggt man zwei Fehlerquellen gleichzeitig.
- Datenbank-Migrations-Dry-Run: Die Migrationen auf dem Klon laufen lassen und die Dauer messen. Diese Zahl ist die Untergrenze des Produktivfensters — und in großen Katalogen die Überraschung.
- Smoke-Test-Katalog abarbeiten: Ein festgeschriebener Satz umsatzkritischer Abläufe, jedes Mal derselbe. Nicht Klicken nach Gefühl, sondern eine Liste, die auch um drei Uhr nachts noch funktioniert.
- Rollback-Plan mit definierter Rückfallzeit: Vorab festlegen, bis wann entschieden wird, ob zurückgerollt wird, wie lange das dauert und was mit Bestellungen passiert, die im Fenster eingegangen sind.
- Produktivfenster und Nachlauf: Update im geplanten Fenster, danach eine definierte Beobachtungsphase mit Blick auf Fehlerlogs, Queue-Länge und ERP-Rückläufe.
Der Dry-Run ist die einzige seriöse Aufwandsschätzung
Smoke-Test-Katalog: die zehn umsatzkritischen B2B-Flows
Der Katalog ist das Herzstück der ganzen Disziplin, weil er die Abnahme vom Bauchgefühl löst. Er wird einmal geschrieben, bei jedem Upgrade abgearbeitet und nach jedem Vorfall erweitert. Die Reihenfolge ist bewusst nicht die der Startseite, sondern die des Geldes. Die folgenden zehn Abläufe haben sich als Grundgerüst bewährt und lassen sich pro Shop ergänzen (Projekterfahrung).
- Anmeldung mit einem echten Firmenkonto und Wechsel zwischen mehreren hinterlegten Lieferadressen
- Artikelaufruf mit kundenindividuellem Preis: Der Preis auf der Detailseite entspricht dem Rahmenvertrag
- Staffelpreis über eine Mengenschwelle hinweg: Der Sprung greift im Warenkorb, nicht nur in der Anzeige
- Schnellbestellung per Artikelnummer und Import einer Bestellliste mit mehreren Positionen
- Verfügbarkeit und Lieferzeit für einen Artikel mit Lagerbezug und für einen Streckenartikel
- Freigabeprozess: Bestellung über der Budgetgrenze läuft in die Genehmigung statt direkt in den Auftrag
- Checkout mit Rechnungskauf und hinterlegtem Kreditlimit, inklusive Bestellbestätigung
- Bestellexport ins ERP: Der Auftrag kommt vollständig an, inklusive Positionen, Preisen und Kundenreferenz
- Punchout-Einstieg aus dem Beschaffungssystem und Rückgabe des Warenkorbs
- Belegabruf im Kundenkonto: Auftragsbestätigung und Rechnung sind abrufbar und korrekt zugeordnet
Zwei Ergänzungen sind projektabhängig, aber häufig zwingend. Wer Self-Service über ein B2B-Kundenportal anbietet, testet die Portalfunktionen separat, weil sie oft auf eigenen Erweiterungen aufsetzen. Und wer exportiert, prüft nach jedem Upgrade die Sanktionslistenprüfung im Bestellprozess — eine stillschweigend deaktivierte Prüfung ist ein Compliance-Risiko, das im normalen Betrieb erst auffällt, wenn es zu spät ist.
Deploymentfenster: Dienstagvormittag ist Peak
Im B2C ist die Sache einfach: Man deployt, wenn die Kundschaft schläft. Im B2B schläft die Kundschaft zur selben Zeit wie das eigene Team — und bestellt, wenn beide arbeiten. Die Bestellaktivität in Geschäftskundenshops folgt den Arbeitszeiten der Einkaufsabteilungen und liegt typischerweise am Vormittag der mittleren Wochentage, nicht am Sonntagabend (Projekterfahrung). Das dreht die gewohnte Fensterlogik um.
Daraus folgen zwei unbequeme Konsequenzen. Erstens ist das ruhigste Fenster im B2B oft dasjenige, in dem auch die eigenen Fachleute nicht arbeiten — also genau dann, wenn ein Rollback am schwersten zu organisieren ist. Zweitens ist die Zeit bis zum nächsten Arbeitstag die eigentliche Deadline: Ein Fehler, der am Freitagabend entsteht, hat bis Montagmorgen Zeit, entdeckt zu werden — oder eben nicht. Wer das Fenster mit dem Vertrieb und dem E-Commerce-Verantwortlichen abstimmt statt allein mit der IT, bekommt eine realistischere Antwort.
| Aspekt | B2C-Shop | B2B-Shop |
|---|---|---|
| Nachfrage-Peak | Abends und am Wochenende | Werktags vormittags, häufig Dienstag und Mittwoch (Projekterfahrung) |
| Ruhigstes Fenster | Werktags früh am Morgen | Freitagabend bis Samstagmorgen (Projekterfahrung) |
| Wer bemerkt einen Fehler zuerst | Einzelne Kundinnen und Kunden | Einkauf, Außendienst und ERP-Sync praktisch gleichzeitig |
| Folge eines Fehlers | Abgebrochener Warenkorb | Blockierte Beschaffung beim Kunden, Rückfragen im Vertrieb |
| Ansprechbarkeit im Fenster | Support überwiegend asynchron | Ansprechpartner auf Kundenseite meist nur werktags erreichbar |
| Rollback-Entscheidung | Kann bis zum nächsten Werktag warten | Muss vor Beginn des nächsten Arbeitstags gefallen sein |
Das Fenster ist eine Vertriebsentscheidung, keine IT-Entscheidung
Plugins ohne Nachfolgeversion: ablösen, nachbauen oder streichen
Der Kompatibilitätscheck vor dem Update kennt drei Antworten: bereits kompatibel, kompatibel mit der neuen Shopware-Version, oder nicht kompatibel — letzteres bedeutet, dass es für diese Erweiterung keine Nachfolgeversion gibt (Shopware Update Guide). Die dritte Antwort ist die einzige, die eine Entscheidung erzwingt, und sie kommt bei einem Hauptversionswechsel häufiger als bei einem Minor-Update, weil Umstellungen wie der Wechsel von Webpack auf Vite getrennte Plugin-Versionen für 6.6 und 6.7 nötig machen (Shopware Update Guide). Drei Wege stehen offen, und jeder hat einen Preis.
Ablösen
Die Funktion durch eine gepflegte Alternative oder durch Bordmittel ersetzen. Günstig, wenn der Funktionsumfang vergleichbar ist — teuer, wenn Datenstrukturen migriert werden müssen und Redakteure umlernen.
Nachbauen
Die Funktion als eigene Erweiterung neu implementieren. Sinnvoll, wenn sie geschäftskritisch und der Umfang klein ist. Ab diesem Moment gehört die Pflege dauerhaft ins eigene Budget.
Streichen
Die Funktion ersatzlos entfernen. Die unbeliebteste und oft richtige Option — erst recht, wenn eine ehrliche Nutzungsauswertung zeigt, dass die Funktion kaum verwendet wird.
Die Entscheidung sollte fallen, bevor das Upgrade-Fenster steht, nicht darin. Praktisch bewährt hat sich, jedes Plugin ohne Nachfolgeversion mit zwei Fragen zu konfrontieren: Welcher Umsatzprozess bricht ohne diese Funktion, und wie oft wurde sie in den letzten zwölf Monaten tatsächlich genutzt? Erstaunlich viele Erweiterungen überleben die zweite Frage nicht (Projekterfahrung). Was bleibt, wandert in ein sauber gepflegtes Set eigener Erweiterungen — und damit in die Hände derjenigen, die auch die laufende Shopware-Entwicklung verantworten.
Wartung als laufender Posten statt Notfall-Rechnung
Der wirtschaftliche Kern des Themas ist unspektakulär: Wartung kostet Geld, ob man sie plant oder nicht. Der Unterschied ist, wer den Termin bestimmt. Das Bundesamt für Sicherheit in der Informationstechnik hat für den Berichtszeitraum Juli 2024 bis Juni 2025 durchschnittlich 119 neue Schwachstellen pro Tag gezählt, rund 24 Prozent mehr als im Vorjahreszeitraum (BSI). Schwachstellen mittlerer und hoher Schwere nahmen um etwa 20 Prozent zu, kritische blieben mit minus 2 Prozent nahezu unverändert (BSI). Gleichzeitig stieg die beobachtete Ausnutzung von Schwachstellen um 38 Prozent (BSI), und rund 80 Prozent der angezeigten Angriffe richteten sich gegen kleine und mittlere Unternehmen (BSI).
Das BSI benennt in seinem Fazit auch die Ursache: Bekannte Schwachstellen in exponierten Systemen werden zu spät oder gar nicht gepatcht, und zeitnahe Updates gehören zu den Hebeln, die das Risiko unmittelbar senken (BSI). Ein Online-Shop ist per Definition ein exponiertes System. Wer die Wartung in einen laufenden Posten überführt, kauft damit keine Sicherheit im absoluten Sinne, aber er verschiebt die Wahrscheinlichkeiten deutlich zu seinen Gunsten — und er tauscht eine unkalkulierbare Notfall-Rechnung gegen eine planbare monatliche Position. Welche regulatorischen Anforderungen dabei zusätzlich greifen können, ordnet der Beitrag zu IT-Sicherheit und NIS2 im B2B-Shop ein.
- Monatlicher Minor-Takt: Shopware liefert Minors jeden ersten Montag (Shopware Release Policy) — aktiv gepflegt ist nur die jeweils letzte
- Fester Wartungsslot: ein wiederkehrendes, mit dem Vertrieb abgestimmtes Fenster statt Termine nach Zuruf
- Gepflegter Smoke-Test-Katalog: wächst mit jedem Vorfall und macht die Abnahme wiederholbar
- Staging als Dauerzustand: keine Umgebung, die erst im Projekt gebaut wird, sondern eine, die es schon gibt
- Plugin-Portfolio-Pflege: jährliche Prüfung auf Erweiterungen ohne Nachfolgeversion, bevor die Frist drückt
- Stack-Kalender: Enddaten von Shopware, PHP, Datenbank und Betriebssystem an einer Stelle, mit dem frühesten Datum als Taktgeber
Genau das ist unsere Definition von Shop-Wartung und Support: kein Ticketsystem, das auf Störungen wartet, sondern ein Betriebsmodell mit Terminen, Katalogen und einem Rückweg. Wenn Sie wissen möchten, wo Ihr Shop im Verhältnis zum 28. Februar 2027 steht, ist die Ist-Aufnahme der erste Schritt — sie kostet wenige Tage und beantwortet die Frage, ob Sie ein Wartungsfenster planen oder ein Projekt aufsetzen. Welche Leistungen dabei zusammenspielen, zeigt die Übersicht unserer Leistungen für B2B-Shops.
Quellen und Studien