Shopware 6.8 für 2027 angekündigt: Upgrade jetzt vorbereiten

Shopware hat im November 2025 angekündigt, die nächste Hauptversion 6.8 für 2027 statt für 2026 zu planen (Shopware). Für Betreiber eines Community-Edition-Shops mit eigenen Plugins klingt das nach Aufschub, ist aber vor allem ein Zeitfenster: Die Brüche, die 6.8 mitbringt, sind zu einem guten Teil schon angekündigt, als veraltet markiert und in einem Entwurf der Upgrade-Anleitung beschrieben. Wer die Zeit bis zur Hauptversion nutzt, verteilt die Arbeit auf viele kleine Schritte, statt sie in wenige Wochen vor dem Upgrade zu drängen. Dieser Beitrag ordnet die Supportfenster von 6.6 und 6.7 ein, zeigt, was das Ende der Symfony-Konfiguration in XML für eigene Plugins bedeutet, wie die geschärfte Kennzeichnung von Deprecations die Bestandsaufnahme erleichtert und in welcher Reihenfolge sich das Upgrade vorbereiten lässt – ohne Termine zu nennen, die Shopware selbst noch nicht veröffentlicht hat.

Was Shopware für 6.8 angekündigt hat

Die Ankündigung ist knapp: Shopware hat den Veröffentlichungsplan angepasst, die nächste Hauptversion 6.8 ist nun für 2027 geplant statt für 2026 (Shopware, Update on the Shopware roadmap). Ein Quartal oder einen Monat nennt die Meldung nicht, und ein genaueres Datum hat Shopware bisher auch an anderer Stelle nicht veröffentlicht. Alles, was über das Jahr hinausgeht, wäre deshalb eine Schätzung. Für die Planung eines Shops ist die Jahresangabe trotzdem eine brauchbare Größe: Zwischen heute und dem Erscheinen der Hauptversion liegt ein Zeitraum, in dem sich Plugins, Konfiguration und Laufzeitumgebung schrittweise vorbereiten lassen, ohne dass der laufende Betrieb darunter leidet. Entscheidend ist, diesen Zeitraum als Arbeitszeit zu verstehen und nicht als Wartezeit.

Mit derselben Meldung hat Shopware den Extended Support für 6.6 verlängert: Laut Shopware bleibt er aktiv, bis 6.8 verfügbar ist (Shopware). Das ist eine Kopplung an ein Ereignis, kein Kalenderdatum. Genau darin liegt die wichtigste Änderung gegenüber früheren Aussagen: Supportübergänge sind laut Release Policy an Hauptversionen gebunden, nicht an feste Zeiträume (Shopware Release Policy). Wer mit einem festen Enddatum für 6.6 plant, plant also mit einer Zahl, die es in dieser Form nicht gibt. Verlässlich ist nur die Reihenfolge: Erst erscheint 6.8, dann ändert sich der Status der älteren Reihen. Für die Budgetplanung ist das unbequem, für die technische Vorbereitung aber hilfreich, weil sich der Blick von Daten auf Voraussetzungen verschiebt.

We’ve adjusted our release schedule: the next major Shopware version, 6.8, is now planned for 2027 instead of 2026.

Shopware, Update on the Shopware roadmap (November 2025)

Wann genau die Hauptversion kommt, lässt sich über eine andere Regel wenigstens eingrenzen, sobald es so weit ist: Zu jeder Hauptversion erscheint ein Release Candidate, in der Regel etwa zwei Monate vor der geplanten Hauptversion (Shopware Release Policy). Die Release Policy schränkt das selbst ein: Je nach Rückmeldung der Community kann sich die RC-Phase verlängern (Shopware Release Policy). Der Release Candidate ist deshalb das erste belastbare Signal für die heiße Phase, aber kein Termin, an dem sich ein Livegang festmachen lässt. Für die Vorbereitung folgt daraus eine einfache Regel: Die Arbeit, die ohne Release Candidate möglich ist, sollte vorher erledigt sein, damit die RC-Phase für Tests bleibt und nicht für Umbauten gebraucht wird.

Supportfenster: woran das Ende von 6.6 und 6.7 hängt

Die Release Policy beschreibt den Übergang in einem Satz: Die letzte Minor-Version einer Hauptversion geht in den Extended Support, sobald die nächste Hauptversion erscheint (Shopware Release Policy). Für die Reihe 6.7 bedeutet das: Solange 6.8 nicht erschienen ist, bleibt 6.7 die laufende Reihe mit regulären Minor-Versionen. Erst mit 6.8 wechselt die letzte 6.7-Minor in den Extended Support. Eine eigene Dauer für diesen Abschnitt nennt Shopware für 6.7 nicht, und die Release Policy weist ausdrücklich darauf hin, dass die Übergänge an Hauptversionen hängen und nicht an feste Zeiträume (Shopware Release Policy). Wer eine Budgetplanung aufsetzt, rechnet deshalb sinnvoller mit Ereignissen als mit Monaten: mit dem Erscheinen des Release Candidate, mit dem Erscheinen von 6.8 und mit dem eigenen Upgrade-Fenster danach.

Wie der Übergang in der Praxis aussieht, zeigt die vorige Runde: Mit der stabilen Version 6.7.0.0 endete der Extended Support für die Reihe 6.5 (Shopware-Release-Notes 6.7.0.0). Die Reihe 6.6 wird dagegen weiter gepflegt; 6.6.10.25 vom 16.9.2026 ist laut Release Notes ein Sicherheitsrelease (Shopware-Release-Notes 6.6.10.25). Das Muster ist klar: Der Status einer Reihe ändert sich mit dem Erscheinen der nächsten Hauptversion, nicht an einem Stichtag. Ein Shop auf 6.6 ist bis zum Erscheinen von 6.8 also nicht abgehängt. Er läuft aber auf einer Reihe, deren verlängerter Extended Support laut Shopware nur reicht, bis 6.8 verfügbar ist. Was danach für 6.6 gilt, hat Shopware nicht beziffert, und die frühere Zusage fester Zeiträume ist überholt. Was das für Shops bedeutet, die heute noch auf 6.5 laufen, beschreibt der Beitrag Shopware 6.5 und das Ende der Sicherheitsupdates.

Für selbst gehostete Installationen erscheinen Minor-Versionen monatlich (Shopware Release Policy). Das ist für die Vorbereitung auf 6.8 wichtiger, als es klingt: Jede Minor-Version der Reihe 6.7 kann neue Deprecations mitbringen, die auf 6.8 zielen. Ein Shop, der auf einer frühen 6.7-Minor stehen bleibt, sieht diese Hinweise nicht und erfährt erst beim Sprung, was sich angesammelt hat. Regelmäßige Updates innerhalb der Reihe sind deshalb kein Selbstzweck, sondern die Voraussetzung dafür, dass die Bestandsaufnahme vollständig ist. Wie sich Updates im laufenden Betrieb mit geringem Risiko für den Umsatz einspielen lassen, beschreibt der Beitrag Shopware-Updates sicher einspielen.

• Für 6.6 gibt es laut Shopware kein Enddatum, sondern eine Bedingung: Der Extended Support läuft, bis 6.8 verfügbar ist.
• Für 6.7 gilt die allgemeine Regel der Release Policy: Die letzte Minor-Version geht mit dem Erscheinen von 6.8 in den Extended Support.
• Feste Supportdauern aus früheren Ankündigungen sind überholt; die heutige Release Policy bindet die Übergänge an Hauptversionen.
• Wer noch auf 6.6 steht, legt den Wechsel auf 6.7 sinnvollerweise nicht mit dem Sprung auf 6.8 zusammen, sondern schließt ihn vorher ab – die Brüche zwischen 6.6 und 6.7 beschreibt der Beitrag zur Plugin-Migration auf Shopware 6.7.
• Die monatlichen Minor-Versionen der Reihe 6.7 sind der Kanal, über den neue Hinweise auf 6.8 ankommen.

Symfony-Konfiguration in XML läuft mit 6.8 aus

Seit 6.7.14.0 ist das Laden von Symfony-Konfiguration aus XML-Dateien als veraltet markiert – für Shopware-Bundles, für Plugins und für das Projektverzeichnis config/ einer Installation. Laut den Release Notes funktioniert diese Konfiguration mit Shopware 6.8 nicht mehr, weil Symfony 8 die Unterstützung für XML-Konfiguration vollständig entfernt (Shopware-Release-Notes 6.7.14.0). Betroffen sind damit genau die Dateien, mit denen viele Plugins ihre Dienste und Routen beschreiben: Service-Definitionen, Routen und Paketkonfiguration. Wer eigene Plugins betreibt, die über Jahre gewachsen sind, findet solche Dateien häufig in jedem einzelnen Plugin, oft aus einer Vorlage übernommen und seitdem unverändert. Der Umbau ist pro Datei überschaubar, in der Summe über alle Plugins aber ein Posten, der in die Planung gehört.

Wie hart der Bruch ausfällt, beschreibt der Entwurf der Upgrade-Anleitung zu 6.8 (Stand September 2026): Plugins, die solche Dateien noch mitbringen, werden nicht mehr korrekt geladen und brechen mit einer Exception ab (GitHub shopware/shopware, UPGRADE-6.8.md). Für XML-Dateien im Projektverzeichnis config/ ist die Folge leiser, aber nicht harmloser: Sie werden laut demselben Entwurf stillschweigend nicht mehr geladen. Weil es sich um einen Entwurf für eine noch nicht veröffentlichte Version handelt, kann sich der Wortlaut bis 6.8 ändern. Die Richtung ist jedoch in den Release Notes und im Entwurf gleichlautend beschrieben, und für die Planung zählt die Richtung mehr als die genaue Formulierung.

• Betroffen: Service-Definitionen wie Resources/config/services.xml und weitere Dateien nach dem Muster services*.xml.
• Betroffen: Routen in routes*.xml, etwa für eigene Controller in der Storefront oder in der Administration.
• Betroffen: Paketkonfiguration unter packages/*/.xml.
• Betroffen: XML-Konfigurationsdateien im Projektverzeichnis config/ der Installation – sie werden laut Entwurf stillschweigend übergangen.
• Nicht betroffen laut Entwurf: Shopware-eigene XML-Formate wie config.xml, custom-fields.xml und App-Manifeste.

Deprecations ernst nehmen: was sich mit 6.7.14.0 geändert hat

Mit 6.7.14.0 hat Shopware auch die Bedeutung einer Kennzeichnung geschärft. Laut den Release Notes ist eine @deprecated-Annotation im Core-Code nun durchgehend eine tatsächliche Deprecation: Die Funktion wird entfernt oder ersetzt, und die Migration ist so vorzunehmen, wie die Annotation es beschreibt (Shopware-Release-Notes 6.7.14.0). Für geplante Änderungen an Schnittstellen führt Shopware eigene BC-Change-Attribute ein, sodass sich angekündigte Brüche und echte Deprecations besser auseinanderhalten lassen. Dieselbe Minor-Version schließt nach Angabe der Release Notes 522 Issues (Shopware-Release-Notes 6.7.14.0) – ein Hinweis darauf, wie viel sich innerhalb einer Reihe bewegt, auch ohne Hauptversion.

Dass die Kennzeichnung Folgen hat, zeigt die letzte Hauptversion: Mit 6.6.0.0 im März 2024 wurde der gesamte für 6.6 als veraltet markierte Code entfernt (Shopware-Release-Notes 6.6.0.0). Eine Deprecation ist damit keine Stilfrage, sondern eine Ankündigung mit Fälligkeit. Wer sie bis zum Upgrade auf die Hauptversion ignoriert, bekommt alle Unverträglichkeiten auf einmal – im ungünstigsten Moment, nämlich dann, wenn das Upgrade ohnehin viel Aufmerksamkeit bindet. Wer sie dagegen mit jeder Minor-Version abarbeitet, verteilt denselben Aufwand auf viele kleine, gut testbare Schritte. Der Unterschied liegt nicht in der Menge der Arbeit, sondern darin, ob sie planbar anfällt oder gebündelt unter Zeitdruck.

Für die Einordnung der Treffer hilft eine einfache Unterscheidung. Aufrufe, die ein eigenes Plugin gegen veralteten Core-Code richtet, lassen sich in der Regel im Plugin selbst beheben. Deprecations in Erweiterungen aus dem Shopware Store liegen beim jeweiligen Hersteller; dort ist die Frage, ob und wann eine 6.8-kompatible Fassung geplant ist. Und Deprecations in selbst geschriebenen Anpassungen, die tief in Core-Abläufe eingreifen, sind ein Hinweis darauf, dass sich die Anpassung vielleicht mit Bordmitteln oder in einer anderen Erweiterungsform lösen lässt. Ob dafür eine App oder ein Plugin die passende Form ist, hängt davon ab, wie tief die Anpassung in Core-Abläufe eingreifen muss und wo sie betrieben werden soll.

PHP und Symfony: zwei Zeitpläne neben Shopware

Mit dem Umstieg auf Symfony 7 wurde PHP 8.2 in Shopware 6.6 zur Mindestversion (Shopware-Release-Notes 6.6.0.0). Getestet wurde 6.6.0.0 auf PHP 8.2 und 8.3, 6.7.0.0 auf PHP 8.2 und 8.4 und 6.7.14.0 auf PHP 8.2, 8.4 und 8.5 (Shopware-Release-Notes). Getestet heißt dabei nicht dasselbe wie unterstützt: Die composer.json von 6.7.14.2 lässt PHP 8.2, 8.3, 8.4 und 8.5 zu (GitHub shopware/shopware), und dieselbe Spanne steht in der composer.json von 6.6.10.25 (GitHub shopware/shopware). Für den Betrieb ist eine getestete Kombination die sicherere Wahl; die zulässige Spanne zeigt dagegen, was sich technisch installieren lässt.

Auf Seiten von Symfony bindet Shopware 6.7.14.2 das FrameworkBundle an die Reihe 7.4 (GitHub shopware/shopware). Symfony 7.4 erhält laut symfony.com Sicherheitskorrekturen bis November 2029 (symfony.com). Die Reihe 6.7 steht damit auf einer Symfony-Version mit langem Sicherheitsfenster. Mit 6.8 kommt Symfony 8 ins Spiel – das folgt aus der Begründung, die Shopware für das Ende der XML-Konfiguration gibt (Shopware-Release-Notes 6.7.14.0). Welche Symfony-8-Version 6.8 voraussetzt, hat Shopware noch nicht veröffentlicht. Zum Vergleich: Symfony 8.1 setzt PHP 8.4.0 oder höher voraus (symfony.com). Daraus eine PHP-Mindestversion für 6.8 abzuleiten, wäre eine Folgerung, kein Beleg. Wer seine Plugins schon jetzt auf PHP 8.4 oder 8.5 testet, hält sich die Optionen offen und erfährt früh, ob ein Plugin Sprachfunktionen nutzt, die in neueren PHP-Versionen als veraltet gelten.

Unabhängig von Shopware läuft der Zeitplan von PHP. Jeder PHP-Zweig erhält nach zwei Jahren aktivem Support zwei weitere Jahre nur Korrekturen kritischer Sicherheitslücken (php.net). Für PHP 8.2 endet die Versorgung mit Sicherheitskorrekturen am 31.12.2026, der aktive Support lief bereits am 31.12.2024 aus (php.net). Das liegt vor dem für 2027 geplanten Shopware 6.8. Ein Shop, der heute auf 6.6 oder 6.7 mit PHP 8.2 läuft, braucht den PHP-Wechsel also unabhängig vom Shopware-Upgrade. Was dieser Stichtag für andere Systeme bedeutet, zeigt der Beitrag darüber, was das Supportende von PHP 8.2 für WordPress bedeutet.

Aus der Tabelle folgt eine Reihenfolge, die sich in der Praxis bewährt: den PHP-Wechsel getrennt vom Shopware-Upgrade planen und vorziehen. Wer beides in einem Schritt erledigt, kann bei einem Fehler nicht mehr sagen, ob die neue Shopware-Version oder die neue PHP-Version die Ursache ist. Ein Shop auf 6.7 kann heute auf eine PHP-Version wechseln, die Shopware in den Release Notes als getestet führt, und dort stabil laufen, bevor 6.8 überhaupt verfügbar ist. PHP 8.4 erhält laut php.net Sicherheitskorrekturen bis zum 31.12.2028, PHP 8.5 bis zum 31.12.2029 (php.net) – beide Zweige reichen damit über das Jahr hinaus, für das 6.8 angekündigt ist. Welchen davon 6.8 voraussetzt, bleibt offen, bis Shopware es veröffentlicht.

Bestandsaufnahme: die Kompatibilitätsampel je Plugin

Die Vorbereitung beginnt mit einer Liste aller Erweiterungen, die im Shop aktiv sind oder aktiv werden sollen: eigene Plugins, gekaufte Erweiterungen, Themes und Anpassungen im Projektverzeichnis. Jeder Eintrag landet in einer von drei Spalten. Grün heißt bereit: keine Symfony-Konfiguration in XML, keine offenen Deprecation-Treffer, PHP-Anforderungen im Rahmen. Gelb heißt anpassen: Das Plugin bleibt, braucht aber Umbauten vor dem Upgrade. Rot heißt ersetzen: Das Plugin wird nicht mehr gepflegt, der Hersteller hat keinen Plan für 6.8 genannt, oder die Funktion lässt sich heute mit Bordmitteln einfacher lösen. Das Titelbild dieses Beitrags zeigt ein solches Board als Beispiel mit Platzhalternamen.

Die Suche nach Dateinamen ist ein Anfang, keine Diagnose. Sie findet Service-Definitionen und Routen, die nach den üblichen Mustern benannt sind; Dateien mit abweichenden Namen oder Konfiguration, die über eigene Loader eingebunden wird, erfasst sie nicht. Umgekehrt ist nicht jede XML-Datei ein Problem: config.xml für die Plugin-Einstellungen, custom-fields.xml und App-Manifeste sind laut dem Entwurf der Upgrade-Anleitung nicht betroffen (GitHub shopware/shopware, UPGRADE-6.8.md). Wer config.xml als Ausschlusskriterium wertet, sortiert gesunde Plugins fälschlich in die gelbe Spalte. Für eine belastbare Einordnung gehört zu jedem Treffer ein Blick in die Plugin-Basisklasse und in die Stellen, an denen Konfiguration geladen wird.

# Kompatibilitätsampel je Plugin - Arbeitsstand, Namen sind Platzhalter
EigenesPluginB:
  herkunft: Eigenentwicklung
  symfony_xml: keine            # keine services*.xml, routes*.xml, packages/*.xml
  shopware_xml: [config.xml]    # laut Entwurf der Upgrade-Anleitung nicht betroffen
  deprecations: keine offenen Treffer
  ampel: grün

SchnittstelleE:
  herkunft: Eigenentwicklung
  symfony_xml: [Resources/config/services.xml, Resources/config/routes.xml]
  deprecations: Treffer im Log, siehe Arbeitsliste
  ampel: gelb
  aufgabe: Service-Definitionen und Routen vor dem Upgrade umstellen

GekaufteErweiterungG:
  herkunft: Shopware Store
  symfony_xml: unbekannt
  plan_des_herstellers: nicht angekündigt
  ampel: rot
  aufgabe: Hersteller anfragen, Ersatz oder Eigenbau bewerten

Das Inventar lebt vom Abgleich mit dem Hersteller und mit dem Testsystem. Für gekaufte Erweiterungen ist die wichtigste Zeile die Frage, ob eine 6.8-Fassung angekündigt ist; bei eigenen Plugins die Frage, wer den Code kennt und ihn anpassen kann. Plugins, die einmal für einen Sonderfall entstanden sind und deren Entwickler das Projekt verlassen hat, landen erfahrungsgemäß häufiger in der roten Spalte, als es die Technik allein rechtfertigt. Für die gelbe Spalte ist der Aufwand in der Regel gut planbar: Service-Definitionen und Routen umstellen, Deprecation-Treffer abarbeiten, Tests ergänzen. Wo ein Plugin ohnehin neu geschrieben werden muss, lohnt sich die Frage, ob sich seine Aufgabe heute mit Bordmitteln oder als schlankere Erweiterung sauberer lösen lässt.

• Symfony-Konfiguration in XML gefunden (services.xml, routes.xml, packages/*/.xml)? Dann gelb.
• Nur config.xml, custom-fields.xml oder ein App-Manifest? Laut Entwurf nicht betroffen und damit kein Grund für Gelb.
• Treffer im Deprecation-Log auf der jüngsten 6.7-Minor? Dann gelb, mit Eintrag in der Arbeitsliste.
• PHP-Anforderung des Plugins schließt 8.4 oder 8.5 aus? Dann gelb, bis die Anforderung erweitert und getestet ist.
• Hersteller ohne angekündigte 6.8-Fassung oder Code ohne Zuständigen? Dann rot, Ersatz prüfen.
• Keiner der Punkte trifft zu? Grün – aber erst nach einem Durchlauf auf dem Testsystem.

Zeitplan: vom Inventar bis zum Release Candidate

Weil Shopware für 6.8 nur das Jahr 2027 nennt, lässt sich der Zeitplan nicht rückwärts von einem Datum rechnen. Er lässt sich aber vorwärts in Phasen gliedern, deren Reihenfolge feststeht. Die ersten Phasen hängen nicht an der Hauptversion und können sofort beginnen; die letzten setzen den Release Candidate voraus. Wer die Phasen außerhalb der umsatzstarken Wochen plant, vermeidet den Konflikt mit Aktionszeiträumen – wie sich Lastspitzen etwa am Black Friday abfangen lassen, behandelt der Beitrag zum Warteraum für Lastspitzen im Shop. Das Upgrade selbst gehört in ein ruhiges Fenster mit Rückfallplan.

1. Inventar anlegen: alle Plugins, Themes und Projektkonfigurationen mit Ampel, Herkunft und Zuständigem erfassen.
2. Auf die jüngste 6.7-Minor aktualisieren und das Deprecation-Log auswerten; Ignoriermuster für Shopware-Deprecations entfernen.
3. Symfony-Konfiguration in XML umstellen, Plugin für Plugin, jeweils mit eigenem Test und eigener Auslieferung.
4. PHP-Wechsel getrennt planen: Plugins auf einer in den Release Notes als getestet geführten PHP-Version prüfen und umstellen, bevor 6.8 erscheint.
5. Gekaufte Erweiterungen klären: Hersteller anfragen, Antworten dokumentieren, Ersatz für rote Einträge vorbereiten.
6. Testsystem mit realistischen, aber anonymisierten Daten aufbauen – wie das gelingt, zeigt der Beitrag zu Staging-Testdaten ohne Kundendaten.
7. Release Candidate testen, sobald er verfügbar ist, und Befunde an Shopware zurückmelden.
8. Upgrade auf 6.8 nach der stabilen Veröffentlichung in einem ruhigen Fenster mit Rückfallplan durchführen.

Die Phase mit dem Release Candidate ist die kürzeste und die am wenigsten planbare. Er erscheint laut Release Policy in der Regel etwa zwei Monate vor der geplanten Hauptversion, und die RC-Phase kann sich je nach Rückmeldung der Community verlängern (Shopware Release Policy). In diesen Wochen sollte nur noch getestet werden, was vorher umgebaut wurde. Wer erst mit dem Release Candidate anfängt, XML-Konfiguration umzustellen und Deprecations abzuarbeiten, verschiebt den eigenen Livegang fast zwangsläufig. Umgekehrt ist ein Shop, dessen Inventar vor dem Release Candidate nur noch grüne und erledigte gelbe Einträge enthält, in einer komfortablen Lage: Er kann die RC-Phase nutzen, um Überraschungen zu finden, statt bekannte Baustellen zu schließen.

Wie XICTRON die Vorbereitung auf 6.8 begleitet

XICTRON begleitet Community-Edition-Shops durch Hauptversionswechsel – von der Bestandsaufnahme über den Umbau eigener Plugins bis zum Upgrade im ruhigen Fenster. Im Rahmen der Shopware-Migration erstellen wir das Inventar mit Ampel, stellen Symfony-Konfiguration in XML um und arbeiten Deprecation-Treffer als Arbeitsliste ab, jeweils auf einer Testumgebung und mit eigener Abnahme je Plugin. Wer den Shop dauerhaft auf einer aktuellen Minor-Version halten will, findet in der Shopware-Wartung den laufenden Rahmen dafür: Updates über eine Testumgebung, Sicherheitspatches, Backups und Monitoring – und damit auch die regelmäßige Auswertung neuer Hinweise auf 6.8.

Die Laufzeitumgebung gehört zur Vorbereitung dazu. Beim Shopware-Hosting ist die PHP-Version Teil der Serverkonfiguration; ein PHP-Wechsel lässt sich dort als eigener Schritt planen und vorher auf einer Kopie des Shops durchspielen, bevor er live geht. Ein Upgrade ist zudem ein guter Anlass, den Ausgangsstand festzuhalten: Der Shop-Check für Tempo, SEO und Barrierefreiheit liefert eine Momentaufnahme, gegen die sich der Shop nach dem Upgrade vergleichen lässt. So wird sichtbar, ob die neue Version an einer Stelle langsamer oder schlechter zugänglich geworden ist.

Die Verschiebung von 6.8 auf 2027 nimmt den Druck aus dem Kalender, aber nicht aus dem Code. Die Symfony-Konfiguration in XML ist als veraltet markiert, Deprecations sind klarer gekennzeichnet als früher, und PHP 8.2 verliert seine Sicherheitskorrekturen, bevor 6.8 erscheint. Wer diese drei Punkte jetzt in eine Arbeitsliste übersetzt, kann das Upgrade planen, statt darauf reagieren zu müssen. Für ein erstes Gespräch über Inventar, Ampel und Zeitplan genügt eine kurze Anfrage zur Upgrade-Planung für Shopware 6.8.