Die Frage kommt gerade in fast jedem Jour fixe: „Können wir 6.7 in den Januar schieben?" Dahinter steckt eine nachvollziehbare Rechnung. Von 6.4 auf 6.5 war ein Projekt, von 6.5 auf 6.6 war ein Projekt, aber 6.6 auf 6.7 ist doch nur eine Stelle hinten. Ein Wartungsfenster, ein Composer-Update, Montag früh nachsehen, ob die Bestellbestätigungen rausgehen.
Das trifft für den Core halbwegs zu. Für alles, was eigene Oberflächen in der Administration mitbringt, nicht.
Was in 6.7 tatsächlich gebrochen ist
Die Administration ist von Vue 2 auf Vue 3 umgestellt, der Build läuft über Vite statt Webpack, und die Zustandsverwaltung liegt in Pinia statt in Vuex. Drei Schnitte auf einmal, alle in derselben Schicht. Für den Core hat Shopware das gemacht. Für dein Plugin macht es niemand.
Praktisch heißt das: Jeder Zugriff auf Shopware.State muss auf Shopware.Store umgezogen werden. Vue-2-Filter gibt es nicht mehr, $children und $listeners sind weg, und jede eigene build/webpack.config.js unter src/Resources/app/administration/ ist ab 6.7 Papier. Wer in Admin-Komponenten mit this.$refs auf Kindkomponenten zugegriffen hat, findet Stellen, die keinen Fehler werfen, sondern nur nichts mehr tun. Das ist die unangenehmere Sorte.
Die Storefront kommt milder weg. Twig bleibt Twig, SCSS bleibt SCSS. Reibung entsteht dort vor allem, wo ein Custom-Theme tief in Blöcke hineingreift, deren Markup wegen der Barrierefreiheits-Anpassungen geändert wurde: Formulare, Aria-Attribute, Fokus-Reihenfolge, Buttons, die früher <a> waren. Ein Theme, das zwanzig Blöcke überschreibt, ist an einem Tag durchgesehen. Eins, das die halbe Checkout-Strecke neu baut, nicht.
Die Inventur gehört vor den Termin, nicht in das Wartungsfenster
Bevor über ein Datum gesprochen wird, brauchst du eine Liste. bin/console plugin:list auf dem produktiven System, dazu die installierten Apps und Themes. Dann drei Spalten: Woher kommt es, gibt es eine 6.7-fähige Version, und was passiert, wenn es sie nie gibt.
Die Store-Erweiterungen sind der einfache Teil. Entweder im Shopware Store steht eine Version mit 6.7-Kompatibilität, oder es steht keine da. Wenn keine da ist und die letzte Aktualisierung zwei Jahre zurückliegt, hast du eine Antwort, die dir nicht gefällt, aber du hast sie früh.
Interessant sind die Eigenentwicklungen und die Auftragsarbeiten von vorherigen Dienstleistern. Öffne die composer.json des Plugins und schau auf das Constraint für shopware/core. Steht dort ~6.6.0, war jemand sorgfältig. Steht dort * oder >=6.4, wird das Plugin bei einem 6.7-Update mitinstalliert und startet, bis irgendwer die Einstellungsseite öffnet und eine weiße Fläche sieht. Wir haben Systeme übernommen, in denen genau das seit Wochen so war, ohne dass es jemand gemeldet hat, weil die Seite nur einmal im Quartal gebraucht wurde.
Dritte Spalte, die gern vergessen wird: die Schnittstellen. Ein Plugin, das Bestellungen an das ERP übergibt, hat oft gar keine Admin-Komponente und läuft nach dem Update unauffällig weiter. Ein Plugin, das dem Sachbearbeiter im Bestelldetail einen Reiter mit dem Übertragungsstatus einhängt, gehört zur Kategorie Vue 3.
Doppelte Plugin-Versionen sind kein Übergangsproblem, sondern eine Betriebsentscheidung
Ein Plugin mit Admin-Erweiterung kann 6.6 und 6.7 nicht sauber in einem Build bedienen. Die Praxis läuft daher auf zwei Zweige hinaus: eine 1.x-Linie für 6.6, eine 2.x-Linie für 6.7. Das ist bei Store-Herstellern der Normalfall und bei eigenen Plugins die Arbeit, die niemand einplant.
Wer mehrere Shops auf demselben Plugin-Bestand betreibt und sie nicht am gleichen Wochenende migriert, pflegt eine Zeit lang zwei Stände parallel. Kommt in dieser Zeit ein Bugfix, ist er zweimal zu bauen, zweimal zu testen, zweimal auszurollen. Das ist beherrschbar, wenn es sechs Wochen dauert. Bei sechs Monaten fangen die Zweige an, auseinanderzulaufen, und irgendwann korrigiert jemand einen Fehler nur im 6.7-Zweig, weil der andere ja bald wegfällt. Fällt er dann nicht weg, hast du zwei unterschiedlich funktionierende Shops mit identischer Plugin-Bezeichnung.
Unsere Erfahrung: Die Übergangszeit kurz halten ist billiger als sie gut zu organisieren. Wenn du drei Shops hast, migriere sie in einem Quartal, nicht in einem Jahr.
Woran du erkennst, ob 6.6 noch eine Saison trägt
Mit dem Erscheinen von 6.7 ist 6.6 in den erweiterten Support gegangen. Sicherheitsrelevantes kommt weiter, neue Funktionen nicht. Für einen Shop, der stabil läuft und dessen Peak im vierten Quartal liegt, kann Aussitzen die richtige Entscheidung sein. Drei Punkte entscheiden darüber.
Erstens der Plugin-Bestand. Wenn deine Inventur zwei oder drei Erweiterungen ohne 6.7-Version zeigt, die für den Betrieb tragend sind, hilft dir kein Termindruck. Dann brauchst du erst einen Ersatz oder eine Eigenentwicklung, und das ist ein Vorhaben mit eigener Laufzeit. Steht in der Liste nur unkritisches Zeug, ist das Update in wenigen Wochen machbar.
Zweitens die Barrierefreiheit. Der European Accessibility Act greift Ende Juni 2026, und für B2C-Shops ist das kein technisches Thema, sondern eine Frist. Shopware hat einen Teil der Anpassungen auf 6.6 zurückportiert, dort liegen sie aber hinter dem Feature-Flag ACCESSIBILITY_TWEAKS und sind standardmäßig aus. Du kannst sie einschalten. Dann prüfst du dein Theme und die installierten Erweiterungen gegen das geänderte Markup, und zwar in derselben Tiefe wie bei einem Update. Der Weg über 6.6 ist möglich, spart aber weniger, als er verspricht.
Drittens der Kalender. Ein Shop, der im November das Dreifache seines Normalumsatzes macht, wird nicht im Oktober auf 6.7 gehoben. Dann bleibt 6.6 bis Januar stehen, mit eingeschaltetem Accessibility-Flag und einer bis dahin abgeschlossenen Plugin-Inventur, damit im Januar nicht die Frage beginnt, sondern die Arbeit.
Was gegen Aussitzen spricht: Jeder Monat auf 6.6 verlängert die Strecke, die später aufzuholen ist. Und es gibt keine Version 7, die man abwarten könnte. Die Linie läuft mit 6.8 weiter, angekündigt für 2027. Wer 6.7 überspringt, macht den Vue-3-Umbau später trotzdem, nur mit einem zusätzlichen Sprung obendrauf.
Der realistische Ablauf
Ein 6.7-Update, das ohne Überraschungen durchgeht, hat drei Phasen und der Deploy-Abend ist die kürzeste davon. Die Inventur dauert bei einem mittelgroßen Shop mit zwanzig bis dreißig Erweiterungen etwa zwei Tage. Danach kennst du die Aufwandsspanne und kannst über einen Termin reden. Die Umbauarbeit an eigenen Plugins und am Theme ist der Block, dessen Länge sich nicht abkürzen lässt: Ein Plugin, das im Admin nur ein Konfigurationsfeld anhängt, ist in einer Stunde geprüft; eins mit eigenem Modul, Pinia-fähigem Store und Datengrid beschäftigt einen Entwickler mehrere Tage. Dann ein Staging-Durchlauf mit echtem Datenbestand, inklusive der Vorgänge, die man beim Testen übersieht: Retoure anlegen, Gutschrift, Bestellung nachträglich ändern, ERP-Abgleich über Nacht.
Eine Frage bleibt bei uns regelmäßig offen und wird auch hier nicht geklärt: Was mit den älteren Apps passiert, die über die App-Schnittstelle iframes in die Administration einhängen. Die sind formal von Vue 3 nicht betroffen, weil sie ihre Oberfläche selbst ausliefern. In der Praxis haben wir dort trotzdem Effekte gesehen, wenn die App auf Admin-Ereignisse gehört hat. Das ist Einzelfallprüfung, und für eine belastbare Aussage haben wir zu wenige Fälle.
Der sinnvolle nächste Schritt ist unabhängig davon, wann du migrierst: die Liste erstellen. Solange niemand weiß, welche der installierten Erweiterungen eine 6.7-Version hat, ist jede Terminaussage geraten, und zwar in beide Richtungen.
KI-generierter Inhalt.