Magento Roadmap und End-of-Life-Planung

1. Warum Roadmap- und EOL-Planung strategische Aufgabe ist

Die Magento Roadmap und die damit verbundene End-of-Life-Planung werden in vielen Unternehmen als rein technisches Detail behandelt, das bei Bedarf vom Entwicklerteam erledigt wird. Diese Sichtweise unterschätzt die tatsächliche Tragweite: Ein Shop, der über den offiziellen End-of-Life-Termin hinaus ohne Sicherheitspatches betrieben wird, ist einem messbar höheren Risiko für erfolgreiche Angriffe ausgesetzt, und im Schadensfall trägt das Unternehmen die volle Verantwortung, unabhängig davon, ob die Entscheidung technisch oder budgetär begründet war.

Eine vorausschauende Magento Roadmap-Planung verwandelt ein technisches Risiko in eine planbare Budgetposition. Statt eines überraschenden Notfall-Upgrades unter Zeitdruck, wenn der End-of-Life-Termin bereits erreicht ist, lässt sich ein Upgrade-Projekt Monate im Voraus terminieren, budgetieren und mit ausreichend Testzeit durchführen. Die folgenden Abschnitte zeigen, wie Magentos Versionierungszyklus funktioniert, wie sich EOL-Termine zuverlässig ermitteln lassen und welche Upgrade-Strategie zu welchem Shop passt.

2. Magentos Versionierungszyklus verstehen

Magento folgt seit Version 2.4 einem etablierten Muster aus regelmäßigen Minor-Releases (2.4.x) und darin eingebetteten Quartals-Patches. Jede Minor-Version erhält für einen definierten Zeitraum aktive Unterstützung mit neuen Features und Bugfixes, gefolgt von einer Phase, in der nur noch sicherheitskritische Patches veröffentlicht werden, bevor die Version schließlich den End-of-Life-Status erreicht und keinerlei offizielle Updates mehr erhält. Dieser Zyklus ist bewusst vorhersehbar gestaltet, damit Projektverantwortliche langfristig planen können, statt von Ankündigungen überrascht zu werden.

Ein wichtiger Unterschied in der Magento Roadmap betrifft Adobe Commerce und Magento Open Source: Beide Editionen teilen sich denselben Versionszyklus und dieselben End-of-Life-Termine, da sie auf derselben Codebasis aufbauen. Ein Unterschied besteht jedoch bei erweiterten Support-Optionen, die Adobe in Ausnahmefällen gegen zusätzliche Kosten für Adobe Commerce-Kunden anbietet, etwa verlängerte Security-Patches für eine bereits offiziell ausgelaufene Version. Für Magento Open Source existiert eine solche kostenpflichtige Verlängerung nicht, was die Planungssicherheit für diese Edition umso wichtiger macht.

# Aktuell installierte Magento-Version und Edition ermitteln
bin/magento --version
composer show magento/product-community-edition 2>/dev/null
composer show magento/product-enterprise-edition 2>/dev/null

# PHP-Kompatibilitaet der aktuellen Version pruefen
composer show magento/framework | grep -A2 "requires (dep)"

3. Den End-of-Life-Termin einer Version ermitteln

Der zuverlässigste Weg, den End-of-Life-Termin einer konkreten Magento-Version zu ermitteln, führt über die offizielle Adobe-Commerce-Dokumentation, in der ein Software-Lifecycle-Kalender mit allen Minor-Versionen und deren Support-Phasen veröffentlicht wird. Dieser Kalender listet für jede Version drei relevante Daten: den Release-Termin, das Ende der aktiven Feature-Unterstützung und das endgültige End-of-Life-Datum, ab dem keine Security-Patches mehr erscheinen. Wer sich ausschließlich auf Community-Blogposts oder veraltete Foreneinträge verlässt, riskiert, mit falschen oder überholten Terminen zu planen.

Ein häufiger Fehler bei der Magento Roadmap-Planung ist, nur den Termin der eigenen aktuell installierten Version zu prüfen, ohne die Termine der nächsten ein bis zwei Versionen im Blick zu behalten. Da ein Upgrade-Projekt selbst mehrere Monate Vorlaufzeit benötigt, sollte die Planung immer mindestens eine Version voraus denken: Wenn die aktuelle Version in zwölf Monaten den End-of-Life-Status erreicht, muss das Upgrade-Projekt spätestens sechs bis neun Monate vorher starten, um ausreichend Zeit für Entwicklung, Testing und Staging-Validierung zu haben.

{
  "magento_roadmap_tracking": {
    "aktuelle_version": "2.4.7",
    "eol_aktuelle_version": "2026-12-31",
    "naechste_version": "2.4.8",
    "eol_naechste_version": "2027-09-30",
    "upgrade_projekt_start_spaetestens": "2026-06-30",
    "puffer_monate": 6,
    "letzte_pruefung": "2026-07-31"
  }
}

4. Quality Patches, Security Patches und Feature-Releases

Innerhalb der Magento Roadmap ist es wichtig, drei Arten von Updates klar zu unterscheiden, weil sie unterschiedliche Dringlichkeit haben. Quality Patches beheben funktionale Fehler ohne Sicherheitsrelevanz und können in der Regel im normalen Release-Rhythmus eingespielt werden. Security Patches schließen konkrete Sicherheitslücken und sollten mit hoher Priorität und kurzer Reaktionszeit deployt werden, unabhängig vom regulären Wartungsfenster, da veröffentlichte Sicherheitslücken aktiv von Angreifern ausgenutzt werden, sobald der Patch öffentlich ist.

Feature-Releases, also neue Minor-Versionen wie der Sprung von 2.4.7 auf 2.4.8, bringen zusätzlich zu Bugfixes auch neue Funktionalität und potenziell Breaking Changes für Custom-Module mit. Diese Releases erfordern deutlich mehr Testaufwand als reine Patches und sollten nie ungeplant, sondern immer als eigenständiges kleines Projekt mit Staging-Test und Rollback-Plan behandelt werden. Die Magento Roadmap ernst zu nehmen bedeutet konkret, Security Patches sofort, Quality Patches im Wartungsfenster und Feature-Releases als geplantes Projekt zu behandeln, statt alle drei Kategorien gleich zu priorisieren.

5. Upgrade-Strategie: Rolling Upgrades vs. Big-Bang

Bei der eigentlichen Umsetzung eines Upgrades im Rahmen der Magento Roadmap stehen zwei grundsätzliche Strategien zur Wahl. Rolling Upgrades bewegen den Shop schrittweise über jede Zwischenversion, etwa von 2.4.5 über 2.4.6 zu 2.4.7, mit jeweils eigenem Testzyklus. Dieser Ansatz hält jeden einzelnen Schritt überschaubar und reduziert das Risiko unvorhersehbarer Breaking Changes, verlängert aber die Gesamtprojektlaufzeit, da für jede Zwischenversion ein eigener Test- und Deployment-Zyklus nötig ist.

Ein Big-Bang-Upgrade springt direkt von der aktuellen auf die Zielversion, ohne die Zwischenschritte einzeln zu durchlaufen. Dieser Ansatz ist schneller umsetzbar, birgt aber ein höheres Risiko, weil sich Breaking Changes über mehrere Versionen hinweg akkumulieren können und schwerer einzeln zu identifizieren sind, wenn ein Test fehlschlägt. Für Shops mit wenigen Custom-Modulen und guter Testabdeckung ist Big-Bang oft die pragmatischere Wahl, für Shops mit vielen individuellen Erweiterungen und historisch gewachsenem Code empfiehlt sich das schrittweise Rolling-Upgrade trotz des höheren Zeitaufwands.

#!/usr/bin/env bash
# upgrade-dry-run.sh: Kompatibilitaetspruefung vor einem Magento-Upgrade
set -euo pipefail

readonly TARGET_VERSION="2.4.8"

echo "[CHECK] Composer-Abhaengigkeiten gegen Zielversion pruefen"
composer require --dry-run "magento/product-community-edition=${TARGET_VERSION}"

echo "[CHECK] Custom-Module auf Deprecation-Warnungen pruefen"
bin/magento setup:di:compile --dry-run 2>&1 | grep -i deprecat || echo "Keine Deprecation-Warnungen gefunden"

echo "[CHECK] PHPStan-Kompatibilitaetsanalyse fuer Custom-Code"
vendor/bin/phpstan analyse app/code --level=5 --error-format=table

6. Risikobewertung bei verlängertem Betrieb auf EOL-Versionen

Manchmal ist ein Betrieb über den offiziellen End-of-Life-Termin hinaus aus Budget- oder Ressourcengründen unvermeidbar. In diesem Fall ist eine explizite Risikobewertung Pflicht, statt das Thema stillschweigend zu ignorieren. Zentrale Fragen sind: Welche kompensierenden Sicherheitsmaßnahmen lassen sich einrichten, etwa eine Web Application Firewall, die bekannte Angriffsmuster filtert, oder ein isoliertes Netzwerksegment, das den Zugriff auf die veraltete Instanz einschränkt? Wie hoch ist das tatsächliche Transaktionsvolumen und damit der potenzielle Schaden bei einem erfolgreichen Angriff?

Diese Risikobewertung sollte schriftlich dokumentiert und von der Geschäftsführung bewusst freigegeben werden, statt als informelle Entscheidung des Entwicklerteams zu verbleiben. Eine dokumentierte, akzeptierte Risikoentscheidung unterscheidet sich rechtlich und versicherungstechnisch erheblich von einer versehentlich übersehenen End-of-Life-Frist. Wichtig ist außerdem, den verlängerten Betrieb auf einer EOL-Version zeitlich zu begrenzen und einen verbindlichen Termin für das nachgeholte Upgrade festzulegen, statt den provisorischen Zustand unbegrenzt fortzuführen.

Typische kompensierende Maßnahmen, die sich in der Praxis bewährt haben, umfassen mehrere unabhängige Schutzebenen, die zusammen ein vertretbares Zwischenniveau an Sicherheit herstellen, bis das eigentliche Upgrade nachgeholt wird:

• Eine Web Application Firewall vor der veralteten Instanz, die bekannte Angriffsmuster und Exploit-Signaturen filtert.
• Ein isoliertes Netzwerksegment mit striktem Zugriffsschutz, das die Angriffsfläche der EOL-Version begrenzt.
• Verstärktes Logging und Alerting für ungewöhnliche Zugriffsmuster auf die betroffene Instanz.
• Ein verbindlich terminiertes Upgrade-Datum, das regelmäßig gegenüber der Geschäftsführung nachverfolgt wird.

7. Roadmap-Kommunikation an Stakeholder und Budgetplanung

Die technisch sauberste Magento Roadmap-Planung nützt wenig, wenn sie nicht rechtzeitig an die Stakeholder kommuniziert wird, die über Budget und Priorisierung entscheiden. Ein bewährtes Format ist ein jährlicher Roadmap-Review, in dem die aktuelle Version, die kommenden End-of-Life-Termine und der daraus resultierende Upgrade-Zeitplan gegenüber Geschäftsführung oder Produktverantwortlichen präsentiert werden, idealerweise mit einer groben Aufwandsschätzung für das nächste Upgrade-Projekt.

Diese Kommunikation sollte technische Details auf ein Minimum reduzieren und stattdessen auf Geschäftsrisiko und Kosten fokussieren: Ein ungepatchter Shop mit bekannten Sicherheitslücken ist ein konkretes Geschäftsrisiko, das in Euro und Reputationsschaden übersetzt werden kann, während ein rechtzeitig geplantes Upgrade als kalkulierbare, planbare Investition dargestellt wird. Wer die Magento Roadmap auf diese Weise kommuniziert, bekommt in der Regel deutlich leichter das nötige Budget freigegeben, als wenn das Upgrade erst als Notfallmaßnahme nach Erreichen des End-of-Life-Termins zur Sprache kommt.

<!-- app/code/Mironsoft/RoadmapMonitor/etc/crontab.xml -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Cron:etc/crontab.xsd">
    <group id="default">
        <job name="mironsoft_roadmap_eol_check" instance="Mironsoft\RoadmapMonitor\Cron\CheckEolStatus" method="execute">
            <!-- Woechentliche Pruefung, ob sich der EOL-Termin naehert -->
            <schedule>0 8 * * 1</schedule>
        </job>
    </group>
</config>

8. Die offiziellen Roadmap-Quellen überwachen

Um nicht bei jeder Planung manuell nach aktuellen Terminen suchen zu müssen, lohnt sich ein leichtgewichtiges Monitoring der offiziellen Magento Roadmap-Quellen. Dazu gehören der Adobe-Commerce-Softwarelebenszyklus-Kalender, das öffentliche Magento-2-GitHub-Repository für Sicherheitsankündigungen sowie der offizielle Adobe-Commerce-Security-Center-Feed, der neue Patches und deren Schweregrad veröffentlicht. Ein einfacher, selbst gebauter Cron-Job, der diese Quellen periodisch abruft und bei Änderungen eine Benachrichtigung auslöst, verhindert, dass ein wichtiger Termin unbemerkt verstreicht.

Ergänzend empfiehlt sich, den internen Versionsstand über composer show regelmäßig gegen die offizielle Roadmap abzugleichen, statt sich auf das Gedächtnis einzelner Teammitglieder zu verlassen. Ein einfaches internes Dashboard oder auch nur eine gepflegte Tabelle mit aktueller Version, EOL-Termin und geplantem Upgrade-Fenster reicht oft aus, um die End-of-Life-Planung nachvollziehbar und für das gesamte Team sichtbar zu machen, statt sie im Kopf einer einzelnen Person zu belassen.

9. Versionen, EOL-Daten und Handlungsempfehlung im Überblick

Die folgende Tabelle zeigt exemplarisch, wie eine strukturierte Übersicht über Magento-Versionen, deren EOL-Status und die daraus resultierende Handlungsempfehlung aussehen kann. Konkrete Daten sollten immer gegen die aktuelle offizielle Adobe-Dokumentation geprüft werden, da sich Termine ändern können.

Diese Klassifikation lässt sich direkt in ein internes Tracking übernehmen und regelmäßig aktualisieren, sodass jederzeit auf einen Blick ersichtlich ist, wo im Lebenszyklus die eigene Magento-Installation steht und welche Handlungsschritte als Nächstes anstehen.

10. Zusammenfassung

Eine solide Magento Roadmap- und End-of-Life-Planung verwandelt ein potenziell kritisches Sicherheitsrisiko in eine planbare, budgetierbare Aufgabe. Wer den Versionierungszyklus versteht, EOL-Termine über die offizielle Adobe-Dokumentation zuverlässig ermittelt und zwischen Quality Patches, Security Patches und Feature-Releases unterscheidet, vermeidet die typische Notfall-Migration unter Zeitdruck. Die Wahl zwischen Rolling Upgrade und Big-Bang-Strategie sollte sich an der Menge und Qualität der eigenen Custom-Module orientieren, nicht an reiner Geschwindigkeitspräferenz.

Der entscheidende Erfolgsfaktor ist rechtzeitige Kommunikation: Eine Magento Roadmap, die Monate im Voraus an Stakeholder kommuniziert wird, bekommt leichter Budget freigegeben als ein Upgrade, das erst nach Erreichen des End-of-Life-Termins zur Notfallmaßnahme wird. Ein leichtgewichtiges Monitoring der offiziellen Roadmap-Quellen stellt sicher, dass kein wichtiger Termin unbemerkt verstreicht, und macht die End-of-Life-Planung zu einem festen, wiederkehrenden Bestandteil des Betriebsprozesses statt einer einmaligen Ausnahmeaufgabe.

11. FAQ: Magento Roadmap und End-of-Life-Planung