Magento 2.4.7: Standard-Support endet am 31. Mai 2027

Für Magento 2.4.7 steht das Datum fest: Am 31. Mai 2027 endet der Standard-Support, also die Phase, in der Adobe Qualitätskorrekturen und Sicherheitspatches für diese Reihe liefert (Lifecycle Policy). Eine kostenlose Verlängerung bis zum 31. Mai 2028 gibt es, Adobe nennt dafür aber ausdrücklich nur Kunden von Adobe Commerce, der lizenzpflichtigen Ausgabe. Wer Magento Open Source betreibt, sollte deshalb den Mai 2027 als maßgeblichen Termin behandeln. Das ist eine Ableitung aus dem Wortlaut und aus dem Vorgehen bei älteren Reihen, keine wörtliche Zusage, und wir begründen sie unten. Der Beitrag ordnet die Fristen ein, zeigt, wie PHP und Datenbank in denselben Zeitraum fallen, und hilft bei der Entscheidung zwischen einem Upgrade auf 2.4.8 oder 2.4.9 und einem Wechsel zu Shopware. Für die Umsetzung steht unsere Magento-Agentur bereit.

Was Adobe für Magento 2.4.7 festgelegt hat

Adobe gewährt jeder Version ein Standard-Supportfenster von drei Jahren ab dem Tag der allgemeinen Verfügbarkeit (Lifecycle Policy). Magento 2.4.7 erschien am 9. April 2024, das Ende des Standard-Supports liegt auf dem 31. Mai 2027 (Lifecycle Policy). In diesem Fenster gibt es Qualitätskorrekturen, Sicherheitspatches und den vollen Support von Adobe (Lifecycle Policy). Die Sicherheitskorrekturen erscheinen als kumulative Patchstände mit dem Zusatz -p, für dringende Fälle kommen einzelne Patchdateien und Hotfixes hinzu.

Für 2.4.7 sind bis heute zehn solcher Patchstände erschienen, von 2.4.7-p1 im Juni 2024 bis 2.4.7-p10 am 12. Mai 2026 (Released Versions). Der vorletzte Stand für 2.4.7 kam am 10. März 2026 (Released Versions). Über die geplanten Termine hinaus kann Adobe weitere Sicherheitspatches veröffentlichen, zugesagt ist das aber ausdrücklich nicht (Patch Release Schedule).

Seit 2.4.7 enden die Standard-Fenster einheitlich am 31. Mai, rund drei Jahre nach dem Erscheinen der Reihe (Lifecycle Policy). Wer heute auf 2.4.7 ist, hat bis zum Ende des Standard-Supports nur noch die Monate bis Ende Mai 2027. Wer auf 2.4.6 ist, hat dieses Ende bereits hinter sich: Der Standard-Support für 2.4.6 lief am 11. August 2026 aus (Released Versions).

Adobe bietet Kunden von Adobe Commerce auf den Versionen 2.4.6 und 2.4.7 ein zusätzliches Supportjahr ohne Mehrkosten an.

Adobe, Adobe Commerce lifecycle policy (eigene Übersetzung)

Was das Ende für Magento Open Source bedeutet

Auf der Lifecycle-Seite kommen die Wörter Magento und Open Source nicht vor. Sie spricht durchgehend von Adobe Commerce, und das zusätzliche Jahr gilt dort ausdrücklich für dessen Kunden (Lifecycle Policy). Deutlicher wird Adobe an anderer Stelle: In den Hinweisen zu den Sicherheitspatches für 2.4.5 steht, dass Sicherheitspatches aus der erweiterten Unterstützung nur Kunden von Adobe Commerce zur Verfügung stehen (Security Patch Notes 2.4.5). Für die Codebasis von Magento Open Source seien sie nicht erhältlich (Security Patch Notes 2.4.5). Zu 2.4.6, deren Verlängerung im August 2026 begonnen hat, schreibt Adobe, diese Regelungen gälten nur für Kunden von Adobe Commerce (Security Patch Notes 2.4.6).

Wie das in der Praxis aussieht, zeigt das öffentliche Repository von Magento Open Source. Dort endet die Reihe der Patch-Tags für 2.4.4 bei 2.4.4-p13 und für 2.4.5 bei 2.4.5-p14 (GitHub magento/magento2). 2.4.4-p13 erschien am 8. April 2025, kurz vor dem Ende des Standard-Supports dieser Reihe am 12. April 2025 (Released Versions). 2.4.5-p14 erschien am 12. August 2025, dem Tag, an dem der Standard-Support für 2.4.5 endete (Released Versions). Für Adobe Commerce liefen beide Reihen danach weiter, bis 2.4.4-p18 und 2.4.5-p17 am 12. Mai 2026 (Released Versions).

Für 2.4.6 ist seit dem Ende des Standard-Supports noch kein weiterer Patchstand erschienen. Der letzte, 2.4.6-p15 vom 12. Mai 2026 (Released Versions), steht auch im öffentlichen Repository als Tag bereit (GitHub magento/magento2). Ob die Reihe sich wie 2.4.4 und 2.4.5 verhält, zeigt sich mit dem nächsten Patchtermin.

PHP, Datenbank und Suchdienst: weitere Fristen

Das Supportende von Magento ist nicht die einzige Frist, die einen 2.4.7-Shop betrifft. Adobe liefert ausdrücklich keine Sicherheits- und Qualitätskorrekturen für Abhängigkeiten wie PHP und MySQL, auch wenn diese während des Supportzeitraums ihr Lebensende erreichen (Lifecycle Policy). Getestet ist 2.4.7-p10 mit PHP 8.2 und 8.3 (System Requirements). Für PHP 8.2 endet die Sicherheitsunterstützung am 31. Dezember 2026, für PHP 8.3 am 31. Dezember 2027 (php.net). Ein Shop, der 2.4.7 noch auf PHP 8.2 betreibt, verliert die Sicherheitskorrekturen für PHP also schon Monate vor dem Ende des Magento-Standard-Supports.

Adobe verknüpft das mit der PCI-Konformität: Für PHP 8.2 nennt die Lifecycle Policy ab Ende 2026 ein Risiko für die PCI-Konformität und rät, Upgrade oder Migration vorher zu planen (Lifecycle Policy). Als betroffene Reihe führt die Tabelle dort nur 2.4.6 auf; der Grund, ein PHP ohne Sicherheitskorrekturen, gilt nach unserer Einschätzung für einen 2.4.7-Shop auf PHP 8.2 ebenso. Ob ein Shop die Vorgaben des Kartenzahlungsstandards erfüllt, muss der Händler selbst bewerten (Lifecycle Policy). Läuft der Shop noch auf PHP 8.2, ist die Umstellung auf PHP 8.3 deshalb der erste Schritt, unabhängig davon, wie die große Entscheidung ausfällt. Den Ablauf eines PHP-Wechsels mit Staging-Test beschreibt unser Beitrag zum Supportende von PHP 8.2 am Beispiel WordPress, das Vorgehen lässt sich auf Magento übertragen.

Bei der Datenbank ist eine Frist schon verstrichen. MySQL 8.0 hat am 30. April 2026 das Ende seines Supports erreicht (System Requirements). 2.4.7 unterstützt keine MySQL-Versionen, die nach MySQL 8.0 erschienen sind (System Requirements). Adobe empfiehlt Betreibern von 2.4.7 auf eigenen Servern deshalb dringend den Umstieg auf eine kompatible MariaDB-Version (System Requirements). Was beim Wechsel der Datenbankversion zu prüfen ist, beschreibt unser Beitrag zum Supportende von MySQL 8.0.

Server-Anforderungen der drei Zielstände

Die Tabelle gibt die getesteten Versionen für den Betrieb auf eigenen Servern wieder (System Requirements). Jedes Upgrade bewegt also auch die Server-Umgebung. 2.4.9 ist nur mit PHP 8.5 und OpenSearch 3 getestet, Elasticsearch und Redis stehen für diese Reihe nicht mehr in der Liste (System Requirements). Adobe unterstützt nur die dort aufgeführten Kombinationen (System Requirements). Shop und Server gehören deshalb in einen gemeinsamen Plan. Läuft Ihr Shop bei unserem Hosting, planen wir beides zusammen.

Weg 1: Upgrade auf Magento 2.4.8

2.4.8 ist seit dem 8. April 2025 verfügbar und erhält Standard-Support bis zum 31. Mai 2028 (Lifecycle Policy). Das ist ein Jahr mehr als bei 2.4.7. Der Sprung ist der kleinste der drei Wege: Die Reihe ist mit PHP 8.3 und 8.4 getestet, also auch mit der PHP-Version, auf die ein 2.4.7-Shop ohnehin wechseln sollte (System Requirements). PHP 8.4 erhält Sicherheitskorrekturen bis zum 31. Dezember 2028 und deckt damit das gesamte Standard-Fenster von 2.4.8 ab (php.net).

Mit 2.4.8 lässt sich auch die Datenbankfrage lösen, denn die Reihe ist mit MySQL 8.4 sowie mit MariaDB 11.4 und 11.8 getestet (System Requirements). Der Nachteil: Wer 2.4.8 wählt, steht im Frühjahr 2028 vor derselben Entscheidung wie heute. Für Shops, deren Erweiterungen noch nicht für die neueste Reihe freigegeben sind, ist 2.4.8 trotzdem oft der vernünftige Zwischenschritt.

• Viele Erweiterungen von Drittanbietern: 2.4.8 ist länger auf dem Markt als 2.4.9, Hersteller hatten mehr Zeit für Freigaben.
• Knappe Zeit bis Mai 2027: Von 2.4.7 auf 2.4.8 ist es nur ein Versionsschritt, Staging-Probe und Livegang lassen sich schneller abschließen.
• Plattformwechsel ohnehin geplant: Wer mittelfristig ein anderes System will, überbrückt mit 2.4.8 die Zeit bis dahin, ohne auf einer Reihe ohne Patches zu sitzen.

Weg 2: Sprung auf Magento 2.4.9

2.4.9 erschien am 12. Mai 2026 und erhält Standard-Support bis zum 31. Mai 2029, also zwei Jahre länger als 2.4.7 (Lifecycle Policy). Getestet ist die Reihe mit PHP 8.5 (System Requirements), dessen Sicherheitsunterstützung bis zum 31. Dezember 2029 reicht (php.net). Wer jetzt ohnehin ein Upgrade-Projekt aufsetzt, gewinnt mit 2.4.9 das längste Fenster.

Der längere Zeitraum hat einen Preis. Von 2.4.7 auf 2.4.9 sind es zwei Versionsschritte, PHP springt von 8.3 über 8.4 auf 8.5, und die Server-Umgebung ändert sich in mehreren Punkten zugleich (System Requirements). Jede Erweiterung, jedes Theme und jedes eigene Modul muss mit der neuen PHP-Version laufen. Bei Shops mit wenigen, gut gepflegten Erweiterungen ist das gut machbar. Bei Shops mit vielen älteren Modulen wird 2.4.9 schnell zu einem Projekt, das im Umfang an einen Wechsel heranreicht.

• Liste aller Erweiterungen mit Version, Hersteller und Freigabe für die Zielversion
• Eigene Module und Theme: Eingriffe in Kernklassen, Plugins und Präferenzen im Dependency-Injection-System
• Anbindungen an Warenwirtschaft, Zahlungsanbieter und Versand, siehe unsere Schnittstellen
• Server-Umgebung: PHP, Datenbank, OpenSearch, Cache und Message Queue gegen die Systemanforderungen
• Staging-Umgebung mit aktuellem Datenbestand, aber ohne echte Zahlungen und ohne Mails an Kunden
• Rückweg: geprüfte Sicherung von Code und Datenbank vor dem Livegang

Wer eine Warenwirtschaft angebunden hat, prüft die Anbindung bei jedem Versionssprung mit. Wie das konkret aussieht, zeigt unser Beitrag JTL-Wawi 2.x: Shop-Anbindung vor dem Versionssprung prüfen, die Prüfschritte lassen sich auf andere Systeme übertragen.

Weg 3: Wechsel zu Shopware

Ein Upgrade erhält den bestehenden Shop, ein Wechsel ersetzt ihn. Er lohnt sich vor allem dann, wenn ein Upgrade auf 2.4.9 ohnehin viele Module neu verlangt, wenn das Team den Betrieb von Magento als aufwendig erlebt oder wenn die nächste Grundsatzentscheidung nicht erst 2029 fallen soll. Shopware 6.7 steht unter der MIT-Lizenz (GitHub shopware/shopware) und lässt PHP 8.2 bis 8.5 zu (GitHub shopware/shopware). Die nächste Hauptversion 6.8 ist für 2027 geplant (Shopware-Ankündigung). Ein Wechsel, der 2027 live geht, sollte diesen Termin von Anfang an mitdenken.

Den Datenumzug deckt der Migrationsweg von Shopware zu großen Teilen ab: Kategorien, Kunden mit Adressen, Bestellungen, Produkte mit Varianten, Eigenschaften, Bilder, Bewertungen und Lagerbestand lassen sich übernehmen (Shopware-Doku Magento-Migration). Bestellstatus, Zahlungsarten und Steuersätze werden dabei über eine Vorab-Zuordnung von Hand zugewiesen (Shopware-Doku Magento-Migration). Seiten und Blöcke aus dem CMS von Magento fehlen in dieser Liste, und im Abschnitt zu den Medien hält die Dokumentation fest, dass sich Daten aus dem CMS nicht migrieren lassen (Shopware-Doku Magento-Migration). Inhaltsseiten, Landingpages und Blöcke werden in Shopware deshalb neu aufgebaut.

Der größere Aufwand steckt selten in den Daten, sondern in Funktionen: Was in Magento über Erweiterungen oder eigene Module läuft, wird in Shopware über vorhandene Funktionen, Erweiterungen oder eigene Entwicklung abgebildet. B2B-Funktionen wie Kundenkonten mit Freigaben oder kundenindividuelle Preise entwickeln wir dabei passend zum Bedarf. Weiterleitungen für alle bisherigen Adressen gehören in jeden Wechsel, damit Suchmaschinen und Besucher die neuen Seiten finden. Den allgemeinen Ablauf beschreibt unser Leitfaden zur Migration von Magento zu Shopware 6, die Leistungen dazu finden Sie unter Shopware-Migration.

Auch der Alltag im Backend ändert sich mit dem System, und das Team braucht dafür Einarbeitung. Wie etwa Telefon- und Mailbestellungen im Shopware-Admin erfasst werden, gehört deshalb in die Planung eines Wechsels, nicht erst in die Woche nach dem Livegang.

Upgrade oder Wechsel: die Entscheidung

Welcher Weg passt, hängt weniger vom Kalender ab als vom Zustand des Shops. Die Gegenüberstellung fasst zusammen, worin sich die drei Wege unterscheiden.

Als Faustregel gilt: Lässt sich der Shop in einer Staging-Umgebung mit vertretbarem Aufwand auf 2.4.8 heben, ist das der kürzere Weg bis Mai 2027. Zeigt schon die Bestandsaufnahme, dass mehrere zentrale Module neu entwickelt werden müssten, gehört der Wechsel ernsthaft auf den Tisch.

Zeitplan bis Ende Mai 2027

Bis Ende Mai 2027 bleibt weniger Zeit, als es scheint, denn Weihnachtsgeschäft, Jahreswechsel und Inventur fallen mitten hinein. Ein realistischer Ablauf für ein Upgrade sieht so aus:

1. November 2026: Bestandsaufnahme von Erweiterungen, eigenem Code, Schnittstellen und Server-Umgebung; Umstellung von PHP 8.2 auf 8.3, falls noch nicht geschehen.
2. Dezember 2026: Entscheidung zwischen 2.4.8, 2.4.9 und Wechsel, gestützt auf eine erste Upgrade-Probe in der Staging-Umgebung. Bis zum 31. Dezember 2026 sollte PHP 8.2 abgelöst sein (php.net).
3. Januar bis März 2027: Erweiterungen aktualisieren oder ersetzen, eigene Module anpassen, Datenbank und Suchdienst umstellen.
4. April 2027: Abnahme in der Staging-Umgebung mit Testbestellungen über alle Zahlungs- und Versandarten und einem Lasttest.
5. Mai 2027: Livegang mit Puffer vor dem 31. Mai, danach Beobachtung von Fehlerprotokollen und Bestellungen.

Bis zur Umstellung: den 2.4.7-Shop absichern

Wie ernst Lücken in Magento werden können, zeigt CVE-2025-54236. Die Lücke war ohne Anmeldung ausnutzbar, erhielt den CVSS-Basiswert 9,1 und erlaubte Angreifern, Sitzungen zu übernehmen (NVD). Im Oktober 2025 nahm die US-Cybersicherheitsbehörde CISA sie für Adobe Commerce und Magento in ihren Katalog bekannter ausgenutzter Schwachstellen auf (NVD). Für 2.4.7 ist sie mit dem Patchstand 2.4.7-p8 behoben, einen Hotfix hatte Adobe bereits im September 2025 veröffentlicht (Security Patch Notes 2.4.7). Schon für CVE-2024-34102 hatte Adobe gemeldet, dass Angriffe auf Händler bekannt sind, wenn auch in sehr begrenztem Umfang (Security Patch Notes 2.4.7).

• Neuesten Patchstand einspielen: Für 2.4.7 ist das derzeit 2.4.7-p10 (Released Versions). Isolierte Sicherheitspatches lassen sich nur auf den jeweils neuesten -p-Stand einer Reihe anwenden (Patch Release Schedule).
• Hotfixes nicht als Ersatz sehen: Ein Hotfix wie der vom September 2025 schließt eine einzelne Lücke. Er behebt aber nicht alle Probleme, die ein Upgrade auf den neuesten Stand löst (Lifecycle Policy).
• PHP 8.3 statt 8.2: Damit fällt das Jahresende 2026 als Frist für PHP weg (php.net).
• Datenbank auf MariaDB: MySQL 8.0 hat sein Supportende hinter sich, für 2.4.7 empfiehlt Adobe eine kompatible MariaDB-Version (System Requirements).
• Zugänge eingrenzen: Admin-Bereich nur über feste Adressen oder mit zusätzlichem Anmeldefaktor erreichbar machen, ungenutzte Integrationen und Zugangsschlüssel entfernen.
• Überwachung einrichten: Fehlerprotokolle, Änderungen an Dateien und auffällige Bestellungen beobachten, damit ein Angriff früh auffällt.

Für Händler hat das auch eine rechtliche Seite. Nach Art. 32 DSGVO treffen Verantwortliche unter Berücksichtigung des Stands der Technik geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten (DSGVO). Ob ein Shop dem genügt, ist im Einzelfall zu bewerten. Eine Software, für die der Hersteller keine Sicherheitskorrekturen mehr veröffentlicht, macht diese Begründung jedenfalls nicht leichter.

So begleiten wir Upgrade oder Wechsel

Wir betreuen Magento-Shops und bauen Shops mit Shopware. Deshalb bewerten wir beide Wege nebeneinander, ohne das Ergebnis vorwegzunehmen. Am Anfang steht eine Bestandsaufnahme mit Upgrade-Probe, danach entscheiden Sie auf Grundlage einer Aufwandsschätzung für jeden Weg.

Wenn Sie nicht sicher sind, welcher Weg zu Ihrem Shop passt, klären wir das in einem Erstgespräch.