Magento-2.4.x-Update-Checkliste: vor, während und nach dem Update

Ein sicheres Magento-2.4.x-Update hat drei Phasen. Vorher: prüfen, welche Release-Linie noch unterstützt wird, die PHP-, OpenSearch- und Datenbankversionen bestätigen, die das Ziel-Release braucht, und jede Extension sowie jedes eigene Modul dagegen abgleichen. Währenddessen: Update auf einer Staging-Kopie mit Produktivdaten, danach Regressionstests für den Checkout und jede Schnittstelle. Danach: Release in einem geplanten Zeitfenster mit getestetem Rollback, danach in den ersten Tagen Fehler, Bestellungen und Performance im Blick behalten. Im Folgenden finden Sie die Checkliste, die wir bei jedem Update abarbeiten, geschrieben für Shopbetreiber und für Agenturen, die Updates an uns vergeben.

Die Versionen und Daten unten wurden im November 2026 mit der offiziellen Dokumentation von Adobe abgeglichen. Adobe aktualisiert diese Seiten regelmäßig, prüfen Sie sie bei Ihrer Planung also erneut.

Vor dem Update

1. Wissen, wo Ihre Version steht

Adobe gewährt jeder 2.4.x-Release-Linie ab ihrem Veröffentlichungsdatum drei Jahre Standard-Support mit Qualitätsfixes und Sicherheitspatches. Einige ältere Linien erhalten zusätzliche Zeit. Releases von Magento Open Source folgen denselben 2.4.x-Release-Linien und demselben Patch-Zeitplan wie Adobe Commerce; die Lifecycle-Daten veröffentlicht Adobe für Adobe Commerce.

Was das in der Praxis bedeutet:

• Auf 2.4.4 oder 2.4.5: Sie erhalten nur noch einzelne Sicherheitsfixes, keine Qualitätsfixes, und dieser Zeitraum wird nicht verlängert. Planen Sie jetzt ein Minor-Update.
• Auf 2.4.6: Der Standard-Support ist beendet. Sie haben noch Zeit, aber nicht viel.
• Auf 2.4.7 oder 2.4.8: Spielen Sie jeden Sicherheitspatch ein (die -pN-Releases) und planen Sie das nächste Minor-Update in Ruhe.
• Auf Adobe Commerce Cloud: Ab dem 1. Juni 2027 stellt Adobe die Wartung von Cloud-Umgebungen ein, auf denen nicht unterstützte Versionen laufen.

Prüfen Sie außerdem, ob Sie auf dem neuesten Patch Ihrer Linie sind. Die einzelnen Sicherheitspatch-Dateien von Adobe lassen sich nur darauf einspielen, ein Shop mit mehreren Patches Rückstand kann einen Notfall-Fix also nicht schnell übernehmen.

Die 2.4.10-Linie befindet sich zum Zeitpunkt des Schreibens im Alpha-Stadium. Planen Sie kein Produktiv-Update auf ein Alpha- oder Beta-Release.

2. Plattformanforderungen prüfen

Ein Großteil des Update-Risikos liegt außerhalb von Magento selbst: PHP, die Suchmaschine, die Datenbank und der Cache. Die Systemanforderungen von Adobe für den neuesten Patch jeder Linie (self-hosted):

Punkte, über die Teams oft stolpern:

• PHP-Sprünge. Der Schritt von 2.4.6 auf 2.4.9 bedeutet einen Wechsel von PHP 8.1/8.2 auf 8.5. Jedes eigene Modul und jede Extension muss auf der neuen PHP-Version laufen, nicht nur der Magento-Core. PHP 8.2 selbst erhält nur noch bis zum 31. Dezember 2026 Sicherheitsfixes.
• Suchmaschine. Der Support für Elasticsearch 7.17 endete am 15. Januar 2026, und 2.4.9 führt nur noch OpenSearch 3. Wenn Sie noch Elasticsearch nutzen, gehört die Migration der Suche zum Projekt. Planen Sie Budget für die Neuindexierung und für die Prüfung jeder Such-Extension gegen OpenSearch ein.
• Datenbank. Der Support für MySQL 8.0 endete am 30. April 2026. Prüfen Sie, welche MySQL- oder MariaDB-Versionen Ihr Ziel-Release unterstützt, bevor Sie den Code anfassen.
• Cache. Aktuelle Patches führen Valkey statt Redis. Ihr Hosting oder Ihr Cloud-Setup muss die Version bieten, die das Ziel-Release erwartet.
• Commerce Cloud hat eine eigene Anforderungstabelle, die von der für self-hosted abweicht. Nutzen Sie die Cloud-Werte, wenn Sie auf Cloud sind.

3. Eine Kompatibilitätsmatrix für Extensions erstellen

Listen Sie jedes Drittanbieter-Modul in composer.json und app/code auf und füllen Sie dann eine Zeile pro Extension aus:

• installierte Version und Hersteller;
• die Version, die Ihr Magento-Ziel-Release und Ihre PHP-Version unterstützt (laut Changelog des Herstellers, nicht nur laut Marketplace-Badge);
• Lizenz- oder Supportstatus, da manche Updates eine kostenpflichtige Verlängerung erfordern;
• ob das Modul überhaupt noch genutzt wird.

Markieren Sie jede Zeile mit aktualisieren, ersetzen, selbst patchen oder entfernen. Nicht mehr gepflegte Module sind ein häufiger Grund, warum Update-Schätzungen wachsen. Module zu entfernen, die niemand nutzt, ist oft der günstigste Fix.

4. Eigenen Code und veraltete APIs prüfen

• Core-Änderungen. Suchen Sie nach Änderungen in vendor/, überschriebenen Core-Klassen und Composer-Patches. Jede davon muss gegen das neue Release erneut geprüft werden.
• Plugins und Preferences auf Core-Klassen brechen, wenn sich Methodensignaturen ändern.
• Abwärtsinkompatible Änderungen. Adobe veröffentlicht pro Release eine Liste. So wechselt 2.4.9 zum Beispiel auf Symfony 7.4 LTS; eigene Klassen, die Symfony-Core-Klassen erweitern, brauchen daher aktualisierte Typdeklarationen und Methodensignaturen. Außerdem lehnt 2.4.9 über die API angelegte Bestellungen ohne Rechnungsadresse ab, was relevant ist, wenn ein ERP- oder Marktplatz-Connector Bestellungen anlegt.
• Auf Adobe Commerce lassen Sie das Upgrade Compatibility Tool von Adobe gegen die Zielversion laufen. Es meldet kritische Probleme, Fehler und Warnungen in Ihren Modulen und im Core-Code. Für Magento Open Source ist es nicht verfügbar. Dort erfolgt dieselbe Prüfung von Hand und mit statischer Analyse.

5. Staging und Backups vorbereiten

• Eine Staging-Umgebung, die der Produktivumgebung entspricht: dieselben PHP-, Suchmaschinen-, Datenbank- und Cache-Versionen wie im Ziel, nicht wie heute.
• Eine aktuelle Kopie der Produktivdaten, anonymisiert, falls die Staging-Umgebung weniger geschützt ist als die Produktivumgebung.
• Backups, die Sie mindestens einmal wiederhergestellt haben: Datenbank-Dump, media/, app/etc/env.php und der deployte Code (oder das Release-Artefakt). Ein Backup, das Sie nie wiederhergestellt haben, ist eine Hoffnung, kein Backup.
• Ein Code Freeze oder zumindest eine klare Branch-Strategie, damit Features, die während des Updates entwickelt werden, nicht damit kollidieren.

Während des Updates

6. Update in kleinen, überprüfbaren Schritten

1. Aktualisieren Sie zuerst die Infrastruktur auf Staging: PHP, Suchmaschine, Datenbank und Cache.
2. Aktualisieren Sie Magento und die Extensions über Composer, jeweils eine Gruppe nach der anderen, und committen Sie nach jedem Schritt.
3. Führen Sie setup:upgrade aus, kompilieren Sie die DI, deployen Sie den Static Content und beheben Sie jeden Fehler und jede Deprecation-Warnung. Unterdrücken Sie sie nicht.
4. Spielen Sie Composer-Patches erneut ein oder entfernen Sie sie; manche werden nach einem Update überflüssig.
5. Bauen Sie die Frontend-Assets neu und prüfen Sie das Theme, besonders wenn es Core-Templates überschreibt.

7. Regressionstests für alles, was Umsatz bringt

Automatisierte Tests helfen, aber ein schriftlicher Testplan, der die echten Geschäftsprozesse abdeckt, ist das Minimum:

• Checkout: als Gast und eingeloggt, jede Zahlungsart (inklusive 3-D Secure und Wallets), jede Versandart, Gutscheine, Geschenkkarten, Steuern und Währung je Store View.
• Kundenkonto: Registrierung, Login, Passwort zurücksetzen, Bestellhistorie, erneut bestellen.
• Katalog und Suche: Kategorieseiten, Layered Navigation, Suchergebnisse und Autocomplete nach der Neuindexierung, konfigurierbare Produkte und Bundle-Produkte, Preise je Kundengruppe.
• Schnittstellen: ERP- und Bestandssynchronisation, Bestellexport, Zahlungs- und Versand-Webhooks, Marktplatz-Feeds, E-Mail- und Marketing-Tools, Analytics- und Tag-Manager-Events. Testen Sie beide Richtungen, mit echten (Sandbox-)Zugangsdaten.
• Admin und Betrieb: Bestellanlage und Rechnungsstellung, Gutschriften, Importe, Cronjobs, Queue-Consumer und Transaktions-E-Mails.
• B2B-Funktionen auf Adobe Commerce: Firmenkonten, Shared Catalogs, Angebote (Quotes), Bestelllisten (Requisition Lists).

Führen Sie auch einen kurzen Performance-Check durch: Trefferquote des Full-Page-Cache, Server-Antwortzeit auf den wichtigsten Seiten und Core Web Vitals der geänderten Templates.

8. Release-Fenster und Rollback planen

• Wählen Sie ein verkehrsarmes Zeitfenster abseits von Kampagnen, Sales und anderen saisonalen Spitzen.
• Schreiben Sie das Release-Runbook: Schritte, wer was macht, erwartete Dauer und den Entscheidungspunkt für den Rollback.
• Legen Sie Rollback-Kriterien vor dem Release fest (zum Beispiel: Checkout defekt, Zahlungsfehler, Schnittstellenfehler, die Sie im Zeitfenster nicht beheben können).
• Halten Sie das vorherige Release und ein frisches Datenbank-Backup bereit und wissen Sie, wie lange eine Wiederherstellung dauert. Sobald nach dem Datenbank-Update neue Bestellungen eingehen, bedeutet ein Rollback der Datenbank, dass diese verloren gehen; das Zeitfenster für einen Rollback ist also kurz.
• Versetzen Sie den Shop nur für die Schritte in den Wartungsmodus, die ihn erfordern, und informieren Sie Support und Marketing vorab über den Zeitplan.

Nach dem Update

9. Die ersten Tage genau überwachen

• Fehler: PHP- und Exception-Logs, fehlgeschlagene Cronjobs, hängende Queue-Consumer.
• Bestellungen: Vergleichen Sie Bestellvolumen und Quote fehlgeschlagener Zahlungen mit einer normalen Woche. Ein stiller Rückgang ist oft das erste Anzeichen für ein Zahlungs- oder Checkout-Problem.
• Schnittstellen: Stellen Sie sicher, dass Bestellungen im ERP ankommen, Bestände zurückfließen und Webhooks erfolgreich sind.
• Suche und Indexierung: Indexer gültig, Suchergebnisse plausibel, kein wachsender Reindex-Rückstau.
• Performance: Antwortzeiten, Cache-Trefferquote und Core Web Vitals im Vergleich zu vor dem Update.

10. Den Kreis schließen

• Entfernen Sie die ersetzten Module und Patches und räumen Sie alte Deployment-Artefakte auf.
• Aktualisieren Sie die Dokumentation: Versionen, Extension-Matrix, Runbook.
• Tragen Sie den nächsten Sicherheitspatch in den Kalender ein. Wer auf dem neuesten Patch seiner Linie bleibt, hält das nächste Minor-Update klein.

Patch-Update, Minor-Update oder Upgrade älterer Versionen: was Sie erwartet

• Patch-Update (zum Beispiel von 2.4.8-p4 auf 2.4.8-p5): kleiner Umfang, vor allem Tests. Das sollte Routine sein.
• Minor-Update (zum Beispiel von 2.4.7 auf 2.4.8 oder 2.4.9): neue PHP- und Service-Versionen, Extension-Updates und Anpassungen am eigenen Code. Das ist ein Projekt, keine Aufgabe für zwischendurch.
• Upgrade von 2.3 oder älter: Rechnen Sie mit größerem Aufwand, denn dazwischen liegen mehrere PHP-Versionen und viele veraltete Komponenten.

Wenn Sie auch darüber nachdenken, Luma zu ersetzen, lesen Sie zuerst Wann lohnt sich Hyvä?. Eine Hyvä-Migration lässt sich mit einem Minor-Update kombinieren; auf einer nicht unterstützten Version kommt das Update zuerst.

Unterstützung bei Ihrem Update

Wenn Sie vor dem Start eine zweite Meinung möchten, bieten wir ein kostenloses Express-Audit an: Versionen, Patch-Stand, Performance und Basis-Sicherheit, mit Kurzbericht und 20-Minuten-Call. Für das Update selbst beginnen unsere Update-Pakete zum Festpreis bei 300 € für ein Patch-Update und bei 1.000 € für ein Minor-Update innerhalb von 2.4.x inklusive PHP-Update. Der Endpreis wird nach dem Audit festgelegt. Damit Ihr Shop danach gepatcht bleibt, gibt es unsere Magento-Supportverträge.

Quellen (auf Englisch): Adobe Experience League: Lifecycle-Richtlinie, Systemanforderungen, Veröffentlichte Versionen, Release-Zeitplan, Release Notes zu Magento Open Source 2.4.9, Upgrade Compatibility Tool; Adobe Developer: Abwärtsinkompatible Änderungen; Unterstützte PHP-Versionen.