Shopware 6.8: Ausblick auf Roadmap, Änderungen und Vorbereitung
Shopware 6.8 ist für 2027 geplant. Wir trennen bestätigte Roadmap, technische Vorbereitungen und offene Vorschläge und zeigen, was Händler jetzt tun sollten.
Shopware 6.8 wird das nächste Major Release nach Shopware 6.7. Ursprünglich für 2026 erwartet, hat Shopware die Veröffentlichung offiziell auf 2027 verschoben. Ein konkretes Datum und ein finaler Funktionsumfang sind Stand 17. August 2026 noch nicht veröffentlicht.
Trotzdem ist 6.8 bereits relevant. Der öffentlich gepflegte Upgrade-Guide zeigt erste technische Änderungen, einzelne Erweiterungen haben ein bestätigtes Supportende und die 6.7-Reihe enthält Migrationspfade, Feature Flags und Deprecations für den nächsten Major-Schritt.
Ein seriöser Ausblick muss dabei drei Kategorien auseinanderhalten:
- Offiziell bestätigt: Terminrahmen und strategische Schwerpunkte.
- Technisch vorbereitet: Änderungen im laufenden
UPGRADE-6.8.md, die sich bis zum Release noch verändern können. - Offen diskutiert: RFCs und Entwürfe, die keine Release-Zusage sind.
Was Shopware offiziell zu 6.8 bestätigt hat
Offiziell bestätigt sind drei Dinge: Shopware hat 6.8 am 12. November 2025 von 2026 auf 2027 verschoben, nennt als Schwerpunkte Stabilität, Dokumentation und Agentic AI, und verlängert den Extended Support für Shopware 6.6 bis zur Verfügbarkeit von 6.8. Als Grund für die Verschiebung nennt das Unternehmen die Balance aus Fortschritt, Robustheit, Stabilität und Developer Experience.
Für den verlängerten Entwicklungszeitraum nennt Shopware drei Schwerpunkte:
- Stabilität, Performance und Sicherheit der Plattform,
- bessere Dokumentation und Developer Experience,
- Weiterentwicklung von Agentic-AI-Funktionen.
Außerdem wird der Extended Support für Shopware 6.6 bis zur Verfügbarkeit von 6.8 verlängert. Händler auf 6.6 erhalten dadurch mehr Zeit, sollten Extended Support aber nicht mit der aktiven Feature-Entwicklung von 6.7 verwechseln.
Warum die Verschiebung sinnvoll sein kann
Ein Major Release erlaubt Breaking Changes — und jede solche Änderung erzeugt Aufwand bei Plugin-Herstellern, Agenturen und Händlern. Der längere Zyklus verschafft allen Beteiligten Zeit: für Stabilisierung, Plugin-Migrationen, länger sichtbare Deprecations und die planvolle Ablösung von B2B Suite und Sprachpaket. Shopware hat zudem gezeigt, dass neue Commerce-Funktionen auch in Minor-Releases der 6.7-Linie ausgeliefert werden können.
Der längere Zyklus bietet Chancen:
- 6.7 kann weiter stabilisiert und funktional ausgebaut werden.
- Erweiterungshersteller erhalten mehr Zeit für Migrationen.
- Deprecations können vor der Entfernung länger sichtbar gemacht werden.
- Händler können B2B Suite, Sprachpaket und individuelle Altlasten planvoll ablösen.
- Größere Architekturänderungen können mit Feature Flags und Tests vorbereitet werden.
Die Kehrseite: Ein längerer Vorlauf ist kein Grund, bis 2027 nichts zu tun. Wer alle Anpassungen erst beim Release beginnt, verschenkt den gewonnenen Zeitraum.
Was ein Major Release voraussichtlich verändern wird
Major Releases sind bei Shopware traditionell der Zeitpunkt, an dem veraltete APIs, Services, Konfigurationsoptionen und Kompatibilitätsschichten entfernt werden. Neue sichtbare Features können parallel erscheinen, der wichtigste Effekt ist jedoch häufig eine bereinigte technische Basis.
Der aktuelle Upgrade-Guide auf dem Shopware-Trunk ist deshalb wertvoll. Er ist aber ein lebendes Entwicklerdokument und noch kein finaler Releasevertrag. Die folgenden Punkte beschreiben den Stand im August 2026.
Technisch vorbereitet: Deprecations werden entfernt
Shopware markiert APIs und Konfigurationen in 6.7 als deprecated, bevor sie in 6.8 entfernt werden. Betroffen sind unter anderem alte Cache-Optionen, Administration-Blöcke, Services, Events und API-Verhalten.
Für Standardshops ist vieles unsichtbar. Eigene Plugins oder tiefgreifende Integrationen können diese Schnittstellen jedoch direkt verwenden. Deshalb sollten Deprecation Logs und der Upgrade-Guide nicht erst nach dem 6.8-Release gelesen werden.
Axios 1 wird zum Standard der Administration
Shopware 6.7 unterstützt Axios 1 bereits parallel zum älteren Client. Eigene
Administrationserweiterungen können Anfragen testweise mit useAxiosV1: true
ausführen. Für 6.8 sieht der
aktuelle Guide
Axios 1 als Standard vor.
Relevant sind unter anderem Änderungen bei Request Cancellation, Fehlercodes und einzelnen Defaults. Plugin-Entwickler sollten ihre HTTP-Aufrufe bereits unter 6.7 mit dem neuen Client testen und nicht auf einen Kompatibilitätsmodus in 6.8 vertrauen.
Webhooks erhalten einen eigenen Messenger Transport
Der aktuelle
6.8-Guide
beschreibt einen eigenen webhook-Transport. Betreiber,
die Messenger Receiver oder shopware.admin_worker.transports individuell
konfigurieren, müssen diesen Transport berücksichtigen. Andernfalls könnten
Webhooks nach dem Update nicht verarbeitet werden.
Das ist ein gutes Beispiel für eine kleine Konfigurationsänderung mit großer Betriebswirkung. Standardkonfigurationen können automatisch passen, maßgeschneiderte Worker-Setups brauchen einen expliziten Review.
Das Cache-Rework wird konsequent fortgeführt
Shopware 6.7 entfernte die frühere Store-API-Caching-Schicht und bereitete ein neues HTTP-Caching-Modell vor. Im aktuellen 6.8-Guide werden alte, wirkungslose Konfigurationsoptionen entfernt und ausgewählte Store-API-GET-Routen in den normalen HTTP Cache integriert.
Für Betreiber bedeutet das: Cache-Konfigurationen nicht blind übernehmen, sondern Reverse Proxy, Cache Keys, Invalidierung und Response Header unter 6.7 bereits dokumentieren und messen.
Agentic Commerce wird aus dem Core entkoppelt
Der experimentelle Agentic-Commerce-Sales-Channel wurde in der 6.7-Reihe im
Core erprobt. Der aktuelle
6.8-Upgrade-Guide
weist darauf hin, vor dem Update die
Erweiterung SwagAgenticCommerce zu installieren, um konfigurierte Sales
Channels und die Funktion zu erhalten.
Das spricht für eine modularere Weiterentwicklung außerhalb des Core. Händler, die den experimentellen Channel einsetzen, sollten Daten, Feed-URLs, Konfigurationen und Tracking vor der Migration dokumentieren.
B2B Suite endet, B2B Components werden zum Zielmodell
Shopware bestätigt in der Dokumentation, dass die bisherige B2B Suite ab 6.8 nicht mehr unterstützt wird. Neue B2B-Funktionen entstehen bereits heute in den B2B Components.
Betroffene Händler sollten nicht nur die Erweiterung austauschen. Zu prüfen sind Organisationen, Mitarbeiter, Rollen, Budgets, Freigaben, Angebote, Bestelllisten, kundenspezifische Sortimente und individuelle Preise. Eine produktive B2B-Migration ist ein eigenes Fachprojekt.
Das bisherige Sprachpaket wird nicht mehr unterstützt
Seit 6.7.3 kann Shopware verfügbare Übersetzungen nativ aus dem Core verwalten. Die Sprachpaket-Erweiterung wird laut Dokumentation ab 6.8 nicht mehr unterstützt.
Vor dem Wechsel sollten installierte Sprachen, eigene Snippets, Plugin- Übersetzungen und Deployment-Prozesse geprüft werden. Die Core-Migration ersetzt keine redaktionelle Übersetzungsstrategie.
Storefront und Developer Experience
Bereits 6.7.11 führte Shopware Twig UX Components, einen Vite-basierten Storefront Dev Server, CSS Custom Properties aus Theme-Einstellungen und ein globales JavaScript-Event-System ein. Diese Bausteine zeigen die Richtung: wiederverwendbare Komponenten und modernere Entwicklungsabläufe.
Welche dieser Grundlagen in 6.8 verpflichtend werden oder bestehende Mechanismen ersetzen, ist noch nicht final bestätigt. Neue Themes und Komponenten sollten die aktuellen 6.7-Ansätze dennoch berücksichtigen, um unnötige neue Altlast zu vermeiden.
Agentic AI bleibt strategischer Schwerpunkt
Shopware nennt Agentic AI ausdrücklich als Fokus bis 6.8. Die 6.7-Reihe enthält bereits Agentic-Commerce-Feeds, AI Discovery Files, Copilot-Blueprints und einen experimentellen MCP Server.
Das bedeutet nicht, dass alle künftigen AI-Funktionen Bestandteil von 6.8 oder der Community Edition werden. Shopware kann Funktionen über Minor-Releases, Commercial Extensions oder Dienste veröffentlichen. Sicher ist die strategische Richtung, nicht jedes einzelne Produktdetail.
Offen diskutiert: ein entity-basierter Warenkorb
In einer öffentlichen Shopware-RFC wird ein Wechsel vom session-basierten zu einem entity-basierten Warenkorbsystem mit Zielversion 6.8 diskutiert. Genannte Ziele sind mehrere Warenkörbe je Kunde, bessere Performance und eine einfachere Architektur.
Der Status lautet jedoch Draft. Daraus darf keine feste Feature-Zusage abgeleitet werden. Für Händler ist die RFC dennoch interessant, weil sie zeigt, welche grundlegenden Commerce-Modelle Shopware untersucht.
Was Händler jetzt konkret vorbereiten sollten
Sieben Vorbereitungen zahlen sich unabhängig vom finalen Releasedatum aus: Shopware 6.7 aktuell halten, das Erweiterungsinventar dokumentieren, Eigenentwicklungen auf Deprecations prüfen, B2B Suite und Sprachpaket migrieren, die Infrastruktur dokumentieren, automatisierte Kerntests aufbauen sowie Budget und Releasefenster reservieren. Jede davon reduziert das spätere Major-Update-Risiko — auch wenn sich der 6.8-Umfang noch ändert.
1. Shopware 6.7 aktuell halten
Ein gepflegter 6.7-Stand macht Deprecations, Migrationspfade und neue Kompatibilitätsoptionen früh sichtbar. Der Sprung von einer alten 6.6- oder ungepflegten 6.7-Version direkt auf 6.8 würde mehr Variablen gleichzeitig verändern. Was das Update auf Shopware 6.7 bringt und wie es sauber abläuft, haben wir separat beschrieben.
2. Erweiterungsinventar erstellen
Für jedes Plugin, jede App und jedes Theme sollten Hersteller, Version, Geschäftskritikalität, Update-Status und Ersatzoption dokumentiert sein. Besondere Aufmerksamkeit verdienen Erweiterungen ohne aktive Pflege.
3. Eigenentwicklungen auf Deprecations prüfen
Statische Analyse, Tests und Logs sollten veraltete APIs, Administration- Overrides, Axios-Aufrufe, Cache-Konfigurationen und Event Subscriber sichtbar machen. Jede bereits unter 6.7 entfernbare Deprecation reduziert das spätere Major-Update-Risiko.
4. B2B Suite und Sprachpaket migrieren
Diese beiden Supportenden sind offiziell dokumentiert. Wer betroffen ist, sollte Analyse und Migration lange vor dem 6.8-Go-live abschließen.
5. Infrastruktur dokumentieren
Erfasst werden sollten PHP, Datenbank, Redis, OpenSearch, Queue Worker, Cron, Reverse Proxy, Node Toolchain, Deployment und Observability. Finale Systemanforderungen für 6.8 sind noch abzuwarten, aber undokumentierte Sonderkonfigurationen sind schon heute ein Risiko.
6. Automatisierte Kerntests aufbauen
Mindestens Login, Suche, Warenkorb, Checkout, Payment, Bestellübertragung, Kundenkonto und zentrale API-Flows sollten reproduzierbar testbar sein. Ohne Regressionstests wird jede spätere Release-Candidate-Phase zum manuellen Großprojekt.
7. Budget und Releasefenster reservieren
Major Updates benötigen Analyse, Anpassung, Test, Deployment und Nachkontrolle. Ein Platzhalter in Roadmap und Budget verhindert, dass 6.8 später als ungeplante Wartung behandelt wird. Am einfachsten ist das in einem laufenden Wartungs-Retainer verankert, der Major-Updates von vornherein einplant.
Was Händler noch nicht tun sollten
Genauso wichtig wie die Vorbereitung ist die Abgrenzung: Aus „2027“ lässt sich kein Go-live-Datum ableiten, eine RFC ist keine bestätigte Funktion, und der heutige Trunk-Guide ist kein Releasevertrag. Wer Architektur- oder Budgetentscheidungen ausschließlich auf unbestätigte 6.8-Details stützt, baut auf Sand. Konkret heißt das:
- Kein finales Go-live-Datum aus „2027“ ableiten.
- Keine RFC als bestätigte Funktion verkaufen.
- Keine produktive Architektur ausschließlich auf den heutigen Trunk-Guide ausrichten.
- Nicht jede neue 6.7-Funktion aufschieben, nur weil 6.8 geplant ist.
- Nicht bis zum ersten Release Candidate warten, um B2B Suite oder Sprachpaket zu analysieren.
Ein realistischer interner Zeitplan
Der interne Zeitplan gliedert sich in drei Phasen: Aufräumarbeiten von heute bis zur offiziellen Preview, produktionsnahe Tests in der Release-Candidate-Phase und ein kontrollierter, nicht überstürzter Rollout nach dem finalen Release. Wer die erste Phase ernst nimmt, macht die beiden folgenden zu Routineaufgaben statt zu Krisenprojekten.
Jetzt bis zur offiziellen Preview
- 6.7 aktualisieren und stabilisieren
- Erweiterungen und Eigenentwicklungen inventarisieren
- Deprecations beseitigen
- bestätigte Migrationen starten
- automatisierte Tests erweitern
Mit Release Candidates
- produktionsnahe Stage aktualisieren
- finale Systemanforderungen prüfen
- Plugins und Themes mit freigegebenen Versionen testen
- Performance und zentrale Geschäftsprozesse vergleichen
- Rollback und Wartungsfenster planen
Nach dem finalen Release
- nicht automatisch am ersten Tag produktiv aktualisieren
- erste Patch-Releases und Herstellerfreigaben bewerten
- eigenen Risikograd und benötigte neue Funktionen abwägen
- überwachten Rollout mit Nachkontrolle durchführen
Lohnt es sich, auf 6.8 zu warten?
Für die meisten aktiven Shops lautet die Antwort: nein. Shopware 6.7 erhält weiter Funktionen, Performance- und Sicherheitsverbesserungen, während 6.8 zwar für 2027 geplant ist, aber weder ein festes Datum noch einen finalen Funktionsumfang hat. Eine gepflegte 6.7-Basis ist zugleich die beste Vorbereitung auf 6.8 — Warten bringt dagegen keinen Vorteil.
Wer jetzt auf einer älteren Version bleibt, verzichtet möglicherweise lange auf Verbesserungen und vergrößert den späteren Migrationsschritt.
Fazit: 6.8 beginnt mit Aufräumen unter 6.7
Der belastbare Shopware-6.8-Ausblick besteht derzeit weniger aus einer fertigen Featureliste als aus einer klaren Richtung: Veröffentlichung 2027, mehr Fokus auf Stabilität, Performance, Sicherheit, Developer Experience und Agentic AI.
Technische Vorbereitungen sind bereits sichtbar. Axios 1, Webhook Transport, Cache-Bereinigung, ausgelagerter Agentic Commerce sowie das Ende von B2B Suite und Sprachpaket geben Teams konkrete Arbeitspakete.
Der beste Zeitpunkt für die Vorbereitung ist deshalb nicht der Release-Tag. Wer heute 6.7 pflegt, Deprecations entfernt, Tests automatisiert und bestätigte Migrationen abschließt, macht aus 6.8 ein planbares Update statt eines Notfallprojekts.
Offizielle Quellen
Reden wir über dein System.
Kein Pitch-Deck. Ein Gespräch mit denen, die auch bauen.