Replatforming vs. Frontend-Renovation: OXID-Framework 2026

Die OXID-6-auf-7-Migration ist nicht nur ein technisches Upgrade. Sie ist eine strategische Weggabelung mit drei Optionen, einer richtigen Antwort pro Kontext, und einer Frage, die viele zuerst gar nicht stellen.

Dieser Post liefert Dir das Entscheidungs-Framework: drei Optionen auf dem Tisch (Upgrade, Replatforming, Frontend-Renovation), eine IDC-Datenpunkt-Schicht, die TCO ehrlich macht, und eine Decision-Logic, die Dir sagt, welche Option für Deinen Kontext die richtige ist.

Wo OXID-Customer 2026 wirklich stehen

OXID hat das Major-Upgrade von Version 6 auf Version 7 ausgerollt. In der Customer-Base sehen wir drei wiederkehrende Beobachtungen:

1. Das Upgrade ist invasiv. Viele Customer-Anpassungen müssen neu gemacht werden, der Implementations-Aufwand liegt typischerweise bei 3-9 Monaten.
2. Das Frontend wurde in vielen Shops über Jahre nicht angefasst, weil das nächste Backend-Großprojekt vor der Tür stand. Folge: schwache Core Web Vitals, schwache Mobile-Conversion, Frontend-Iteration in Wochen statt Tagen.
3. Die Frage wird strategisch: „Wenn wir eh viel Aufwand reinstecken, sollten wir nicht direkt eine modernere Plattform wählen?" Replatforming-Optionen wie commercetools, Shopware 6 oder Adobe Commerce stehen offen im Raum.

Das ist die Lage. Drei Optionen, drei sehr unterschiedliche Rechnungen, eine Entscheidung, die für die nächsten 5-7 Jahre trägt.

Drei Optionen auf dem Tisch

Die Tabelle ist absichtlich nüchtern. Es gibt keinen Gewinner-Spalten-Eintrag pro Zeile, der für alle Customer stimmt. Was die Tabelle aber sichtbar macht: Option 3 ist die einzige, die Du parallel zu jeder anderen Option laufen lassen kannst, ohne sie zu blockieren.

Die IDC-Datenpunkt-Schicht, die viele übersehen

Wenn Du Replatforming in Richtung Composable-Commerce-Stack (commercetools, Spryker, VTEX) diskutierst, gibt es einen Datenpunkt, der in den meisten Vendor-Pitches fehlt: laut IDC liegt der TCO eines Composable-Commerce-Setups über einen 3-Jahres-Horizont beim 2,2- bis 3,1-fachen eines Headless-Setups (Quelle: IDC 2024 Worldwide Digital Commerce Spending Guide, zitiert im BigCommerce 2026-Update).

Was bedeutet das konkret für Mid-Market-OXID-Customer? Die Composable-Story wird typischerweise mit „besser, moderner, zukunftsfähiger" verkauft. Die TCO-Wahrheit ist: Du zahlst für jede der MACH-Komponenten (Headless-Commerce, CMS, Search, Personalization, Checkout) eine separate Lizenz, integrierst sie über Custom-Glue-Code, hostest sie selbst und betreibst sie mit einem Team, das jede Komponente kennen muss. Über drei Jahre summiert sich das zu einer Rechnung, die im Pitch-Deck nie auftaucht.

Das ist kein Argument gegen Composable-Commerce. Es ist ein Argument dafür, die Composable-Entscheidung nicht aus dem 6-auf-7-Upgrade-Druck heraus zu treffen, sondern aus einer ehrlichen Business-Rechnung. Wer den Druck aus der Frontend-Frage rausnimmt, hat den Kopf frei für die Backend-Frage. Mehr dazu in unserem TCO-Deep-Dive zu Budget als Composable-Barriere.

Was bedeutet Frontend-Renovation konkret?

Frontend-Renovation heißt: Du modernisierst das Frontend jetzt, während Dein OXID-6-Backend stabil weiterläuft. Der OXID-7-Upgrade-Move kommt später separat, ohne Frontend-Risiko.

Technisch funktioniert das, weil Laioutr-FMP sich via API an OXID koppelt. Frontend und Backend werden entkoppelt. Storefront-Iteration läuft unabhängig vom OXID-Core. Wenn OXID 7 später ansteht: das Frontend bleibt unverändert, das Backend wird isoliert migriert. Das ist USP 1 unserer Plattform: jedes Backend, ein Frontend, kein Lock-in.

Der zweite Effekt ist Time-to-Market. Wo klassische OXID-Theme-Pflege bei 4-12 Wochen pro Frontend-Change liegt, sehen wir mit FMP-Setup Iterationen in 1-3 Tagen. Das ist USP 2: Marketing-Teams bauen Landing-Pages selbst im Studio mit Live-Preview, Engineering reviewt und erweitert. Banner-Tickets verschwinden aus dem Backlog.

Den vollständigen Decoupling-Walkthrough für OXID-Setups haben wir hier dokumentiert: OXID 6 auf 7 Upgrade entkoppeln, ohne Replatforming.

Wann lohnt sich welche Option

Es gibt keine universelle Antwort. Es gibt drei Wenn-Dann-Statements pro Option, die in der Praxis tragen.

Option 1 (Upgrade) lohnt sich, wenn:

• Dein Backend-Customizing flach ist und das 7er-Upgrade in 3-4 Monaten realistisch durchläuft.
• Deine Wachstums-Ambition stabil ist, kein Multi-Storefront-/Multi-Market-Druck.
• Deine Frontend-Performance kein akutes Conversion-Problem ist.

Option 2 (Replatforming) lohnt sich, wenn:

• OXID strategisch nicht mehr passt (z. B. Wechsel zu B2B-only-Backend mit OMS-Anforderungen, die OXID nicht abdeckt).
• Du bereit bist, 12-24 Monate Greenfield zu investieren und Frontend-Innovation in der Zeit zu pausieren.
• Das Replatforming-Ziel klar definiert ist und nicht aus „weg von OXID" allein gespeist wird.

Option 3 (Frontend-Renovation) lohnt sich, wenn:

• Dein Frontend der Engpass ist (Performance, Mobile-Conversion, Time-to-Market) und nicht das Backend.
• Du das OXID-7-Upgrade nicht vermeiden, aber zeitlich entzerren willst.
• Du Multi-Storefront, Multi-Market oder Multi-Brand brauchst, ohne das Backend zu zerschlagen.
• Du Dir die Replatforming-Option für später offenhalten willst, ohne sie heute zu erzwingen.

Das letzte Bullet ist der unterschätzte Hebel. Frontend-Renovation ist die einzige Option, die Optionalität bewahrt.

Was Du gewinnst

Nach Auskunft eines typischen DACH-Mittelständlers aus unserer Customer-Base hat genau dieses Pattern (Frontend jetzt, Backend später) das Team in die Lage versetzt, Black-Friday-Aufsätze in Tagen statt Sprints auszuspielen, während die Backend-Roadmap ungestört weiterläuft. Der Customer-Namensanker ist hier bewusst neutral gehalten: die Press-Klausel im Reference-MSA ist für die namentliche Nennung noch nicht geklärt.

FAQ

Wann lohnt Replatforming wirklich? Wenn OXID strategisch nicht mehr zur Backend-Anforderung passt (z. B. komplexe B2B-OMS-Szenarien, die OXID nicht abdeckt), wenn ein konkreter Ziel-Stack definiert ist, und wenn das Team die 12-24 Monate Greenfield-Investition organisatorisch abfedern kann. „Weg von OXID" allein ist kein Replatforming-Argument.

Was kostet 6 auf 7 ohne Frontend-Anteil? Reine Backend-Migration liegt typischerweise bei 3-9 Monaten Implementations-Aufwand. Der Frontend-Anteil treibt diese Spanne oft auf 6-12 Monate. Wenn Du den Frontend-Teil per Renovation vorab entkoppelst, schrumpft die 6-auf-7-Migration auf das reine Backend-Thema und planbarer.

Wie lange dauert Frontend-Renovation? Mit Founder-Begleitung sehen wir in unserer Customer-Base 6-12 Wochen für einen Standard-OXID-Shop, mediane Migrationszeit liegt unter 14 Tagen für den Plattform-Aufsatz selbst. Der Rest ist Content-Migration, Theme-Aufbau und Go-Live-Vorbereitung.

Bleibt OXID-Investment erhalten? Ja. Frontend-Renovation berührt den OXID-Core nicht. Produktdaten, Order-Management, Checkout-Logik, B2B-Preise, ERP-Anbindung bleiben im OXID-Backend. Laioutr koppelt sich via API daran an. Alle OXID-Customizings und Module bleiben funktional.

Wann switche ich später trotzdem? Wenn sich Deine Backend-Anforderungen so verändern, dass OXID nicht mehr passt. Der Vorteil: Das Frontend bleibt unverändert, der Backend-Wechsel ist ein isoliertes Projekt. Du sparst Dir den klassischen Replatforming-Doppelschmerz (Frontend + Backend gleichzeitig neu).

Nächste Schritte

Wenn Du gerade in der 6-auf-7-Entscheidung steckst oder Replatforming intern diskutierst: spricht das Pattern Deine Situation an? Lass uns in 30 Minuten Dein Setup durchgehen. Wir schauen Dir auf die Backend-Tiefe, das Frontend-Alter, die Multi-Storefront-Anforderung und liefern Dir eine Einschätzung, welche der drei Optionen für Deinen Kontext rechnet.

Termin direkt buchen

Weitere Themen aus der Laioutr-Plattform

• Headless Frontend für OXID
• Composable Digital Experience Platform
• Multi-Brand, Multi-Market