Answer-Engine-Optimization ist eine Architektur-Eigenschaft, kein Bolt-onDiese Woche sind zwei Dinge…
OXID 6 End-of-Life: Was der Kalender fürs Frontend heißt
OXID 6 End-of-Life: Was der Kalender fürs Frontend heißt
OXID 6 ist kein laufendes Produkt mehr, sondern eine auslaufende Version. Im offiziellen Release-Plan von OXID eSales steht die 6er-Reihe seit 2024 durchgehend auf "legacy" und bekommt nur noch ausgewählte wichtige Fixes, keine vollen Maintenance-Updates. Die strategische Frage ist deshalb nicht "ob", sondern "wann" und "in welcher Reihenfolge" Du reagierst. Unsere Antwort: Frontend zuerst entkoppeln, Backend-Upgrade danach separat, kein Big-Bang-Replatforming.
Was bedeutet OXID 6 End-of-Life genau?
OXID arbeitet nicht mit fixen Kalender-EOL-Daten pro Version, sondern mit einem rollierenden Support-Modell: Es gibt immer eine Maintenance-Version (die bekommt die meisten Fixes) und zwei Legacy-Versionen (die bekommen nur noch ausgewählte wichtige Fixes, typisch Security- und Compliance-relevant). Alles davor gilt als veraltet und erhält nicht mehr alle Patches.
OXID 6.5 ist die letzte Minor-Version der 6er-Reihe, es gibt keine 6.6. Im Release-Plan steht 6.5 über alle Quartale von Q2/2024 bis "TBA" auf Legacy-Status. Die aktive Maintenance-Linie ist inzwischen die 7er-Reihe (7.5 als Maintenance im Q2/2026, 7.4 als Legacy). Praktisch heißt das: Wer auf OXID 6 sitzt, läuft auf einer Version, die nur noch Notfall-Pflege bekommt und mit jedem neuen 7er-Release weiter aus dem Support-Fenster rutscht.
Hinweis zu den Daten: OXID kommuniziert Status (maintenance / legacy / outdated) und Quartals-Fenster, keine harten Tages-EOL-Daten pro 6.x-Version. Die Tabelle unten bildet diesen Status-Kalender ab. Verifiziere den aktuellen Stand im offiziellen OXID Release Plan, bevor Du Budget-Entscheidungen darauf aufbaust.
Der OXID-6.x-Lifecycle-Kalender (Status statt fixe Daten)
| Version | Rolle 2024-2025 | Rolle Q2/2026 | Was das fürs Frontend heißt |
|---|---|---|---|
| OXID 6.0 - 6.4 | outdated | outdated | Kein voller Patch-Stream mehr. Frontend-Themes auf veraltetem PHP-/Template-Stand, A11y- und Performance-Schuld wächst. |
| OXID 6.5 | legacy | legacy | Nur noch ausgewählte wichtige Fixes (Security/Compliance). Letzte 6er-Minor, keine 6.6 mehr. Frontend bekommt keine Innovation aus dem Core. |
| OXID 7.0 - 7.3 | dev bis legacy | legacy / outdated | 7er-Reihe ist aktiv, aber Upgrade bedeutet Re-Implementierung vieler Customer-Anpassungen. |
| OXID 7.4 / 7.5 | dev / - | legacy / maintenance | Aktive Maintenance-Linie. Das ist das Upgrade-Ziel, aber mit dem bekannten 6 zu 7 Aufwand (typisch 3-9 Monate). |
Der Kalender sagt klar: OXID 6 ist nicht "morgen tot", aber es ist eine Sackgasse für alles, was am Frontend Innovation braucht. Performance, Accessibility (BFSG ist seit 28.06.2025 Pflicht), mobile Conversion und schnelle Kampagnen-Iteration kommen aus einem Core, der nur noch Notfall-Pflege bekommt.
Das Problem, das viele OXID-Shops aktuell haben
Wir sehen bei OXID-6-Betreibern fast immer dasselbe Muster: Das Frontend wurde seit Jahren nicht angefasst, "weil das 6 zu 7 Upgrade noch vor uns liegt". Das Upgrade ist invasiv, viele Anpassungen müssen neu gemacht werden, und es kostet typischerweise 3-9 Monate Implementierungs-Aufwand. Also wartet das Team, und in der Wartezeit altert das Frontend weiter.
Daraus entsteht die falsche Entweder-oder-Frage: aufwendig auf OXID 7 migrieren oder gleich zu commercetools / Shopware 6 / Adobe Commerce replatformen. Beide Optionen sind unangenehm. Das Upgrade bindet Monate, das Replatforming wirft Jahre an OXID-Investment weg und kostet typisch sechsstellig bis in den Millionenbereich. In beiden Fällen passiert am Frontend, also dort, wo die Endkundin tatsächlich kauft, monatelang nichts.
Genau dieses Muster haben wir auch für Magento-Betreiber beschrieben, als die Magento-2.4.6-EOL-Frage zur Patch-Tretmühle wurde. Vendor-EOL erzeugt fast immer denselben Reflex, und fast immer ist der Reflex teurer als nötig.
Wie Laioutr das löst: Frontend entkoppeln, Backend stabil halten
Du musst das Backend-Upgrade und die Frontend-Modernisierung nicht gleichzeitig stemmen. Mit der Laioutr Frontend Management Platform (FMP) setzt Du ein Composable Headless Frontend oben auf Dein bestehendes OXID-6-Backend, angebunden über die OXID-API. Frontend und Backend sind ab diesem Moment entkoppelt:
- Das Frontend modernisierst Du jetzt: Composable Storefront auf Nuxt, Core Web Vitals out-of-the-box, BFSG-konforme Komponenten ab Werk, Kampagnen-Pages aus dem Studio in Stunden statt Sprints.
- Das OXID-6-Backend läuft stabil weiter, mit dem Security-/Compliance-Fix-Stream der Legacy-Linie, ohne dass Du es für die Frontend-Arbeit anfassen musst.
- Das OXID-7-Upgrade machst Du später separat. Weil die Datenanbindung über eine GraphQL-Schicht (Orchestr) normalisiert ist, bleibt das Frontend beim Backend-Wechsel unverändert. Du tauschst die Anbindung, nicht die Storefront.
Das ist der Kern unseres Decoupling-Versprechens: jedes Backend, ein Frontend, kein Lock-in. Die Reihenfolge ist Frontend-First, nicht Big-Bang. Wie das technisch aussieht, haben wir im Detail beschrieben in OXID 6 zu 7 Upgrade: Frontend ohne Replatforming entkoppeln.
Was Du gewinnst
| Dimension | OXID 6 mit klassischem Frontend | Mit Laioutr-FMP (entkoppelt) |
|---|---|---|
| Time-to-Market neue Features | 4-12 Wochen pro Frontend-Change | 1-3 Tage aus dem Studio |
| Performance (LCP) | typisch 3-5 s bei alten Themes | unter 2,5 s, Core Web Vitals ab Werk |
| Accessibility / BFSG | Nachrüst-Sprint nötig | WCAG-konforme Komponenten ab Werk |
| EOL-Druck | wächst mit jedem 7er-Release | entkoppelt, Backend-Upgrade planbar |
| Kosten der Modernisierung | hoch (Replatforming-Druck) | mittel (FMP-Investment, Backend bleibt) |
FAQ
Muss ich wegen OXID 6 End-of-Life sofort upgraden? Nein, nicht sofort. OXID 6.5 ist Legacy, nicht abgeschaltet, und bekommt weiter ausgewählte Security-/Compliance-Fixes. Der Druck ist real, aber Du kannst die Reihenfolge selbst wählen: Frontend jetzt entkoppeln und modernisieren, Backend-Upgrade als separates, planbares Projekt danach.
Was kostet das im Vergleich zum Replatforming? Ein Frontend-Decoupling mit der FMP liegt deutlich unter den typischen Replatforming-Kosten (sechsstellig bis Millionen). Die genaue Plan-Zuordnung findest Du auf unserer Preis-Seite.
Wie lange dauert die Frontend-Anbindung an OXID 6? Migrationen mit Founder-Begleitung dauern bei uns im Median unter 14 Tage. Das hängt von Deiner Daten-Komplexität ab, aber es ist Größenordnung Wochen, nicht Monate.
Können wir später trotzdem auf OXID 7 oder eine andere Plattform wechseln? Ja, genau das ist der Punkt. Das Frontend ist backend-agnostisch angebunden. Wenn Du später auf OXID 7 oder ein anderes Backend gehst, bleibt die Storefront bestehen, Du tauschst nur die Anbindung.
Nächste Schritte
Wenn Du auf OXID 6 sitzt und das 6 zu 7 Upgrade vor Dir herschiebst: Lass uns 20 Minuten über den Decoupling-Pfad sprechen, den Du fahren kannst, ohne Dein OXID-Setup anzufassen. Details zum Backend findest Du auf Headless Frontend für OXID.
Weitere Themen aus der Laioutr-Plattform
- Composable Headless Frontend - der entkoppelte Frontend-Layer über jedem Commerce-Backend
- Composable Visual Page Builder - Studio: Kampagnen-Pages in Stunden statt Sprints
- Composable Digital Experience Platform - die DXP-Architektur ohne Designer-Lock-in
- Agentic Frontend Management Platform - Larry AI und die Frontend Agents auf dem entkoppelten Layer
- Headless Frontend für OXID - der OXID-spezifische Anbindungs-Pfad
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr. Er begleitet DACH-Merchants beim Schritt vom monolithischen Shop zum entkoppelten Composable Frontend, mit Fokus auf Decoupling statt Replatforming.