Adobe Commerce End of Life am 11. August 2026: Was für Ihre Version wirklich gilt

Der 11. August 2026 steht seit Monaten in Agentur-Newslettern und LinkedIn-Posts als "Adobe Commerce End of Life". Der Termin stimmt, die Zuspitzung nicht. Was an diesem Tag endet, hängt davon ab, welche Version Sie fahren, ob Sie Magento Open Source oder eine Adobe-Commerce-Lizenz nutzen und ob Ihr Shop auf Adobe Commerce on Cloud liegt. Aus einem Datum werden so vier verschiedene Fahrpläne, und in einem Fall liegt die härtere Frist gar nicht 2026, sondern 2027.

Dieser Artikel ist Teil unserer Serie "Magento für Entscheider". Alle Daten stammen aus der Adobe Software Lifecycle Policy in der Fassung vom 5. August 2026 und den zugehörigen Release Notes. Die Quellen sind am Ende verlinkt.

Was am 11. August 2026 tatsächlich endet

Adobe kennt für die 2.4-Linie drei Support-Stufen, und der 11. August 2026 betrifft nur die erste davon.

• Standard-Support läuft drei Jahre ab dem Release-Datum. Enthalten sind Qualitäts-Fixes, kumulative und isolierte Security-Patches sowie Hotfixes für kritische Lücken.

• Extended Support hängt ein Jahr an und liefert weiterhin Qualitäts- und Security-Patches für die Kernanwendung. Adobe stellt das für 2.4.6 und 2.4.7 ohne Aufpreis bereit.

• Security-only-Übergangsphase gibt es einmalig für 2.4.4, 2.4.5 und 2.4.6. Sie liefert isolierte Security-Fixes, keine Qualitäts-Fixes. Adobe beschreibt sie ausdrücklich als Migrationszeit, nicht als Support-Stufe zum Draufbleiben.

Am 11. August 2026 endet der Standard-Support für 2.4.6. Für 2.4.5 fällt einen Tag später, am 12. August 2026, der Extended Support weg. Beide Versionen bekommen danach noch isolierte Security-Fixes, 2.4.5 bis zum 31. Mai 2027, 2.4.6 bis zum 31. Mai 2028.

Die Termine im Überblick

Der Unterschied, der in den meisten Beiträgen fehlt: Open Source oder Lizenz

Extended Support und Security-only-Phase sind an eine Adobe-Commerce-Lizenz gebunden. In den Release Notes zu den 2.4.6-Security-Patches steht das in einem Satz: Die Verlängerung bis zum 30. August 2027 und die anschließende Security-only-Phase bis zum 31. Mai 2028 stehen Adobe-Commerce-Kunden zur Verfügung. Magento Open Source ist nicht gemeint.

Damit trennt sich der 11. August 2026 in zwei sehr unterschiedliche Termine. Wer Magento Open Source 2.4.6 betreibt, erreicht an diesem Tag das echte Ende der Patch-Versorgung durch Adobe. Wer eine Adobe-Commerce-Lizenz hat, hat noch gut ein Jahr regulären Patch-Betrieb vor sich und danach eine Übergangsphase.

Für Open-Source-Betreiber auf 2.4.5 oder älter ist die Lage bereits seit dem 12. August 2025 unverändert: Standard-Support beendet, Extended Support nie verfügbar gewesen. Wer das noch fährt, läuft seit einem Jahr ohne Core-Patches.

Welche Edition Sie haben, steht in der composer.json. Das Paket magento/product-community-edition bedeutet Open Source, magento/product-enterprise-edition bedeutet Adobe Commerce. Die genaue Version liefert bin/magento --version.

Für Open-Source-Shops, die vorerst auf der Plattform bleiben wollen, ist Mage-OS einen Blick wert. Die gemeinnützige Distribution von Magento Open Source veröffentlicht eigene Releases und übernimmt dabei auch Adobes isolierte Security-Patches. Offen bleibt, wie lange eine Community-Distribution eine Codebasis pflegen kann, für die der Hersteller selbst keine Fixes mehr liefert. Als Ersatz für ein Versions-Upgrade würden wir es nicht einplanen, als Zwischenschritt kann es passen.

Adobe Commerce on Cloud: ab 2027 schaltet Adobe ab

Die Lifecycle Policy enthält seit 2026 eine Regel, die in den EOL-Diskussionen bisher kaum vorkommt. Ab dem 1. Juni 2027 betreibt Adobe keine Cloud-Umgebungen mehr, die auf einer nicht unterstützten Commerce-Version laufen. Adobe beschreibt die Konsequenz wörtlich: Der Traffic auf die betroffene Infrastruktur wird ausgesetzt, der Storefront geht offline. Bleibt eine Umgebung danach weiter außerhalb der Vorgaben, kann Adobe die Cloud-Services kündigen und die Umgebung stilllegen.

Für 2.4.4 und 2.4.5 auf Cloud greift diese Frist am 1. Juni 2027, für 2.4.6 und 2.4.7 am 1. Juni 2028. Wer on-premises hostet, ist davon nicht betroffen, trägt dafür aber das Sicherheitsrisiko allein.

Dieselbe Regel gilt auf Cloud auch für die Plattformdienste. Wenn Datenbank, Suchindex, Cache oder Message Broker auf einer Version laufen, die ihrerseits das Support-Ende erreicht hat, kann Adobe den Traffic ebenfalls aussetzen. Die Version des Shops allein reicht als Nachweis also nicht.

Die zweite Uhr: PHP, MySQL und der Rest des Stacks

Adobe liefert keine Fixes für Drittanbieter-Software, die während Ihres Support-Fensters ihr eigenes Lebensende erreicht. Das steht so in der Lifecycle Policy und ist der Punkt, an dem Extended Support seinen praktischen Wert verliert.

Adobe Commerce 2.4.6 ist auf PHP 8.2 und 8.1 validiert. PHP 8.1 hat sein Lebensende bereits hinter sich, für PHP 8.2 endet auch der reine Security-Support am 31. Dezember 2026. Ein Adobe-Commerce-Kunde, der den Extended Support bis August 2027 ausreizt, betreibt seinen Shop in den letzten acht Monaten also auf einer PHP-Version, für die es keine Patches mehr gibt. 2.4.5 ist noch enger: Diese Version läuft ausschließlich auf PHP 8.1.

Bei der Datenbank sieht es ähnlich aus. MySQL 8.0 hat am 30. April 2026 sein Support-Ende erreicht, und Adobe validiert für die 2.4.6-Linie keine neueren MySQL-Hauptversionen mehr. Adobe rät On-Premises-Betreibern auf 2.4.6 deshalb zum Umstieg auf MariaDB, unterstützt ist dort 10.11.

Die aktuellen Zielversionen lösen das: 2.4.8 läuft auf PHP 8.4 und 8.3 sowie MariaDB 11.4 und 11.8, 2.4.9 auf PHP 8.5 und MariaDB 12.3. Ein Versions-Upgrade ist damit fast immer auch ein PHP- und Datenbank-Upgrade. Wer den Aufwand kalkuliert und nur den Magento-Teil einrechnet, landet zu tief.

Was das für PCI DSS bedeutet

Wenn Ihr Shop Teil der Karteninhaber-Umgebung ist, wird aus dem technischen Thema ein Prüfbefund. PCI DSS v4.0.1 verlangt in Anforderung 6.3.3, dass Patches für kritische und hoch eingestufte Lücken innerhalb eines Monats nach Veröffentlichung eingespielt werden. Ohne Hersteller-Patches lässt sich diese Anforderung nicht erfüllen, weil es nichts zum Einspielen gibt.

Anforderung 12.3.4 verlangt zusätzlich eine jährliche Prüfung aller eingesetzten Hardware und Software daraufhin, ob sie noch Herstellerunterstützung hat, samt einem von der Geschäftsleitung freigegebenen Plan zur Ablösung von Technologien, die das Support-Ende erreicht haben. Ein Shop auf einer Version ohne Patches ist genau der Fall, den diese Anforderung adressiert. Bei der nächsten Prüfung brauchen Sie dafür einen Plan mit Terminen, nicht nur die Absicht.

Upgrade oder Systemwechsel: die ehrliche Rechnung

Ein Support-Ende ist ein schlechter Auslöser für ein Replatforming. Ein Versions-Upgrade von 2.4.6 auf 2.4.8 dauert je nach Anpassungsgrad und Extension-Bestand einige Wochen. Ein Wechsel auf ein anderes Shopsystem dauert eher sechs bis zwölf Monate, weil Katalogstruktur, Schnittstellen, Checkout, Suche und SEO-Setup neu entstehen. Wer beides zusammenlegt, trifft eine Plattformentscheidung für die nächsten fünf Jahre unter dem Zeitdruck einer Frist, die schon abgelaufen ist.

Der pragmatische Weg für die meisten Shops führt zuerst auf eine unterstützte Magento-Version und danach in eine unbefristete Systemdiskussion. 2.4.8 ist dabei die konservative Wahl: seit April 2025 im Markt, breite Extension-Abdeckung, Standard-Support bis 31. Mai 2028. 2.4.9 kauft ein weiteres Jahr, verlangt aber PHP 8.5 und ist erst seit Mai 2026 verfügbar, weshalb einzelne Drittanbieter-Module noch keine Freigabe haben. Prüfen Sie das an Ihrem konkreten Modulbestand, nicht an einer allgemeinen Empfehlung.

Ein Systemwechsel ergibt Sinn, wenn die Gründe dafür schon vor dem EOL-Termin auf dem Tisch lagen: Lizenzkosten von Adobe Commerce, die im Verhältnis zum Umsatz nicht mehr passen, fehlende Magento-Kompetenz im Team oder Agenturumfeld, oder ein Shop, der ohnehin funktional neu gebaut werden sollte. Welche Systeme dann in Frage kommen, haben wir im Vergleich von Magento und Shopware gegenübergestellt. Als drittes Ziel nennt Adobe in der Lifecycle Policy selbst den Wechsel auf Adobe Commerce as a Cloud Service, also die SaaS-Variante ohne eigene Versionspflege.

Die nächsten Schritte, in der Reihenfolge, die sich bewährt hat

1. Ausgangslage feststellen. Version, Edition und Hosting-Art bestimmen die Frist, die für Sie gilt. Ohne diese drei Angaben lässt sich der Rest nicht planen.

2. Modulbestand inventarisieren. Jedes Drittanbieter-Modul und jede eigene Erweiterung braucht eine Aussage zur Zielversion. Adobe-Commerce-Kunden können dafür das Upgrade Compatibility Tool nutzen, das Core- und Modulcode gegen eine Zielversion prüft und einen Report mit Fehlern und Warnungen ausgibt. Für Magento Open Source steht dieses Tool nicht zur Verfügung, dort läuft die Prüfung über Composer-Constraints, die Herstellerangaben der Modulanbieter und statische Analyse.

3. Zielversion festlegen und den Plattformpfad mitplanen. PHP- und Datenbankversion gehören in dieselbe Entscheidung, sonst upgraden Sie zweimal. Wie wir solche Projekte aufsetzen, steht auf unserer Seite zur Magento-Migration.

4. Upgrade auf einer Staging-Umgebung durchziehen und die Bereiche testen, die erfahrungsgemäß brechen: Checkout mit allen Zahlarten, Versandregeln, ERP-Schnittstelle, Suche und Indexer, Import- und Exportjobs.

5. Go-live in einer umsatzschwachen Woche, mit Rollback-Pfad und einem Monitoring, das Fehler in den ersten Tagen sichtbar macht statt erst im Umsatzbericht des Folgemonats.

Wenn Sie mit dem Upgrade ohnehin an die Codebasis gehen, lohnt der Blick auf die Punkte, die im laufenden Betrieb Geld kosten: Ladezeiten, Indexer-Laufzeiten und Caching-Verhalten. Was sich dabei erreichen lässt, haben wir in der Magento-2-Performance-Optimierung zusammengetragen.

Was wir Kunden in dieser Lage raten

Prüfen Sie zuerst, welche der sechs Zeilen aus der Tabelle oben Ihre ist. Für Magento Open Source auf 2.4.6 ist der 11. August 2026 der harte Schnitt und ein Upgrade in den nächsten Wochen die richtige Antwort. Für Adobe-Commerce-Lizenznehmer auf 2.4.6 ist es der Startschuss für ein Projekt, das bis Sommer 2027 abgeschlossen sein sollte, wobei das PHP-Support-Ende zum 31. Dezember 2026 die praktisch engere Grenze setzt. Wer auf Cloud liegt, hat mit dem 1. Juni 2027 beziehungsweise 1. Juni 2028 einen Termin im Kalender, an dem der Shop ohne Upgrade offline geht.

In allen drei Fällen gilt dasselbe zur Reihenfolge: erst auf eine unterstützte Version, dann über die Plattform reden. Ein Replatforming unter Fristdruck kostet mehr und liefert schlechtere Entscheidungen als eines, das aus einer stabilen Ausgangslage heraus geplant wird.

Quellen

• Adobe Experience League - Software lifecycle policy (Stand 05.08.2026)

• Adobe Experience League - Release notes for Adobe Commerce 2.4.6 security patches

• Adobe Experience League - System requirements

• Adobe Experience League - Upgrade Compatibility Tool

• php.net - Supported Versions

• Mage-OS - Releases

• PCI Security Standards Council - PCI DSS v4.0.1, Anforderungen 6.3.3 und 12.3.4