OXID-6→7-Upgrade: Frontend entkoppeln, statt zu replatformen

OXID 6 läuft, das Backoffice ist eingespielt, die Custom-Module funktionieren. Aber der Frontend-Stack ist 8 Jahre alt, die Core Web Vitals sind im roten Bereich, und der 7er-Upgrade-Pfad heißt entweder „Replatforming-Projekt 18 Monate" oder „weiter auf 6.x bleiben und hoffen, dass die Sicherheits-Patches kommen". Es gibt eine dritte Option, die kaum jemand bespricht.

TL;DR

• OXID-6-Shops stehen 2026 vor einer Upgrade-Entscheidung, die in der Praxis ein Replatforming ist: 7.x bringt Symfony-Update, Theme-Layer-Bruch und Custom-Module-Migration in einem Paket.

• Option A (Volles 6→7-Upgrade) bindet 6 bis 12 Monate Engineering. Option B (auf 6.x bleiben) verschiebt das Problem.

• Option C: Frontend entkoppeln. Composable Frontend auf den OXID-6-Backend setzen, die Storefront in 4 bis 6 Wochen modernisieren, das Backend stabil halten und das 7er-Upgrade später isoliert ziehen oder ganz weglassen.

• Für die meisten OXID-6-Shops mit funktionierender Custom-Modul-Landschaft ist Option C die einzige rationale Wahl.

Die Lage 2026: OXID 7 ist da, der Druck ist real

OXID hat den 7er-Zweig stabilisiert. Version 7.2 läuft produktiv bei den ersten Lighthouse-Customers, und der Vendor arbeitet bereits an 8.0 mit Symfony-6-Sprung und MySQL-8-Anhebung. Das bedeutet für jeden OXID-6-Shop-Betreiber konkret: Die Frage ist nicht mehr ob, sondern wann. Und je länger gewartet wird, desto näher rückt das 8er-Upgrade an das 7er-Upgrade heran. Der Vendor wird perspektivisch 6.x in den End-of-Life-Modus überführen.

Gleichzeitig ist 2026 nicht 2018. Ein OXID-6-Standard-Theme bringt heute Core Web Vitals, die in Google's Page Experience Signal vergleichbar mit dem schwächeren Drittel des Marktes sind. LCP-Werte zwischen 3 und 5 Sekunden sind die Regel, mobile Conversion-Quoten leiden, und das Frontend-Developer-Reservoir mit echter OXID-Theme-Expertise wird im DACH-Markt jedes Quartal kleiner.

Die Combo aus Upgrade-Druck und Frontend-Modernisierungs-Druck führt dazu, dass viele Geschäftsführer aktuell ein Replatforming-Pitch auf dem Tisch haben. commercetools, Shopware 6, Adobe Commerce. Alle drei sind valide. Alle drei werfen die OXID-Investition der vergangenen Jahre weg.

Die drei strategischen Optionen im Vergleich

| Option | Was es bedeutet | TCO (3-Jahres-Sicht) | Time-to-Value | Risiko-Profil |
|---|---|---|---|---|
| **A: Volles 6→7-Upgrade** | Symfony-Update, Theme-Layer-Rebuild, Custom-Module-Migration, neue QA-Runde | € 250k bis € 800k Implementation + laufende Wartung | 9 bis 18 Monate bis Go-Live | Hoch: Frontend und Backend gleichzeitig in der Luft, Custom-Module-Risiko, Theme-Layer-Bruch |
| **B: Auf 6.x bleiben (Patch-Strategie)** | Sicherheits-Patches einspielen, Theme einfrieren, Frontend nicht anfassen | € 50k bis € 150k laufende Wartung + Opportunitäts-Kosten | sofort, aber Stagnation | Mittel-Hoch: Performance verschlechtert sich schleichend, EOL-Risiko, Developer-Skill-Erosion |
| **C: Frontend entkoppeln, Backend stabil** | Composable Frontend (Laioutr-FMP) als Storefront-Layer, OXID 6 als Backend, API-First-Integration | € 30k bis € 90k Setup + € 5.880 bis € 30.000/Jahr FMP-Lizenz | 4 bis 6 Wochen bis Go-Live des neuen Frontends | Niedrig: Frontend und Backend entkoppelt, Custom-Module bleiben unberührt, Upgrade-Option optional |

Option A ist die Standardantwort der OXID-Solution-Partner. Sie ist die teuerste, die langsamste und die einzige, die das gesamte Custom-Modul-Universum noch einmal anfassen muss. Option B ist eine Hoffnungs-Strategie. Sie verzögert die Entscheidung und akzeptiert den schleichenden Performance- und Skill-Verlust.

Option C ist der Weg, der in der Diskussion meistens fehlt. Er hat einen anderen Architektur-Gedanken: Trenne die beiden Probleme, die heute gemeinsam auf dem Tisch liegen. Das Backend-Upgrade ist ein Wartungs-Thema. Das Frontend ist ein Wachstums-Thema. Beide haben unterschiedliche Zeit-Horizonte und unterschiedliche Risiko-Profile. Wer sie zwingend koppelt, zahlt für beide den vollen Preis gleichzeitig.

Wie Decoupling konkret aussieht: drei Phasen

Phase 1: Composable Frontend aufsetzen (4 bis 6 Wochen)

Die Laioutr-Frontend-Management-Platform wird parallel zum OXID-6-Backend aufgesetzt. Die Storefront wird im Composable-Stack neu gebaut, mit Live-Editor für Marketing-Content, Component-Library auf Brand-Guidelines und vorkonfigurierten Performance-Patterns. Die Verbindung zum OXID-Backend läuft über die OXID-REST-API plus einen Connector-Layer, der die Custom-Module-Endpoints stabil exponiert.

Was in dieser Phase nicht passiert: das OXID-Backend wird nicht angefasst. Keine Code-Änderungen an Custom-Modulen. Keine Theme-Layer-Migration. Keine Backoffice-Schulung. Das Backoffice bleibt das, was die Operations-Mannschaft seit Jahren kennt.

Phase 2: OXID-Storefront durch Laioutr-Storefront ersetzen

Sobald das Composable Frontend abgenommen ist, wird der Traffic von der OXID-Storefront auf die neue Storefront umgezogen. Das passiert üblicherweise per Sub-Domain-Cut oder per Route-basiertem Rollout. Wer Risiko reduzieren will, kann das Frontend pro Brand, pro Markt oder pro Page-Type schrittweise umstellen. Das Multi-Brand-/Multi-Market-Pattern ist genau dafür gebaut, siehe das Produkt-Modul Multi-Brand & Multi-Market.

Ab diesem Punkt läuft die Conversion-Strecke auf modernem Stack. Core Web Vitals out-of-the-box, mobile-first-Performance, A/B-Tests pro Page-Type, Personalisierung pro Segment. Das Backoffice-Team merkt davon nichts, weil die Order- und Customer-Flows nach wie vor durch das OXID-Backend laufen.

Phase 3: Das 7er-Upgrade isoliert ziehen, oder gar nicht

Wenn das Frontend einmal entkoppelt ist, wird das 7er-Upgrade ein reines Backend-Projekt. Kein Theme-Layer-Bruch, weil das Theme nicht mehr existiert. Keine Frontend-Regression-Tests, weil das Frontend nicht aus OXID kommt. Das Upgrade-Projekt schrumpft auf den reinen Backend-Scope: Symfony-Update, Custom-Module-Anpassung an die 7er-API, Daten-Migration.

Viele Shops, die diesen Weg gehen, stellen nach 6 bis 12 Monaten fest, dass das 7er-Upgrade gar nicht zwingend ist. Wenn das Backend stabil läuft, die Performance über das entkoppelte Frontend gelöst ist und die Custom-Module weiterhin funktionieren, wird das Backend-Upgrade ein normales Wartungs-Thema. Es passiert dann, wenn der Vendor es erzwingt, nicht wenn der Geschäftsführer entscheiden muss.

Wann sich Decoupling lohnt, und wann nicht

Decoupling ist keine Universal-Lösung. Es lohnt sich, wenn die folgenden Bedingungen zutreffen:

1. Das OXID-Backend funktioniert. Order-Management, Pricing, Custom-Module, Logistik-Integrationen. Wenn das Backend selbst zur Last geworden ist, ist Replatforming ehrlicher.

2. Das Frontend ist das stärkere Schmerzthema. Core Web Vitals, Mobile-Conversion, Time-to-Market für Marketing-Content. Wenn die Pain-Stelle eindeutig vorne sitzt, ist Decoupling die schärfste Antwort.

3. Die Custom-Module-Landschaft ist substanziell. Wer 30, 50 oder 100+ Custom-Erweiterungen hat, wirft mit Replatforming massiv Investition weg. Decoupling konserviert sie.

4. Time-to-Value zählt. Wer dieses Jahr noch Frontend-Performance braucht, kommt mit Decoupling in Wochen ans Ziel, mit Upgrade-A in Quartalen, mit Replatforming in Jahren.

5. Das Frontend-Team kann den Composable-Stack betreiben. Oder ein Partner übernimmt die Frontend-Operations. Composable ist nicht magisch, es braucht andere Skills als ein OXID-Theme.

Wenn diese Punkte nicht passen, ist Decoupling nicht der richtige Weg. Bei akut maroden Backends, bei sehr kleinen Shops ohne Custom-Logic, oder bei Teams, die auf Standard-OXID-Theme zufrieden sind, gibt es einfachere Antworten.

Was wir bei einem Magento-Stack analog gesehen haben

Der gleiche Architektur-Gedanke gilt für andere Legacy-Stacks. Wer wissen will, wie das Decoupling-Muster bei einem Magento-2.4.6-EOL-Druck konkret läuft, findet das im Schwester-Post zur Magento-2.4.6-EOL-Patch-Tretmühle und Frontend-Entkopplung. Für eine OXID-spezifische Vertiefung in die Frontend-Alternative gibt es die OXID-Frontend-Alternative als Begleit-Lektüre.

FAQ

Was passiert mit unseren OXID-Custom-Modulen? Sie bleiben unangetastet. Die Custom-Module laufen weiter im OXID-Backend und werden über die OXID-REST-API plus einen Connector-Layer für das Composable Frontend exponiert. Wo die Standard-API nicht reicht, baut der Connector-Layer die fehlenden Endpoints. Migration der Module ist nur dann nötig, wenn das Modul direkt im Theme-Layer hängt, was bei sauber gebauten Modulen nicht der Fall ist.

Wie lange dauert die Decoupling-Phase? Phase 1 (Composable Frontend aufsetzen plus Connector-Layer) liegt typischerweise bei 4 bis 6 Wochen für einen mittelgroßen Shop. Phase 2 (Cut-Over) ist eine Frage des Rollout-Stils und kann zwischen 1 Tag (Big-Bang) und 8 Wochen (Page-Type-by-Page-Type) liegen. Phase 3 ist optional und hat keinen festen Zeitplan.

Müssen wir später trotzdem auf OXID 7 umsteigen? Nein, nicht zwingend. Wenn das Frontend entkoppelt ist und das OXID-6-Backend stabil läuft, wird das 7er-Upgrade zu einer normalen Wartungs-Entscheidung. Viele entkoppelte Shops bleiben über mehrere Jahre auf 6.x mit Patch-Support und upgraden erst dann, wenn der Vendor das EOL erzwingt. Das Upgrade ist dann ein reines Backend-Projekt ohne Frontend-Risiko.

Was kostet das im Vergleich zu einem Full-Replatforming? Ein Full-Replatforming auf commercetools, Shopware 6 oder Adobe Commerce liegt für mittelgroße DACH-Shops typischerweise im Bereich € 200.000 bis € 2 Mio. Implementation, plus Lizenzkosten der neuen Plattform. Decoupling mit Laioutr-FMP startet bei € 30.000 bis € 90.000 Setup plus € 5.880 bis € 30.000 jährlicher FMP-Lizenz. Die Backend-Investition in OXID bleibt erhalten.

Wer betreibt das Frontend dann? Drei Modelle sind üblich. Eigenes Frontend-Team mit Composable-Stack-Skills (für Shops mit substanzieller Digital-Mannschaft). Frontend-Partner-Agentur mit Laioutr-Zertifizierung (für Shops ohne dedizierte Frontend-Crew). Hybrid mit Laioutr-Founder-Begleitung in den ersten 12 Wochen (typisch für Shops, die intern aufbauen). Das Backoffice und das OXID-Backend werden weiter vom bisherigen OXID-Partner betreut, das ändert sich nicht.

Nächste Schritte

Wenn das Bild passt, lass uns über den konkreten Decoupling-Pfad für deinen Shop sprechen. Wir gehen die Custom-Modul-Landschaft durch, schauen auf die Core-Web-Vitals-Basis und legen einen Phasen-Plan auf, der ohne Replatforming auskommt. Sprich mit uns über den OXID-Decoupling-Pfad auf der Backend-Pillar-Page für OXID. Für die strategische Plattform-Ebene über alle Backends hinweg lohnt sich der Einstieg über die Composable-Digital-Experience-Plattform-Übersicht.

Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und arbeitet seit 2024 an der Kategorie Frontend Management Platform. Davor war er als Berater und Operator in mehreren E-Commerce-Plattform-Migrations-Projekten im DACH-Markt tätig.

Quellen:

• OXID eShop Release Plan, docs.oxid-esales.com/en/releases/release-plan.html

• OXID eShop 7 Roll-out, Netensio, netensio.de/en/e-commerce-blog/articles-about-oxid-eshop/oxid-eshop-version-7-is-now-available.html