Am 11. August 2026 endet der Support für Magento 2.4.6. Danach veröffentlicht Adobe keine Security-Patches mehr für diese Version — weder für Magento Open Source noch für Adobe Commerce (Extended Support ist optional und nur für zahlende Adobe-Commerce-Kunden verfügbar). Wer 2.4.6 betreibt, hat damit ein klares Datum, ab dem jeder neue CVE ein offenes Risiko bleibt. In diesem Artikel sortieren wir, was konkret zu tun ist, welche Upgrade-Pfade sich anbieten und wo sich Mage-OS als Alternative lohnt.
Was End-of-Life für Magento 2.4.6 wirklich heißt
Magento 2.4.6 erschien am 28. Februar 2023. Damit lief die Version dreieinhalb Jahre im aktiven Support — Standard für Adobes Magento-Linie. Was ab dem 11. August 2026 entfällt:
- Keine Security-Patches mehr. Adobe veröffentlicht ab August keine Magento-2.4.6-spezifischen CVE-Fixes. Jeder neu entdeckte Bug bleibt für 2.4.6-Shops offen.
- Keine Bug-Fixes mehr. Auch funktionale Probleme — Checkout-Glitches, GraphQL-Inkonsistenzen, Admin-UI-Hänger — werden nicht mehr rückportiert.
- Compliance-Pflicht. Wer PCI-DSS umsetzen muss (de facto jeder Shop, der Kreditkartendaten verarbeitet — auch über externe Payment-Provider via Iframe), darf eine unsupported Version nicht produktiv betreiben. PCI-DSS 4.0 verlangt explizit „supported software”.
- Extensions ziehen nach. Die meisten kommerziellen Magento-Extensions geben offiziellen Support für 2.4.6 mit Adobe-EoL ebenfalls auf. Wer auf älteren Extensions sitzt, verliert dort doppelt.
Wichtig: Dein Shop läuft nicht plötzlich nicht mehr am 12. August 2026. Er läuft. Aber er sammelt ab dann technische und rechtliche Schulden, die schneller wachsen, als die meisten erwarten.
Die Magento-Versions-Landkarte 2026
Bevor du planst, lohnt der Blick auf das aktuelle Versionsbild:
| Version | Released | End-of-Support (Adobe Commerce) |
|---|---|---|
| 2.4.5 | 01.08.2022 | 09.08.2025 (bereits EOL) |
| 2.4.6 | 28.02.2023 | 11.08.2026 |
| 2.4.7 | 04.04.2024 | 19.04.2027 |
| 2.4.8 | 03.04.2025 | 11.04.2028 |
| 2.4.9 | 12.05.2026 | ~Mai 2029 |
Eine Magento 2.5 ist nicht angekündigt. Adobe bleibt bei der 2.4.x-Linie, mit jährlichem Major-Release (Mai) und zwei aggregierten Patch-Releases pro Jahr (Mai/November) — das aktuelle Release-Schema seit 2026. Wer auf 2.4.9 upgraded, kauft sich drei Jahre Ruhe.
Die vier realistischen Optionen
Wir sehen in der Praxis vier saubere Wege aus dem 2.4.6-EoL — keine 25-Punkte-Listicle, sondern das, was wir mit Shop-Betreibern tatsächlich entscheiden.
Option 1 — Inkrementelles Upgrade auf 2.4.9
Der Standard-Pfad: 2.4.6 → 2.4.9 im selben Magento-Open-Source-Strang. Du gewinnst Support bis Mai 2029, PHP-8.4/8.5-Kompatibilität und die in 2.4.9 enthaltenen architektonischen Verbesserungen (laut Adobe rund 560 Bugfixes — das größte Bugfix-Volumen einer 2.4.x-Version bis dato). Aufwand bei sauber gepflegten Shops: zwei bis vier Wochen, inklusive Extension-Compatibility-Checks und Staging-Durchlauf. Bei stark customisierten 2.4.6-Shops mit veralteten Drittanbieter-Extensions: realistisch sechs bis zehn Wochen.
Wann sinnvoll: Dein Shop ist im Wesentlichen gesund, Custom-Code ist sauber, Extensions sind aktiv gepflegt. Du willst Magento bleiben und auf der Open-Source-Linie weitermachen.
Option 2 — Wechsel auf Mage-OS
Mage-OS ist die community-getriebene, 100 % kompatible Distribution von Magento Open Source. Mit Mage-OS 3.0 (veröffentlicht am 18. Mai 2026, basiert auf Magento 2.4.9) bekommst du dasselbe Support-Fenster wie Adobe — plus schnellere Security-Patches, einen eingebauten Audit-Trail (Admin Activity Log), einen PCI-DSS-4.0-Compatibility-Layer und eine integrierte Returns-Funktion ohne Extension. Die Umstellung selbst ist mechanisch klein: composer.json zeigt auf repo.mage-os.org statt repo.magento.com, composer update, deployen.
Wann sinnvoll: Du brauchst kein Adobe Commerce, willst aber kürzere Patch-Latenzen und keine Adobe-Account-Abhängigkeit mehr. Für Neuprojekte und reine Open-Source-Shops aus unserer Sicht inzwischen der Default.
Option 3 — Upgrade kombiniert mit Hyvä-Migration
Wenn ohnehin ein Upgrade ansteht, lohnt es sich, das Frontend gleich mitzumachen. Bei Hyvä — wir sind Hyvä Silver Partner — ersetzt du das Magento-Standard-Frontend (Luma) durch ein modernes Tailwind/Alpine-basiertes Theme. Realistische Ladezeiten unter 1 Sekunde auf Mobile, Lighthouse-Scores deutlich über 90. Der Mehraufwand zum reinen Versions-Upgrade liegt bei vier bis acht zusätzlichen Wochen, abhängig von Custom-UI-Komponenten.
Wann sinnvoll: Dein Frontend ist alt, Core Web Vitals sind unterirdisch, und der Magento-2.4.6-EoL-Zwang ist ein guter Anlass, das Performance-Thema endlich anzugehen.
Option 4 — Plattform-Wechsel oder Headless-Refactor
Wenn dein Shop strukturell an Magento vorbei gewachsen ist — etwa weil B2B-Anforderungen, Skalierung oder Multi-Brand-Setups jenseits dessen liegen, was Magento Open Source vernünftig abbildet — kann ein Plattformwechsel (Shopware, Spryker, reines Headless mit Astro/Next.js + Commerce-API) der ehrlichere Weg sein. Das ist kein „Upgrade”, das ist ein Re-Build mit allem, was dazugehört: 6–12 Monate Projektlaufzeit, Daten-Migration, neue Workflows, neue Tests.
Wann sinnvoll: Du hast schon zwei Magento-Upgrades aufgeschoben, hast eine wachsende Liste von Custom-Hacks und denkst sowieso darüber nach, ob Magento noch passt. Dann ist EoL der ehrliche Anlass.
Wie wir die Entscheidung in der Praxis treffen
Bevor wir mit Kunden einen Upgrade-Pfad fixieren, schauen wir uns vier Dinge an:
- Extension-Inventar. Welche Extensions sind installiert? Für jede einzelne: gibt es eine 2.4.9- (bzw. PHP-8.4/8.5-) kompatible Version? Ist sie noch aktiv gepflegt? Eine veraltete Payment-Extension kann ein 2-Wochen-Projekt in ein 8-Wochen-Projekt verwandeln.
- Custom-Code-Schulden. Wie viel Code lebt in
app/code/und wie eng ist er an Magento-Core-Interna gekoppelt? Plugins und Observer sind unproblematisch; Preferences und Core-Overrides sind teuer. - Schnittstellen-Landschaft. ERP, PIM, Payment, Shipping — jede Schnittstelle ist eine Kompatibilitätsprüfung. APIs ändern sich, REST-Endpoints werden ersetzt (Beispiel: USPS hat 2025/26 auf eine REST-API umgestellt).
- Geschäftliche Roadmap. Plant das Unternehmen in den nächsten 12 Monaten neue Märkte, neue Brands, einen Carve-out? Das beeinflusst Optionen 3 und 4 spürbar.
Aus diesen vier Dimensionen entsteht eine Aufwandsschätzung mit Korridor — keine Festpreiszusage, sondern eine ehrliche Range. Die echte Punktlandung kommt nach dem Audit.
Wann du anfangen solltest
Heute. Drei Monate vor Adobe-EoL ist üblicherweise zu spät, weil Staging-Tests, Extension-Updates und Coordination mit Payment-/Shipping-Providern realistisch vier bis acht Wochen reine Projektlaufzeit brauchen — bei einem sauberen Shop. Bei einem 2.4.6-Shop mit drei Jahren angefallenem Custom-Code planst du eher drei bis sechs Monate, inklusive Audit, Plan, Umsetzung, QA und Go-Live.
Wer heute (Mai 2026) startet, hat Puffer. Wer im Juli loslegt, hat keinen mehr.
Was du als nächstes tun kannst
Wenn dein Shop heute auf Magento 2.4.6 läuft, ist der nächste pragmatische Schritt ein technischer Audit: Extension-Inventar, Custom-Code-Schulden, Schnittstellen-Check, Hosting-Setup. Ergebnis ist eine priorisierte Roadmap mit Aufwandskorridor und benannten Risiken — die Grundlage, auf der wir gemeinsam den passenden der vier Pfade festlegen. Kontakt: Audit anfragen oder per Mail an office@copex.io.
Verwandte Themen aus unserem Blog: Unterschiede zwischen den Magento-2-Versionen, Was End-of-Life für betroffene Shops bedeutet, Sicheres Update- und Patch-Management für Magento, Mage-OS 3.0 als Alternative.
