Magento 2.4.6 EOL im August 2026: Patch-Tretmühle stoppen ohne Replatforming

Am 11. August 2026 endet der Regular Support für Magento 2.4.6. Wer noch auf 2.4.5 sitzt, ist seit dem 12. August 2025 außerhalb des Support-Fensters. Drei Optionen liegen auf dem Tisch - Patch-Sprint, Replatforming oder Frontend entkoppeln - und alle drei haben einen Pferdefuß.

Dieser Post ist für E-Commerce-Leads, CTOs und Heads of Engineering, die einen Magento-2-Shop mit 5 bis 100 Millionen Euro Online-Umsatz verantworten und gerade ausrechnen, was die nächsten 12 Monate kosten. Wir gehen die drei Pfade durch, zeigen den Rechenweg für jede Option und legen offen, wo eine Composable Commerce Migration über das Frontend günstiger landet als das Big-Bang-Replatforming.

Die drei Optionen im Vergleich

Stand heute hat jeder Magento-Merchant drei realistische Wege:

1. Patch-Sprint auf 2.4.7 oder 2.4.8 - Backend und Frontend bleiben, Aufwand wandert in die Patch-Pipeline. 2.4.7 läuft Regular Support bis 9. April 2027, 2.4.8 bis 11. April 2028. Adobe hat seit Januar 2026 auf monatliche Patch-Cycles umgestellt.
2. Replatforming - Komplett-Wechsel auf Shopify Plus, Shopware 6, commercetools, BigCommerce oder Adobe Commerce-on-Cloud. Typische Projektlänge: 12 bis 24 Monate, Backend und Frontend gleichzeitig neu.
3. Frontend entkoppeln - Magento-Backend bleibt unverändert, das Frontend wird über GraphQL angebunden und auf eine Frontend Management Platform (FMP) gehoben. Der Patch-Cycle bleibt im Backend isoliert, das Frontend hängt am API-Vertrag, nicht am Theme-Renderer.

Jede Option hat ein eigenes Risikoprofil. Die Wahl hängt weniger an der Technik als an der Frage, was in zwölf Monaten auf der Roadmap stehen muss - und wie viel Optionalität ihr euch danach erhalten wollt.

Option 1 - Patch-Sprint auf 2.4.7 oder 2.4.8

Der naheliegende Pfad: Magento 2.4.6 raus, 2.4.7 oder 2.4.8 rein, Support-Fenster verlängert. Klingt nach einem Wochenende Arbeit, ist aber in der Praxis ein eigenes Quartalsprojekt.

Was tatsächlich anfällt:

• Extension-Inventur - Jede Drittanbieter-Extension auf Kompatibilität mit der Ziel-Version prüfen. Bei DACH-Mid-Market-Shops typischerweise 40 bis 120 Extensions im Stack. Erfahrungswert: 20-30% brauchen Update oder Ersatz.
• Test-Pipeline aufsetzen oder verifizieren - Wer noch ohne CI-gestützte Regressions-Tests fährt, baut die jetzt. Mit monatlichen Patch-Cycles seit Januar 2026 ist manuelles Smoke-Testen nicht mehr skalierbar.
• Frontend-Re-Test pro Patch - Bei Luma-basiertem Theme: jeder Patch kann CSS- oder Layout-Regressionen auslösen. Bei Hyvä: weniger Frontend-Risiko, dafür eigene Migration vorgelagert.
• PHP-Version, Composer-Updates, Datenbank-Schema-Migrations - Standardthemen, aber Aufwandstreiber bei alten Custom-Modulen.

Kostenrahmen: Eine saubere Patch-Strategie für einen 5-bis-20-Millionen-Shop mit Luma-Theme landet bei 4.000 bis 12.000 Euro pro Patch-Cycle, plus monatlich 1.500 bis 4.000 Euro für Test- und Deploy-Pipeline. Über 12 Monate macht das in der Spitze einen sechsstelligen Betrag, der vollständig in „Status erhalten" fließt. Kein Cent in Conversion, Performance oder neue Features.

Der Pferdefuß: 2.4.8 EOL ist der 11. April 2028. In zwei Jahren steht die gleiche Frage wieder auf dem Tisch - und ihr habt sie nicht beantwortet, sondern verschoben.

Option 2 - Replatforming

Replatforming hat reale Risiken, und das gehört auf den Tisch. Wer nach 8 Jahren Magento auf Shopify Plus oder Shopware 6 wechselt, schreibt nicht nur ein Frontend neu - er migriert Produktdaten, Kundenkonten, Bestellhistorie, B2B-Preislisten, ERP-Integrationen, Marketing-Automation-Trigger und SEO-URL-Strukturen.

Typische Projektlänge: 12 bis 24 Monate. Typische Reibungspunkte:

• Daten-Migrations-Risiko - Mappings für Custom-Attribute, EAV-Strukturen, B2B-Kundengruppen. Erfahrungswert: 5 bis 15% der Datenmodelle brauchen Sonderbehandlung.
• SEO-Einbußen-Risiko - URL-Strukturen, Redirect-Mappings, Schema-Markup. Saubere 301-Redirect-Strategien dämpfen den Drop, vermeiden ihn aber selten ganz. Realistischer Rückgang in den ersten 3 bis 6 Monaten: 10 bis 30% organischer Traffic.
• Parallele Phasen-Komplexität - Während das neue Backend gebaut wird, muss das alte Magento weiter Patches einspielen. Zwei Stacks, zwei Teams, zwei Test-Pipelines.
• Feature-Parität - B2B-Features, Multi-Store, Multi-Brand und Custom-Workflows aus 5+ Jahren Magento-Customizing sind selten 1:1 auf der neuen Plattform abbildbar.

Kostenrahmen: 150.000 bis 800.000 Euro Implementierung, plus 3 bis 12 Monate parallele Lizenz- und Hosting-Kosten. Plus Opportunity-Cost: 12 bis 24 Monate, in denen das Team nicht an Konversion, Sortiment oder neuen Märkten arbeitet.

Replatforming ist die richtige Antwort, wenn das Backend selbst der Engpass ist - schlechte Performance unter Last, fehlende B2B-Features, nicht skalierbares Hosting. Wenn der Engpass das Frontend ist (Mobile-LCP, Theme-Wartung, Time-to-Market für neue Storefronts), schießt Replatforming am Problem vorbei.

Option 3 - Frontend entkoppeln

Hier setzen wir an: Magento-Backend behalten, Frontend von Luma-/Hyvä-/PWA-Trilemma entkoppeln. Der Patch-Cycle bleibt im Backend isoliert. Das Frontend hängt am GraphQL-API-Vertrag, nicht am Theme-Renderer. Wenn Adobe Magento 2.4.9 ausliefert, bekommt das Frontend davon im Idealfall nichts mit - der API-Contract bleibt stabil.

Konkret heißt das:

• Orchestr-Anbindung an Magento-GraphQL - Produkte, Kategorien, Customer, Cart, Checkout. Magento bleibt Source of Truth für alle Commerce-Operationen.
• Frontend Management Platform (FMP) - Studio (visueller Editor für Marketing-Teams), UI-Library (vorgebaute, themable Komponenten), Theming-Engine (mehrere Storefronts auf einer Codebasis).
• 50+ Backend-Integrationen via Orchestr - Search (Algolia, Klevu), CMS (Contentful, Storyblok), Payments, Loyalty, Subscriptions als parallele Datenquellen neben Magento.

Was ihr damit gewinnt:

• Patch-Optionalität - Backend-Patches betreffen das Frontend nicht direkt. Kein Frontend-Re-Test bei jedem Magento-Update.
• Performance ohne Hyvä-Migration - Mobile-LCP unter 2,5 Sekunden ist über die FMP-Edge-Architektur erreichbar, ohne das Backend-Theme anzufassen. Mehr dazu unter Performance & Core Web Vitals.
• BFSG-Konformität - Die UI-Library ist WCAG 3.0-konform ausgeliefert. Luma ist out-of-the-box nicht WCAG-3.0-konform, und die BFSG-Pflicht greift seit dem 28. Juni 2025.
• Replatforming-Optionalität - In 18 bis 24 Monaten könnt ihr das Backend von Magento auf commercetools, Shopware 6 oder Shopify B2B migrieren, ohne das Frontend nochmal anzufassen. Der API-Adapter im Orchestr-Layer wird getauscht, nicht die Storefront.

Wer sich detaillierter ansehen möchte, wann sich der Schritt zu Magento Headless wirklich rechnet, findet die Rechnung in unserem Magento-Headless-Switch-Post vom 03.05.2026.

Der Pferdefuß auch hier, fair benannt: Decoupling ist keine Antwort auf Backend-Probleme. Wenn Magento selbst zu langsam, zu teuer oder zu starr ist, löst eine FMP davor das nicht. Decoupling ist die Antwort, wenn das Backend tragfähig ist und das Frontend der Engpass.

Was DACH-Shops jetzt rechnen müssen

Vier Pfade, fünf Dimensionen, ein Vergleichsbild:

Dimension · Patch-Sprint 2.4.7/2.4.8 · Hyvä-Migration · Replatforming · Laioutr-FMP (Decoupling)

Aufwand-Wochen · 8-14 (initial) + laufend · 6-32 Wochen · 52-104 Wochen · <14 Tage Single-Store, 6-12 Wochen Multi-Brand

Frontend-Migration-Kosten · 0 (bleibt Luma) · 30.000-150.000 € + Lizenz 1.000-5.000 € einmalig + Subscription · im Replatforming-Budget enthalten (150.000-800.000 €) · im FMP-Modell enthalten

Mobile-LCP · 4-7 s (Luma typisch) · 1,8-3,0 s · abhängig von Zielplattform · <2,5 s

BFSG-Konformität · manuelle Theme-Arbeit nötig · abhängig von Custom-Theme · abhängig von Zielplattform · WCAG 3.0 out-of-the-box

Replatforming-Optionalität nach 18 Monaten · gering - gleiches Stack-Problem · gering - Hyvä-Theme bindet ans Backend · bereits durchgeführt · hoch - Backend tauschbar über Orchestr-Adapter

Was die Tabelle zeigt: Drei der vier Pfade sperren euch auf zwei Jahre auf eine Architektur-Entscheidung fest. Der vierte hält die Option offen, dass ihr in zwei Jahren auf Basis realer Daten neu entscheidet - ohne das Frontend nochmal zu bauen.

Migration-Pfad mit Laioutr

Wer mit der FMP-Route durchspielt, läuft typischerweise diesen Pfad. Die Wochen-Schätzungen kommen aus unseren letzten 12 Magento-Migrations:

1. Discovery (Woche 1) - Backend-Inventur, GraphQL-Audit, Extension-Liste, Performance-Baseline. Aktuelle Mobile-LCP, INP, CLS messen.
2. Orchestr-Setup (Woche 1-2) - Magento-GraphQL anbinden, Auth-Layer, Cart-/Checkout-Pfad. Ziel: API-Contract steht.
3. Komponenten-Mapping (Woche 2-3) - Bestehende Luma-/Hyvä-Komponenten auf FMP-UI-Library mappen. PDP, PLP, Cart, Checkout, Account, CMS-Pages.
4. Extension-Konsolidierung (Woche 2-3, parallel) - Welche Magento-Extensions können raus, weil die FMP-Layer die Funktion übernimmt? Search, A/B-Testing, Personalization, Mini-Cart-Logik wandern häufig nach vorn.
5. Multi-Brand-Aktivierung (optional, Woche 3-4) - Wer mehrere Storefronts fährt, schaltet sie hier auf eine gemeinsame Codebasis um.
6. Soft-Launch (Woche 4-6 für Single-Store, 6-12 Wochen Multi-Brand) - Schrittweiser Traffic-Switch über Edge-Routing. Rollback jederzeit möglich.

Median-Migration mit Founder-Begleitung: weniger als 14 Tage für einen Single-Store, der die Discovery-Phase mit sauberen Daten ins Projekt bringt. Das ist -65% gegenüber dem typischen Hyvä-Migrations-Mittelwert.

FAQ

Was ist EOL bei Magento?

End-of-Life (EOL) heißt: Adobe liefert keine Security-Patches und Bugfixes mehr für die betroffene Version aus. Bei Magento Open Source und Adobe Commerce 2.4.6 ist das Regular-Support-Ende der 11. August 2026. Danach läuft euer Shop auf einer Version, die bei neu entdeckten Sicherheitslücken nicht mehr offiziell gefixt wird - relevant für PCI-DSS und für Cyber-Versicherungen. Quelle: Adobe Magento Release Notes.

Lohnt eine Hyvä-Migration trotz EOL noch?

Hyvä ist saubere Technik und ein deutlicher Performance-Sprung gegenüber Luma - daran ist nichts auszusetzen. Die Frage ist die Investitionslogik: Eine Hyvä-Migration kostet 30.000 bis 150.000 Euro Implementierung plus Lizenz und bindet das Frontend an den Magento-Theme-Renderer. Wenn ihr in 18 bis 24 Monaten eine Replatforming-Diskussion erwartet, baut ihr ein Frontend, das ihr danach nochmal anfasst. Decoupling über eine FMP investiert das gleiche Budget in ein Frontend, das beide Pfade (Magento behalten oder Backend tauschen) offen hält.

Bleibt das Backend bei Decoupling wirklich unverändert?

In der Standard-Konfiguration ja. Magento bleibt Source of Truth für Produkte, Kategorien, Bestellungen, Customer. Die FMP konsumiert ausschließlich die offizielle Magento-GraphQL-API. Was ihr im Backend auf jeden Fall machen solltet: GraphQL-API auf aktuellen Stand bringen, Custom-Resolver für Sonderfälle (B2B-Preise, Custom-Attribute) sauber dokumentieren. Aber: kein Theme-Umbau, kein PHP-Eingriff, keine Magento-Extension-Welle.

Wie sieht die Migration in 12 Monaten Richtung Adobe Commerce oder anderes Backend aus?

Im Decoupling-Modell tauscht ihr im Orchestr-Layer den Backend-Adapter. Das Frontend, der Content, die Tracking-Pixel, das SEO-Mapping bleiben. Wir haben Customer, die so von Magento auf commercetools migriert sind und dabei ihr Frontend zu 100% behalten haben. Die typische Backend-Migration ohne Frontend-Neubau läuft in 8 bis 16 Wochen - gegenüber 52 bis 104 Wochen beim klassischen Replatforming.

Weitere Themen aus der Laioutr-Plattform

• Headless Frontend for Magento 2 - Pillar-2-Hub
• Composable Digital Experience Platform - Plattform-Hub
• Performance & Core Web Vitals
• Composable Headless Frontend - Architektur

Nächster Schritt

Wenn ihr den 11. August 2026 nicht als Patch-Deadline, sondern als Architektur-Entscheidung lesen wollt: Wir zeigen euch in 20 Minuten, wie das Decoupling für euren konkreten Magento-Stack aussieht. Inklusive Orchestr-Map für eure aktuellen Extensions und einer ehrlichen Einschätzung, wann Decoupling für euch nicht der richtige Weg ist.

[20-Minuten-Demo zur Magento-Decoupling-Architektur buchen →](https://www.laioutr.com/contact)

Die Architektur bleibt in eurer Hand. Decoupling statt Replatforming - und der nächste Magento-EOL-Cycle ist eine Backend-Frage, keine Frontend-Krise mehr.