Auf Shopware 6.7 wechseln oder bei 6.6 bleiben
Wir betreiben beide Linien parallel und haben verglichen, was sich messbar unterscheidet. Das Ergebnis spricht für einen Wechsel — aber nicht aus den Gründen, die meist genannt werden.
Die Frage kommt in jedem zweiten Gespräch: Lohnt der Wechsel auf 6.7, oder reicht 6.6 noch? Die üblichen Antworten sind eine Funktionsliste oder ein Verweis auf das Supportende. Beides hilft bei der Entscheidung wenig.
Wir betreiben beide Linien parallel, mit identischem Pluginstand, um Erweiterungen zu prüfen. Also haben wir verglichen, was sich messbar unterscheidet.
Die Messung
Derselbe Befehl in beiden Installationen:
| 6.6.10.6 | 6.7.13.1 | |
|---|---|---|
| Storefront-Routen (Kern) | 101 | 107 |
Migrationen im Verzeichnis V6_7 | 8 | 149 |
| Flow-Aktionen im Kern | 17 | 17 |
| Sitemap-URL-Quellen | 6 | 6 |
Feld description_teaser am Produkt | nicht vorhanden | vorhanden, schreibgeschützt |
Vier Zeilen, vier verschiedene Aussagen.
Was die Zahlen bedeuten
Sechs Routen mehr — und eine davon kann wehtun
Die Storefront hat in 6.7 sechs zusätzliche Kernrouten. Das klingt harmlos und ist der Punkt mit dem grössten Überraschungspotenzial: Eine dieser Routen belegt einen Pfad, den vorher eine unserer Erweiterungen bediente.
Nachtrag vom 17.09.2026: Hier stand zunächst „neun Routen". Das war die Rohzahl — 132 gegen 141 — und sie enthielt die Routen der installierten Erweiterungen, die sich zwischen den beiden Testsystemen unterscheiden. Nach Herkunft getrennt (Namensraum des Controllers) sind es 101 gegen 107 Kernrouten, also sechs. An der Aussage ändert das nichts, an der Zahl schon.
Das Ergebnis ist nicht ein Fehler, sondern Stille. Die Erweiterung bleibt aktiv, ihre Konfiguration bleibt speicherbar, die URL antwortet mit Status 200 — nur der Inhalt kommt jetzt aus dem Kern. Den vollständigen Messweg haben wir aufgeschrieben: Wenn der Shopware-Kern eine Plugin-Route verdrängt.
Für die Entscheidung heisst das: Ein Kompatibilitätstest, der bei „installiert und Seite lädt" aufhört, findet diese Klasse von Regression nicht.
149 Migrationen sind der eigentliche Sprung
Der Unterschied zwischen 8 und 149 Migrationen im selben Verzeichnis ist die ehrlichste Zahl in der Tabelle. Sie beschreibt, wie viel sich an der Datenbank tut — und damit, wie gründlich ein Testlauf mit echten Daten sein sollte.
Ein Update ist kein Schalter. Es ist ein Datenbankvorgang, den man einmal auf einer Kopie durchspielt, bevor man ihn im Produktivsystem auslöst.
Was sich nicht ändert
Flow-Aktionen: 17 zu 17. Sitemap-Quellen: 6 zu 6. Wer auf 6.7 wechselt, weil er mehr Automatisierungsmöglichkeiten oder eine bessere Sitemap erwartet, wechselt aus dem falschen Grund. Die Details stehen in Flow Builder: Auslöser, Aktionen und Grenzen und Die Sitemap in Shopware.
Ein neues Feld, das Integrationen bricht
description_teaser gibt es in 6.6 nicht. In 6.7 wird es über die API
ausgeliefert, ist aber schreibgeschützt. Integrationen, die einen gelesenen
Datensatz vollständig zurückschreiben, brechen daran — auch wenn sie das Feld
nie angefasst haben. Ausführlich in
Produktdaten übersetzen, ohne Daten zu verlieren.
Die Entscheidungshilfe
Nicht nach Katalogumfang, sondern nach dem, was den Aufwand tatsächlich treibt:
| Ihre Lage | Empfehlung |
|---|---|
| Wenige Erweiterungen, alle aus dem Store, alle mit 6.7-Freigabe | wechseln — der Aufwand ist überschaubar |
| Viele Erweiterungen, davon einige individuell entwickelt | wechseln, aber planen — die Prüfung ist das Projekt, nicht das Update |
| Individuelle Erweiterungen ohne aktive Pflege | erst klären, wer sie prüft — sonst wechseln Sie in ein Risiko |
| Anbindung an Warenwirtschaft oder PIM mit Rückschreibpfad | Schreibpfad zuerst prüfen — siehe das neue Feld oben |
| Laufender Relaunch oder grosses Projekt | danach — zwei grosse Änderungen gleichzeitig sind nicht trennbar |
| „Wir warten auf 6.8" | schlechter Plan — der Sprung wird grösser, nicht kleiner |
Was wir vor einem Wechsel prüfen
Fünf Punkte, in dieser Reihenfolge:
- Erweiterungsliste gegen Freigaben. Welche haben eine 6.7-Version, welche nicht, welche werden nicht mehr gepflegt?
- Routen vergleichen.
debug:routervor und nach dem Update, Ausgabe gegenüberstellen, doppelte Pfade suchen. Eine Minute Aufwand für die Regression, die sich sonst nicht meldet. - Schreibpfade der Integrationen ansehen. Wird ein gelesener Datensatz zurückgeschrieben oder ein Änderungsobjekt gebaut?
- Update auf einer Kopie mit echten Daten fahren. Wegen der 149 Migrationen.
- Wirkung messen, nicht Anwesenheit. Je Erweiterung: Was soll sie tun, und tut sie es noch?
Punkt 5 ist der, der in Checklisten fehlt und in der Praxis den Unterschied macht.
Unsere Empfehlung
Wechseln, aber nicht nebenbei. Der Kern ist stabil; die 149 Migrationen laufen durch. Das Risiko liegt bei dem, was zusätzlich installiert ist — und dort in Verhalten, das sich nicht als Fehler meldet.
Wer heute auf 6.6 steht, sollte den Wechsel als eigenes kleines Projekt planen, nicht als Wartungsfenster. Und wer ihn plant, sollte die Prüfung der Erweiterungen einrechnen, nicht das Update.
Wie wir solche Wechsel begleiten, steht auf Shopware-Agentur; die laufende Betreuung danach auf Shopware-Support.
Häufige Fragen
- Ist 6.6 unsicher, wenn wir bleiben?
- Nicht automatisch. Solange die Linie Sicherheitsaktualisierungen bekommt, ist Bleiben eine legitime Entscheidung. Die Frage ist, wie lange das noch gilt — und ob Sie dann unter Zeitdruck wechseln müssen.
- Wie lange dauert ein Wechsel?
- Das hängt fast ausschliesslich an den Erweiterungen. Der Kern selbst aktualisiert sich in Stunden. Die Prüfung von zwanzig Erweiterungen dauert Tage.
- Reicht es, wenn der Shop nach dem Update läuft?
- Nein. Ein Shop kann vollständig funktionieren, während Erweiterungen still nichts mehr beitragen. Prüfen Sie die Wirkung, nicht die Anwesenheit.
- Sollten wir auf 6.8 warten?
- Warten verschiebt den Aufwand, es verringert ihn nicht — und der Sprung wird grösser. Wer heute auf 6.6 steht, hat bei einem Wechsel auf 6.8 zwei Hauptversionen aufzuholen statt einer.