Die eine Frage, die euer Replatforming entscheidet

Ihr wisst, dass euer Commerce-Stack modernisiert werden muss. Die Frage ist nicht ob, sondern wie ihr es angeht, ohne dass das Projekt im Sand verläuft.

Und genau da liegt das eigentliche Sequencing-Problem: Fängt ihr mit dem Backend an (OMS, Checkout, Produktdaten) oder mit dem Frontend (Storefront, Kampagnen-Pages, Kundenerlebnis)? Diese Entscheidung bestimmt euer Risikoprofil, euren Budget-Verlauf und wie schnell ihr sichtbare Ergebnisse vorweisen könnt.

Dieser Leitfaden richtet sich an die Entscheider im Raum: COO, CTO, CFO und alle, die das Budget verantworten. Keine Architektur-Tiefen, keine Stack-Vergleiche. Sondern: Welche Reihenfolge trägt weniger Risiko, liefert früher Wert und hält euer Budget kalkulierbar?

Das klassische Backend-First-Modell: Was es verspricht und was es kostet

Option A ist der Instinkt vieler Unternehmen: Erst das Fundament stabil machen, dann das Haus bauen. Backend-First bedeutet: Ihr wechselt zuerst Plattform, OMS, ERP-Anbindung oder Checkout-Layer, und das Frontend läuft währenddessen auf dem Altsystem weiter.

Was für Backend-First spricht

• Datenkonsistenz von Anfang an: Ihr baut das neue Frontend auf sauberer Datenbasis.
• Keine doppelten Daten-Mappings: Ein Integrations-Layer statt zweier paralleler Schichten.
• Klare Übergabe: Wenn das Backend steht, folgt das Frontend auf einem stabilen Fundament.

Was Backend-First in der Praxis kostet

Das Problem ist der Zeithorizont. Ein Backend-Wechsel dauert im Mid-Market typischerweise 9 bis 18 Monate, je nach Komplexität des Katalogs, der Checkout-Logik und der ERP-Anbindungen. Während dieser Zeit:

• Keine sichtbaren Ergebnisse: Marketing und Vertrieb sehen monatelang keinen Fortschritt. Das Storefront sieht aus wie 2021, weil das Frontend eingefroren ist.
• Parallele Systeme als Kostentreiber: Ihr bezahlt doppelt. Das Altsystem läuft weiter (Lizenz, Hosting, Support), das neue System ist im Aufbau (Entwicklungskosten, Integrations-Arbeit).
• SEO-Risiko beim Cut-over: Wenn nach 12 Monaten Backend-Arbeit das neue Frontend in 6-8 Wochen aufgesetzt werden muss, ist der Zeitdruck hoch. URL-Struktur, interne Verlinkung und Content-Migration laufen unter Stress, und SEO-Drops von 20-40% in den ersten Wochen nach einem schlecht geplanten Cutover sind dokumentiert.
• Abort-Risiko: Je länger ein Projekt dauert, bevor es sichtbaren Nutzen liefert, desto höher die Wahrscheinlichkeit, dass Budget oder Organisationsenergie enden.

Backend-First ist kein falscher Ansatz. Aber er setzt voraus, dass euer Budget 18 Monate parallele Betriebskosten trägt und dass eure Organisation so lange ohne sichtbare Ergebnisse durchhält.

Die Frontend-First-Alternative: Risikosenkung als Phase 1

Option B dreht die Reihenfolge um: Das Frontend wird zuerst entkoppelt, das Backend kommt danach.

Was ist ein entkoppeltes Frontend genau?

Ein entkoppeltes Frontend, das auf einer Frontend Management Platform (FMP) läuft, sitzt als eigenständige Schicht über eurem bestehenden Backend. Shopify, Shopware, OXID, Magento, commercetools. Ihr behaltet das Backend wie es ist. Das neue Frontend spricht via API mit dem bestehenden System.

Das Ergebnis: Ihr renoviert das Haus, ohne das Fundament anzufassen.

Was Frontend-First bringt

Phase 1 (Wochen 1-10): Frontend entkoppeln

• Neues Storefront auf Composable-Basis läuft live, Backend unverändert.
• Marketing-Teams können Kampagnen-Pages, Produktwelten und Saisonaktionen eigenständig verwalten, ohne Entwickler-Tickets.
• Performance-Gewinn sofort messbar: Typische Werte nach Frontend-Entkopplung sind LCP unter 1,5 Sekunden statt 3-4 Sekunden vorher. Das zieht Conversion-Raten mit.
• SEO-Kontinuität: URL-Struktur bleibt unverändert, da das Backend-Routing nicht angefasst wird.

Phase 2 (nach erfolgreichem Frontend-Launch): Backend wechseln

• Ihr wählt das Backend nun unter anderen Vorzeichen: Das Frontend ist unabhängig, der Cut-over des Backends ist kein Relaunch mehr, sondern ein Connector-Wechsel.
• Kein Zeitdruck auf das neue Frontend-Design, weil das Frontend schon live und stabil ist.
• Parallele Betriebskosten sinken: Das Altsystem-Frontend ist weg, das neue Frontend trägt die Last.

Was Frontend-First kostet und welche Risiken bleiben

Ehrlich gesagt: Frontend-First ist nicht ohne Herausforderungen.

• Doppelte Datenpflege in der Übergangsphase: Solange das alte Backend läuft, pflegt ihr Produkt- und Preisdaten dort. Das ändert sich erst mit Phase 2.
• Parallele Phasen-Komplexität: Wenn Phase 2 (Backend-Wechsel) startet, bevor Phase 1 vollständig konsolidiert ist, steigt die Koordinationskomplexität. Klare Meilensteine und ein Go/No-Go-Gate zwischen Phase 1 und Phase 2 sind Pflicht.
• Abhängigkeit von API-Qualität des Altsystems: Wenn euer bestehendes Backend schlechte oder instabile APIs liefert, ist die Entkopplung schwieriger. Das ist vorab zu prüfen.

Entscheidungsrahmen: Wann Option A, wann Option B?

Nicht jedes Unternehmen passt zum gleichen Sequencing. Hier sind die Kriterien, die die Entscheidung tragen:

Option A (Backend-First) ist besser geeignet, wenn:

• Euer Backend ist fundamental kaputt (Datenverluste, keine API-Fähigkeit, EOL-System ohne Support)
• Ihr habt eine klare 18-Monats-Runway im Budget, inklusive paralleler Betriebskosten
• Das Frontend-Erlebnis ist für euch heute kein Wettbewerbs-Nachteil (B2B-Catalog-Reorder, kein Conversion-Druck)
• Euer Team hat starke Backend-Kompetenz und begrenzte Frontend-Kapazität

Option B (Frontend-First) ist besser geeignet, wenn:

• Euer Backend ist stabil, aber das Storefront ist veraltet oder zu starr für Marketing-Anforderungen
• Ihr braucht sichtbare Ergebnisse innerhalb von 3 Monaten, nicht 18 (interne Stakeholder, Budgetgenehmigung)
• Euer Replatforming-Budget ist begrenzt und muss in Phasen investiert werden
• SEO ist ein relevanter Kanal (Frontend-First schützt URL-Struktur und Rankings besser)
• Ihr wollt das Backend-Risiko trennen: Wenn Phase 2 komplizierter wird als erwartet, habt ihr mit Phase 1 schon substantiellen Wert geliefert

TCO-Perspektive: Was kostet welche Reihenfolge über 3-5 Jahre?

Die meisten Replatforming-Kalkulationen rechnen den Erstaufwand. Die relevante Zahl ist aber der Total Cost of Ownership über 3-5 Jahre.

Backend-First-Szenario (typisch Mid-Market):

• Laufende Altsystem-Kosten während Backend-Umbau: 9-18 Monate volles Lizenz- und Hosting-Budget
• Frontend-Build unter Zeitdruck nach Backend-Go-Live: Oft 20-30% höhere Entwicklungskosten wegen fehlender Vorlaufplanung
• SEO-Recovery-Zeit nach schlecht geplantem Cutover: 3-6 Monate mit reduziertem organischen Traffic

Frontend-First-Szenario mit FMP:

• Phase 1 liefert innerhalb von 8-12 Wochen ein produktives neues Storefront
• Altsystem-Backend wird weiter betrieben, aber das teure Frontend-Hosting und die Frontend-Entwicklungskosten entfallen ab Phase-1-Go-Live
• Phase 2 (Backend-Wechsel) startet ohne Zeitdruck, da das Frontend bereits steht
• TCO-Vorteil über 3 Jahre: je nach Stack und Komplexität typischerweise 25-40% geringer als Backend-First-Big-Bang

Diese Zahlen sind keine Garantie. Jedes Projekt ist anders. Aber die Logik trägt: Wer Phase 1 (Frontend) schnell abschließt, spart parallele Doppelkosten und senkt das Abort-Risiko des Gesamtprojekts.

Der empfohlene Entscheidungspfad für den Mid-Market

Wenn ihr heute mit 5 bis 50 Millionen Euro Jahresumsatz operiert und euer Replatforming plant, ist dies der Pfad, den wir in der Praxis am häufigsten erfolgreich sehen:

Schritt 1: Backend-Readiness-Check (2-4 Wochen)

Prüft, ob euer bestehendes Backend API-fähig ist. Die meisten Shopware-, Shopify-, OXID- und Magento-Systeme sind es. Wenn ja, ist Frontend-First sofort möglich.

Schritt 2: Phase 1 Frontend-Entkopplung (6-12 Wochen)

Neues Storefront auf Composable-Basis via API auf bestehendem Backend. Go-Live mit vollem Marketing-Control. Kein Backend-Risiko.

Schritt 3: Konsolidierung und Bewertung (4-8 Wochen)

Neues Frontend ist live. Ihr messt Conversion-Entwicklung, SEO-Performance und Marketing-Velocity. Erst wenn Phase 1 stabil ist, entscheidet ihr, wann und ob Phase 2 startet.

Schritt 4: Phase 2 Backend-Wechsel (nach eigenem Zeitplan)

Mit einem stabilen Frontend im Rücken ist der Backend-Wechsel ein Connector-Tausch, kein Relaunch. Zeitdruck ist weg, das Risiko ist isoliert.

Was ihr als nächstes tun könnt

Replatforming-Entscheidungen sind keine Einzel-Sprint-Projekte. Aber die Sequencing-Frage ist lösbar, wenn ihr sie früh stellt.

Wenn ihr euer bestehendes Headless Frontend bewerten oder euren Composable-Commerce-Pfad strukturieren wollt, lohnt sich ein Blick auf die Laioutr UI Platform, die genau für dieses Sequencing gebaut ist: Frontend entkoppeln, ohne Backend anzufassen.

Wer den Schritt von bestehenden Investitionen zu Composable planen will, findet in diesem Insights-Artikel einen verwandten Ausgangspunkt: Bestehende Investitionen sichern bei der Composable-Migration.

Verwandte Ressourcen:

• Headless Frontend Hub
• Laioutr UI Platform
• Composable Headless Frontend
• Was ist eine Frontend Management Platform?
• Bestehende Investitionen bei der Composable-Migration sichern