Shopware-Updates
Shopware 6.7 ist die aktuelle Major-Linie; 6.7.0.0 erschien am 17. Juni 2025, der aktuelle Stand der Linie ist 6.7.13.0 vom 5. August 2026. Der Sprung von 6.6 auf 6.7 ist technisch der größte seit dem Start von Shopware 6: Vue 3 statt Vue 2, Vite statt Webpack, Pinia statt Vuex. Deshalb ist ein Update auf 6.7 kein Wartungsvorgang, sondern ein Projekt mit Anfang und Ende — mit Plugin-Inventar, Staging-Durchlauf, Testliste für den Bestellprozess und einem Rückweg, der vorher festgelegt ist. Die Sharpness Solutions GmbH in Oldenburg fährt solche Updates an selbst gehosteten Shops, auch an Shops, die jemand anders gebaut hat. Stand dieser Seite: 17. August 2026.
Anfragen zu Shopware-Updates kommen selten aus Interesse an neuen Funktionen. Sie kommen, weil eine Erweiterung nur noch für 6.7 gepflegt wird, weil der Hoster die PHP-Version hochzieht, weil ein Audit läuft — oder weil ein erster Update-Versuch in einer leeren Administration endete. Die vier Ausgangslagen unten decken den größten Teil dessen ab, womit Betreiber bei uns ankommen. Gemeinsam haben sie eins: Der Aufwand steckt nicht im Update selbst, sondern in allem, was daran hängt.
Der Aufwand hängt an fünf Größen. Vier davon können Sie selbst zählen: die Zahl der Store-Erweiterungen, die Zahl der eigenen Plugins mit Dateien unter src/Resources/app/administration/, den Umfang des Custom-Themes, gemessen in überschriebenen Twig-Blöcken, und die Zahl der angebundenen Systeme. Die fünfte Größe ist der Zustand des Codes, und den kann man nur lesen, nicht zählen.
Nach dem Sprung auf 6.7 lädt die Administration nicht mehr, oder einzelne Module fehlen ohne Fehlermeldung. Die Ursache ist fast immer eine Erweiterung, die noch gegen Vue 2, Vuex oder Webpack gebaut ist. Im PHP-Log steht dazu wenig, weil der Bruch im Build der Administration passiert und nicht zur Laufzeit.
Dann geht es nicht um ein Update. Shopware 5 ist seit Ende Juli 2024 aus der Herstellerwartung, und der Weg auf 6.7 ist ein Neuaufbau mit Datenübernahme: neues Theme, neue Erweiterungen, neu angebundene Schnittstellen, vollständige Redirect-Liste. Das wird als Projekt kalkuliert, nicht als Versionssprung.
Updates laufen über den Updater in der Administration, ein Backup existiert, zurückgespielt hat es nie jemand. Damit ist jedes Update ein Test im Livebetrieb. Diese Lücke schließen wir vor dem Versionssprung, nicht danach — sie macht auch jeden folgenden Patch-Stand billiger.
Shopware zählt vierstellig. In 6.7.13.0 bezeichnen die ersten beiden Stellen die Major-Linie, die dritte das Minor-Release, die vierte den Patch-Stand. Minor-Releases erscheinen nach der Release-Policy am ersten Montag im Monat und bringen Funktionen, Fehlerkorrekturen und Sicherheitsfixes; Patch-Releases kommen dazwischen, wenn ein Fehler es verlangt. Für Major-Releases nennt Shopware keinen Takt: 6.7 erschien im Juni 2025, 6.8 wird erst für 2027 erwartet. Breaking Changes stehen im Major. Aus dieser Einteilung folgt die Risikoeinschätzung, und sie ist alles andere als symmetrisch. Ein Patch-Stand ist eine Betriebsaufgabe, ein Major-Sprung ist ein Projekt. Wer beides gleich behandelt, macht entweder das eine zu aufwendig oder das andere zu leichtfertig.
Bei Patch- und Minor-Ständen innerhalb von 6.7 ist das Risiko begrenzt, aber nicht null. Betroffen ist, was an internen APIs hängt statt an den dokumentierten Erweiterungspunkten, und was in Templates auf Markup zeigt, das sich geändert hat. Eine praktische Regel aus dem Betrieb: neue x.x.x.0-Releases nicht sofort einspielen. Shopware hat 6.7.12.0 kurz nach der Veröffentlichung gesperrt — laut Release-Notes lässt sich diese Version wegen eines nachträglich entdeckten Fehlers nicht installieren oder aktualisieren, stattdessen ist 6.7.12.1 zu verwenden. Wer einen Monat später einsteigt, spart sich diese Klasse von Überraschungen.
Beim Major-Sprung von 6.6 auf 6.7 ändert sich nicht nur der Code, sondern auch der Unterbau. Shopware nennt für 6.7 als Mindestanforderung PHP 8.2, 8.3 oder 8.4, Node.js ab 20 für den Administration-Build, MySQL ab 8.0.17 oder MariaDB ab 10.11 und Redis ab 7.0, falls im Einsatz. Die Dokumentation benennt dabei ausdrücklich problematische Zwischenversionen: MySQL 8.0.20 und 8.0.21, MariaDB 10.11.5 und 11.0.3. Das sind Mindestwerte und keine Empfehlungen — für den Betrieb führt der Hosting-Guide einen neueren Stack. Wer heute auf PHP 8.1 oder MariaDB 10.6 sitzt, hat zwei Vorhaben und nicht eines — und die Reihenfolge steht fest: erst der Unterbau, dann die Anwendung.
Die Administration von Shopware 6 ist eine Vue-Anwendung, kein Satz von Formularseiten. Eine Erweiterung ruft dort keine stabile Schnittstelle auf, sondern wird Teil dieser Anwendung: Sie überschreibt Twig-Blöcke der Administration-Templates, registriert oder erweitert Komponenten über Component.register() und Component.override(), bringt einen eigenen Einstiegspunkt unter src/Resources/app/administration/ mit und wird in denselben Build kompiliert wie der Core. Genau daraus folgt der Aufwand von 6.7: Wenn die Anwendung von Vue 2 auf Vue 3 wechselt, wechselt der Vertrag mit jedem Plugin, das sich dort eingehängt hat.
Drei Umbauten wirken gleichzeitig. Erstens ist die Vue-2-Kompatibilitätsschicht entfallen; Komponenten müssen gegen Vue 3 laufen. Zweitens ersetzt Pinia das State-Management Vuex — aus Shopware.State.get() wird Shopware.Store.get(), und eigene Stores werden neu registriert. Drittens baut die Administration mit Vite statt mit Webpack; eine eigene webpack.config.js wird zur vite.config.js. Webpack und Vite sind nicht kreuzkompatibel: Wer ein Plugin für beide Linien pflegt, braucht getrennte Releases für 6.6 und 6.7. Als Faustregel für das Inventar genügt ein Blick ins Verzeichnis — jede Erweiterung mit Dateien unter src/Resources/app/administration/ ist betroffen.
Auf der PHP-Seite und im Storefront kommt der zweite Block dazu. 6.7 hebt DBAL auf 4, PHPUnit auf 11, Dompdf auf 3 und league/oauth2-server auf 9 und zieht die Symfony-Komponenten auf 7.3 nach; den Sprung auf Symfony 7 selbst hat bereits 6.6 gemacht, er steht also nicht mehr an. Die Payment-Handler sind auf eine einheitliche AbstractPaymentHandler-Klasse zusammengeführt, das Store-API-Route-Caching samt aller Cached*Route-Klassen ist entfallen, die verzögerte Cache-Invalidierung ist standardmäßig aktiv und die frühere Konfiguration shopware.cache.invalidation.delay ist weggefallen. Bei Zahlungs- und Versandarten ist technicalName Pflicht, und Custom-Field-Namen mit Bindestrich oder Punkt werden nicht mehr akzeptiert: Feld- und Feldset-Namen müssen gültige Twig-Variablennamen sein. Im Storefront laden Header und Footer per ESI, damit sie unabhängig gecacht werden können, und der Barrierefreiheits-Umbau hat Markup, ARIA-Attribute und Blockstruktur verändert. Was in 6.6 noch hinter dem Feature-Flag ACCESSIBILITY_TWEAKS lag, ist in 6.7 Standard — die Pagination läuft über Anchor-Links statt über Radio-Inputs, Icons aus dem Icon-Helper tragen aria-hidden. Ein Custom-Theme ist deshalb genauso betroffen wie ein Plugin: Jeder überschriebene Twig-Block muss gegen das neue Original gelesen werden, weil er sonst still eine alte Struktur zurückbringt.
Bei fremden Erweiterungen ist die Lage inzwischen besser als kurz nach dem Release. Anfang 2026 haben die großen Store-Plugins kompatible Fassungen für 6.7 — in den ersten Monaten war das anders, und daher stammt ein guter Teil der Update-Angst. Der Engpass sind heute die individuell gebauten Erweiterungen und die kleinen ohne Betreuer. Einen ersten Überblick liefert Shopware selbst: Unter Einstellungen → System → Shopware-Updates steht je aktiver Erweiterung einer von drei Zuständen. Diese Liste ist ein Anfang und keine Freigabe — sie kennt Ihren eigenen Code nicht und sagt über Templates gar nichts.
Von Shopware 5 auf Shopware 6 gibt es keinen Update-Pfad, sondern nur einen Neuaufbau mit Datenübernahme. Shopware 6 ist ein anderes System: Twig statt Smarty, ein anderes Datenmodell, eine andere Plugin-Architektur. Übernommen werden Daten — Produkte, Varianten, Kategorien, Kunden, Bestellungen, Medien, Custom Fields, SEO-URLs — über den Shopware-Migrations-Assistenten. Theme, Erweiterungen und Schnittstellen entstehen neu. Statt Plugin-Update steht hier Plugin-Ersatz: Für jede Funktion wird entschieden, ob eine 6.7-Erweiterung sie abdeckt, ob sie nachgebaut wird oder ob sie entfällt, weil sie ohnehin niemand benutzt hat.
Für die Planung folgen daraus zwei Dinge. Erstens ist Zielversion direkt der aktuelle 6.7-Stand. Ein Zwischenschritt über 6.6 bringt nichts, weil ohnehin neu gebaut wird, und würde den Umbau auf Vue 3, Vite und Pinia nur einplanen, um ihn später zu wiederholen. Zweitens ist der Termin nicht beliebig: Shopware 5 ist seit Ende Juli 2024 aus der Herstellerwartung, und wer den Termin nicht halten kann, kauft mit den kostenpflichtigen safefive-Patches Zeit — das verschiebt die Migration und ersetzt sie nicht. Am Umschalttag entscheidet dann die Redirect-Liste: Die SEO-URLs aus Shopware 5 lassen sich mitnehmen, die URL-Struktur von Shopware 6 ist aber eine andere, und ohne vollständige Weiterleitungen verlieren Sie gewachsene Sichtbarkeit. Wir erzeugen die Liste aus dem Altbestand und prüfen sie vor dem Cutover; Rankingversprechen gibt es dazu nicht, von uns so wenig wie von jemand anderem.
Kalkuliert wird eine Migration deshalb anders als ein Update. Beim Update zählen Sie Erweiterungen, Administration-Anteile und überschriebene Twig-Blöcke und rechnen Anpassungsaufwand je Position. Bei der Migration rechnen Sie einen Neubau, dazu Datenübernahme, Abgleich und Redirects — und Sie entscheiden bei jeder Funktion neu, ob sie überhaupt mitkommt. Wer beides in einen Topf wirft, bekommt eine Zahl, die für keinen der beiden Fälle stimmt. Den Migrationsweg im Einzelnen — Migrations-Assistent, Mappings, Datenabgleich, Cutover — beschreibt unsere Seite zur Shopware-Hilfe. Auf dieser Seite geht es um den Weg innerhalb von Shopware 6.
Am Anfang steht eine Staging-Kopie mit echten Daten. Echte Katalog- und Bestelldaten sind nötig, weil sich Fehler in Preislogik, Steuersätzen, Rabattregeln und Bestelldokumenten an Testartikeln nicht zeigen. Vier Dinge werden abgeklemmt, bevor der erste Aufruf passiert: der Mailversand, damit niemand Bestellbestätigungen aus dem Testsystem bekommt; die Zahlungsanbieter, die auf Sandbox-Zugänge umgestellt werden; die ERP-Schnittstelle, die auf einen Testmandanten zeigt; und die Indexierung durch Suchmaschinen. Personenbezogene Kundendaten werden pseudonymisiert oder das System läuft geschlossen — eine Staging-Instanz mit echten Kundendaten und offener Erreichbarkeit ist ein Datenschutzvorfall mit Anlauf.
Aktualisiert wird über die Kommandozeile, nicht über den Updater im Browser. Der dokumentierte Weg läuft in zwei Hälften: lokal die Zielversion in die composer.json, dann composer update --no-scripts und composer recipes:update, danach committen und deployen. Auf dem Server folgen sales-channel:maintenance:enable --all, system:update:prepare, system:update:finish und am Ende sales-channel:maintenance:disable --all. Danach die Nacharbeit, die gern vergessen wird: Build der Administration, theme:compile, dal:refresh:index, bei aktiver Suche es:index, Cache-Warmup. Den Updater in der Administration empfiehlt Shopware ausdrücklich nur für kleine Instanzen, weil er im Browser läuft und bei größeren Shops in Timeouts und Memory-Limits läuft. Der Weg über das Repository hat außerdem den Vorteil, dass dieselbe Änderung zweimal identisch ausgeführt wird: erst auf Staging, dann live.
Die Testliste wird vor dem Staging-Durchlauf geschrieben und danach abgehakt, nicht umgekehrt. Sie enthält mindestens: eine vollständige Bestellung mit jeder aktiven Zahlungsart, jede Versandart, einen Gutschein, einen Staffelpreis, einen Kundengruppenpreis, Netto- und Bruttoanzeige mit jedem verwendeten Steuersatz, Rechnung und Lieferschein als PDF, den Bestellexport ins ERP, die Bestandsrückmeldung, Registrierung, Passwort-Reset, Mailversand und die Verkaufskanäle einzeln, wenn es mehrere gibt. Das Wartungsfenster liegt außerhalb der Umsatzzeit. Welche Stunde in Ihrem Shop die schwächste ist, steht in Ihrer eigenen Auswertung und nicht in einer Faustregel.
Der Rückweg gehört in den Plan, bevor umgeschaltet wird — mit einem Abbruchkriterium, das vorher benannt ist, und nicht mit einem Gefühl um drei Uhr nachts. Bei einem Blue-Green-Deployment lässt sich laut Shopware auf die alte Umgebung zurückschalten, ohne ein Backup zurückzuspielen; empfohlen ist das aber nur, wenn ausschließlich Shopware und nicht gleichzeitig Erweiterungen aktualisiert wurden. Die ehrliche Grenze dahinter: Datenbank-Migrationen laufen nur vorwärts. Wer nach dem Umschalten auf den Dump zurückgeht, verliert die Bestellungen, die dazwischen eingegangen sind. Genau deshalb ist das Fenster kurz, liegt in der schwächsten Umsatzstunde und beginnt mit einem Backup von Datenbank und Dateien, das unmittelbar davor gezogen wurde.
Drei Ausfälle treten nach unbegleiteten Updates auf 6.7 wiederholt auf, und alle drei sind unauffällig. Erstens fällt eine Zahlungsart aus: Der Handler ist nicht auf AbstractPaymentHandler umgestellt oder der technicalName fehlt, die Methode verschwindet aus dem Checkout, der Shop läuft ansonsten normal. Zweitens rechnet die Preislogik falsch: Eine Erweiterung, die in Rabatt- oder Preisberechnung eingreift, kommt nicht mehr zum Zug, die Bestellung geht durch — mit dem falschen Betrag. Das ist der teuerste Fall, weil er wochenlang unbemerkt bleiben kann. Drittens schweigt die ERP-Schnittstelle: Ein umbenanntes Custom Field oder ein entfallener Endpunkt passt nicht mehr, und auffällig wird es erst, wenn die Ware nicht rausgeht.
Deshalb gehört nach dem Go-Live ein Monitoring dazu, das mehr misst als Erreichbarkeit. Sinnvoll sind vier Werte im Vergleich zur Woche davor: Zahl der abgeschlossenen Bestellungen, Fehlerrate im Log, Zahl der Bestellungen ohne Quittung aus dem ERP und die Dauer eines Indexlaufs. Wer nur prüft, ob die Startseite antwortet, überwacht die Größe, die im Störungsfall zuletzt kippt.
Für die Planung ist 6.8 die nächste Marke: erwartet für 2027, ohne festes Datum. Shopware koppelt die Supportübergänge an Major-Releases statt an Kalenderdaten und kennt vier Zustände — Maintained, Extended Support, Security fixes only, End of life. 6.6 ist mit dem Erscheinen von 6.7 in den Extended Support gewechselt und bleibt dort, bis 6.8 erscheint; angelegt war dieser Zustand auf ein Jahr, mit der Verschiebung von 6.8 auf 2027 hat Shopware ihn verlängert. Im Extended Support erhält der jeweils letzte Minor ausgewählte Bugfixes und Sicherheitsupdates als Patch, ältere Minors Sicherheitsfixes über das Security-Plugin, und laut Shopware folgt danach ein weiteres Jahr Sicherheitsupdates über dieses Plugin. Praktisch heißt das: Wer jetzt auf 6.7 geht, hat den Vue-3-, Vite- und Pinia-Umbau hinter sich, wenn 6.8 kommt. Dass 6.8 für Erweiterungen der kleinere Sprung wird, ist eine begründete Erwartung und keine Zusage von Shopware.
Es gibt den Fall, in dem wir von einem Update abraten. Wenn der Shop in absehbarer Zeit ohnehin ersetzt oder neu gebaut wird, ist der 6.7-Umbau Geld, das zweimal ausgegeben wird — die angepassten Plugins und Templates landen im Papierkorb des Neubaus. Dann ist 6.6 im Extended Support mit einem verbindlichen Termin für den Neuaufbau die günstigere Antwort. Wenn ein Projekt sich nicht rechnet, sagen wir das vor dem Angebot und nicht danach.
Ablauf
Schicken Sie uns Version und Patch-Stand und die Ausgabe von bin/console plugin:list, oder einen Screenshot aus Einstellungen → System → Shopware-Updates. Sie bekommen eine schriftliche Einschätzung mit Zielversion, Risikoliste, Aufwandsrahmen und Vorschlag für das Wartungsfenster — auch dann, wenn Sie danach woanders beauftragen. Sharpness Solutions GmbH, Edewechter Landstraße 161, 26131 Oldenburg. Telefon 0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr, info@sharpness.de.
Wir sichten Version und Patch-Stand, composer.json und composer.lock, die Plugin- und App-Liste mit Herkunft — Store, Eigenentwicklung, Altagentur —, die Dateien unter src/Resources/app/administration/, das Custom-Theme mit seinen überschriebenen Blöcken, die angebundenen Systeme sowie PHP-, Datenbank- und Node-Version. Fehlt das Repository, rekonstruieren wir den Stand vom Server.
Jede Erweiterung wird einzeln bewertet: Gibt es eine 6.7-Fassung, ist eine Anpassung nötig, gibt es Ersatz, oder wird sie abgeschaltet? Store-Erweiterungen prüfen wir gegen Store und Shopware-Account, eigene gegen den Code. Erweiterungen, die niemand mehr benutzt, fliegen hier raus — das ist der billigste Teil des Projekts und wird am häufigsten übersprungen.
Vor der ersten Zeile Code steht das Ergebnis: Zielversion, Reihenfolge der Schritte, Liste der Erweiterungen mit Aufwand je Position, benanntes Wartungsfenster und die Punkte, die sich erst am Testsystem entscheiden lassen. Für klar abgegrenzte Teile gibt es einen Festpreis, für den Rest eine Schätzung nach Gewerken.
Wir spiegeln Datenbank und Dateien in eine Staging-Umgebung, klemmen den Mailversand ab, stellen Zahlung auf Sandbox und ERP auf einen Testmandanten und pseudonymisieren Kundendaten. Existiert kein Staging, richten wir eines ein. Danach läuft der erste vollständige Durchlauf über die Kommandozeile, inklusive Administration-Build, theme:compile und Indexlauf. Was bricht, bricht hier.
Die Anpassung eigener Plugins und Templates ist der längste Block: Vue 3, Pinia statt Vuex, Vite statt Webpack, Payment-Handler, Custom-Field-Namen, überschriebene Twig-Blöcke gegen das neue Original. Parallel testen Sie am Staging-System gegen die Testliste. Freigegeben wird schriftlich, Position für Position.
Der Go-Live läuft im vereinbarten Fenster außerhalb der Umsatzzeit, mit Backup unmittelbar davor, Maintenance-Modus je Verkaufskanal und definiertem Abbruchkriterium. Danach engeres Monitoring der vier Kennzahlen, Nacharbeiten aus der Abnahme, Übergabe der Dokumentation. Zum Schluss die Frage, wer künftig die monatlichen Minor- und Patch-Stände einspielt: Sie selbst oder wir über ein SLA.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Offline ist der Shop nur im Wartungsfenster beim Umschalten, nicht während des Projekts: Gearbeitet wird auf einer Staging-Kopie, der Live-Shop verkauft unverändert weiter. Im Fenster selbst gehen die Verkaufskanäle über sales-channel:maintenance:enable --all in den Wartungsmodus, danach laufen system:update:prepare und system:update:finish, anschließend die Builds für Administration und Theme und der Indexlauf. Wie lange das dauert, hängt an Katalog- und Bestellmenge und steht nach dem Staging-Durchlauf fest, weil wir es dort messen. Eine Zahl davor wäre geraten.
Wir spielen vor dem Major-Sprung immer erst den letzten Minor der 6.6-Linie mit aktuellem Patch-Stand ein, also 6.6.10.x. Zwei Gründe: Shopware pflegt aktiv den jeweils letzten Minor einer Linie, und wer zwei Sprünge gleichzeitig macht, kann hinterher nicht unterscheiden, welcher davon etwas zerlegt hat. Deshalb läuft die Kette in Schritten, jeder mit einem eigenen Funktionstest auf Staging.
Ein Update von 6.6 auf 6.7 wird nach Aufwand kalkuliert. Den Aufwand bestimmen fünf Größen: Zahl der Store-Erweiterungen, Zahl der eigenen Plugins mit Administration-Anteil, Umfang des Custom-Themes in überschriebenen Twig-Blöcken, Zahl der angebundenen Systeme und der Zustand des Codes. Die ersten vier zählen Sie selbst, den fünften liest jemand von außen. Nach dem Plugin-Inventar gibt es einen Festpreis für die abgegrenzten Teile und eine Schätzung für den Rest. Eine Preisliste würde einen Durchschnitt kalkulieren, den Sie mitbezahlen.
Weil die Administration von Shopware 6 eine Vue-Anwendung ist und eine Erweiterung dort nicht eine Schnittstelle aufruft, sondern Teil der Anwendung wird: Sie überschreibt Twig-Blöcke, erweitert Komponenten über Component.override() und wird in denselben Build kompiliert. In 6.7 ist die Vue-2-Kompatibilitätsschicht entfallen, Pinia hat Vuex ersetzt und Vite hat Webpack ersetzt. Damit ändert sich der Vertrag mit jedem Plugin. Die Faustregel für das Inventar: Jede Erweiterung mit Dateien unter src/Resources/app/administration/ ist betroffen.
Einen ersten Überblick gibt Shopware selbst: Unter Einstellungen → System → Shopware-Updates steht je aktiver Erweiterung einer von drei Zuständen — bereits kompatibel, kompatibel mit der neuen Shopware-Version, oder nicht kompatibel, weil keine Nachfolgeversion existiert. Dieselbe Information liefern der Store und der Shopware-Account unter Lizenzen. Die Liste kennt Ihren eigenen Code nicht und sagt über Templates nichts. Anfang 2026 haben die großen Store-Plugins kompatible Fassungen; der Engpass sind die individuell gebauten und die kleinen ohne Betreuer.
Für kleine Instanzen ist er vertretbar, für größere nicht — Shopware empfiehlt ihn ausdrücklich nur für kleine Shops, weil er im Browser läuft und dabei in Timeouts, Memory-Limits und andere Ressourcengrenzen läuft. Der belastbare Weg führt über composer und bin/console: composer update --no-scripts und composer recipes:update lokal, dann system:update:prepare und system:update:finish auf dem Server. Der zweite Grund ist der wichtigere: Über das Repository wird dieselbe Änderung zweimal identisch ausgeführt, erst auf Staging, dann live.
Ein individuelles Theme übersteht den Sprung auf 6.7 nicht unverändert. Der Aufwand skaliert nicht mit dem Aussehen, sondern mit der Zahl der überschriebenen Twig-Blöcke: Jeder davon muss gegen das neue Original gelesen werden, weil er sonst still eine alte Struktur zurückbringt. Dazu kommen zwei Änderungen, die jedes Theme berühren: Header und Footer laden per ESI, und der Barrierefreiheits-Umbau des Storefront ist in 6.7 Standard geworden — er hat Markup, ARIA-Attribute und Blockstruktur verändert, etwa die Pagination von Radio-Inputs auf Anchor-Links. Themes mit wenigen überschriebenen Blöcken kommen entsprechend günstig durch.
Shopware 6.6 ist mit dem Erscheinen von 6.7 in den Extended Support gewechselt und bleibt dort, bis 6.8 erscheint — erwartet für 2027, ohne festes Datum. Ursprünglich war dieser Zustand auf ein Jahr angelegt; mit der Verschiebung von 6.8 auf 2027 hat Shopware ihn verlängert. Shopware kennt vier Zustände: Maintained, Extended Support, Security fixes only, End of life, und koppelt die Übergänge an Major-Releases statt an Kalenderdaten. Im Extended Support erhält der jeweils letzte Minor — bei 6.6 also 6.6.10.x — ausgewählte Bugfixes und Sicherheitsupdates als Patch, ältere Minors Sicherheitsfixes über das Security-Plugin; danach folgt laut Shopware ein weiteres Jahr Sicherheitsupdates über dieses Plugin.
Nein, von Shopware 5 auf Shopware 6 gibt es keinen Update-Pfad. Der Wechsel ist ein Neuaufbau mit Datenübernahme: Twig statt Smarty, anderes Datenmodell, andere Plugin-Architektur. Theme und Erweiterungen entstehen neu, Schnittstellen werden neu angebunden, Daten kommen über den Shopware-Migrations-Assistenten mit. Zielversion ist dabei direkt der aktuelle 6.7-Stand; ein Zwischenschritt über 6.6 bringt nichts, weil ohnehin neu gebaut wird. Den Migrationsweg im Detail beschreibt unsere Seite zur Shopware-Hilfe.
Ja, ein Update innerhalb von Shopware 6 lässt Daten und URLs unangetastet: Bestellungen, Kunden, Produkte, Medien und SEO-URLs bleiben, die Datenbank wird migriert und nicht ersetzt. Zwei Stellen brauchen trotzdem Aufmerksamkeit. Custom-Field-Namen mit Bindestrich oder Punkt akzeptiert 6.7 nicht mehr — sie müssen gültige Twig-Variablennamen sein, also umbenannt und in allen Templates und Schnittstellen mitgezogen werden. Und die Bestelldokumente prüft man nach dem Update einzeln nach, weil Dompdf auf Version 3 gewechselt ist und Layouts sich verschieben können.
Es gibt einen Rückweg, und er hat eine Grenze. Bei einem Blue-Green-Deployment lässt sich laut Shopware auf die alte Umgebung zurückschalten, ohne ein Backup zurückzuspielen; empfohlen ist das aber nur, wenn ausschließlich Shopware und nicht gleichzeitig Erweiterungen aktualisiert wurden. Die Grenze: Datenbank-Migrationen laufen nur vorwärts. Wer nach dem Umschalten auf den Dump zurückgeht, verliert die Bestellungen, die in der Zwischenzeit eingegangen sind. Deshalb liegt das Fenster in der schwächsten Umsatzstunde, ist kurz, beginnt mit einem frischen Backup und hat ein Abbruchkriterium, das vorher schriftlich feststeht.
Auf 6.8 zu warten ergibt in den meisten Fällen keinen Sinn: 6.8 wird für 2027 erwartet, ein Datum nennt Shopware nicht, und der Umbau auf Vue 3, Vite und Pinia steht trotzdem an — dann eben später und zusammen mit den Änderungen von 6.8. Wer heute auf 6.7 geht, hat ihn hinter sich. Es gibt eine Gegenausnahme: Wenn der Shop in absehbarer Zeit ohnehin neu gebaut oder ersetzt wird, ist das Update verschwendetes Geld. Dann ist 6.6 im Extended Support mit einem festen Termin für den Neubau die günstigere Antwort.
Ja, bei Update-Anfragen ist das der Normalfall. Gebraucht werden Shell- oder SFTP-Zugang, Datenbankzugang, ein Administrator-Konto im Backend, das Git-Repository und der Shopware-Account mit den Lizenzen der kostenpflichtigen Store-Erweiterungen. Fehlt das Repository, rekonstruieren wir den Stand vom Server; dieser Aufwand gehört in die Schätzung. Die Lizenzen sind der Punkt, an dem Projekte tatsächlich hängen bleiben: Liegen sie im Account der alten Agentur, lassen sich kostenpflichtige Erweiterungen nicht aktualisieren, und das ist kein technisches, sondern ein organisatorisches Problem.
Nein, ein Update ist ein Projekt mit Anfang und Ende und wird als solches beauftragt. Die Frage nach dem Vertrag stellt sich danach: Wer spielt die monatlichen Minor- und Patch-Stände ein? Wenn wir das übernehmen, läuft es über ein Service Level Agreement mit vier Stufen — BASIC 24 Stunden, STANDARD 8 Stunden, ADVANCED 4 Stunden, PREMIUM 2 Stunden Reaktionszeit, jeweils als Monatspauschale netto je Shop. Ohne Vereinbarung gilt Bearbeitung in Eingangsreihenfolge innerhalb von 48 Stunden zu unseren Geschäftszeiten Mo–Fr 9:00–16:00 Uhr.
Anfrage
Schicken Sie uns Version, Patch-Stand und Plugin-Liste. Sie bekommen eine schriftliche Einschätzung: Zielversion, welche Erweiterungen im Weg stehen, Aufwandsrahmen und ein Wartungsfenster — vor dem Angebot, nicht danach.