BFSG Ein-Jahr-Bilanz: Welche Lücken Shops jetzt schließenSeit dem 28. Juni 2025 ist das Barrierefrei…
Composable Migration für SFCC: Frontend modernisieren ohne Backend Replatforming
Wenn ein SFCC Customer heute über Composable Commerce nachdenkt, taucht in der ersten Vendor Diskussion fast immer der gleiche Vorschlag auf. Wir tauschen alles aus, neues Backend, neues Frontend, neue Services. Eine vollständig neue Plattform innerhalb von zwei Jahren. Dieser Ansatz ist verlockend, weil er einfach klingt. In der Praxis ist er gleichzeitig der teuerste und der riskanteste Pfad. Es gibt einen pragmatischeren Weg, den die meisten erfolgreichen SFCC Composable Projekte 2026 nutzen. Frontend zuerst. Backend bleibt stehen. Dieser Beitrag zeigt, warum dieser Weg funktioniert und wie er konkret aussieht.
Was die meisten Vendor Pitches verschweigen
Die volle Plattform Migration verspricht einen sauberen Neustart. In der Realität bedeutet sie aber drei Dinge gleichzeitig. Erstens, Sie ersetzen den Backend Backbone für Orders, Pricing, Promotion und Customer Data. Zweitens, Sie ersetzen das Frontend. Drittens, Sie bauen Integrationen zu CRM, ERP und Fulfillment neu auf.
Diese drei Operationen parallel zu fahren überfordert fast jedes Enterprise Team. Migrationszeiträume von achtzehn bis dreißig Monaten sind realistisch. In dieser Zeit liegen Conversion Optimierungen, neue Funnel Tests und Customer Experience Verbesserungen auf Eis. Wettbewerber gewinnen Markt, weil Ihr Team in einer Implementierungsschleife steckt.
Studien zeigen außerdem, dass über die Hälfte der SFCC Nutzer mit den Core Funktionen der Plattform zufrieden sind. Vor allem Checkout und Payment funktionieren gut. Es wäre wirtschaftlich falsch, diese Komponenten auszutauschen, nur um die Schwächen im Frontend zu beheben.
Die Logik von Frontend zuerst
Die Mehrheit der Schmerzpunkte bei SFCC liegt im Frontend. Nicht zufrieden mit User Experience, Mobile Performance, Personalization. Das sind alles Themen, die der Customer im Frontend erlebt. Das Backend ist robust genug, um weiterzulaufen.
Frontend zuerst bedeutet, dass Sie die schwächste Schicht zuerst modernisieren. Sie führen eine moderne Frontend Plattform ein, die SFCC als Backbone weiternutzt. Marketing Teams gewinnen Geschwindigkeit, Customer sehen ein modernes Erlebnis, Engineering arbeitet an Plattform Pflege statt an Wartung einer alten Codebase.
Erst wenn diese Phase stabil läuft, können Sie weitere Schichten composable machen. Search durch Algolia oder Constructor ersetzen. Recommendations durch Bloomreach oder Dynamic Yield ergänzen. CMS auf Contentful, Storyblok oder Hygraph migrieren. Jede dieser Bewegungen erfolgt einzeln, mit klaren Erfolgsmetriken.
Die fünf Phasen einer sauberen Migration
Erfolgreiche SFCC Frontend Migrationen folgen einem klaren Muster.
Phase 1: Audit und Slicing
Sie zerlegen die heutige Storefront in funktionale Bereiche. Homepage und Landingpages, Produktkatalog, Produktdetail, Account, Checkout. Pro Bereich notieren Sie zwei Werte. Wie wichtig ist dieser Bereich für Revenue? Wie hoch ist die Komplexität in der aktuellen Codebase? Aus dieser Matrix entsteht die Migrationsreihenfolge.
Phase 2: Unified Data Layer
Sie etablieren eine Datenschicht, die das neue Frontend mit dem SFCC Backend verbindet. Diese Schicht abstrahiert Produkt, Pricing, Cart und Customer APIs. Sie wird zur einzigen Brücke zwischen alt und neu. Damit verhindern Sie, dass das neue Frontend direkt an alte Schnittstellen klebt.
Phase 3: Erste Bereiche live
Sie migrieren die Bereiche mit dem besten Verhältnis aus Wirkung und Risiko. Häufig sind das Landingpages und Kampagnenflächen. Das neue Frontend läuft parallel zum bestehenden Setup, üblicherweise per Path Splitting. Sie ernten erste Performance Wins ohne den Checkout zu berühren.
Phase 4: Hauptkatalog
Produktlistings und Produktdetailseiten folgen. Hier entstehen die größten Mobile Conversion Effekte. Zeitgleich werden Best of Breed Services für Search und Recommendations angebunden, die SFCC nie elegant bedienen konnte.
Phase 5: Checkout und Account
Den Checkout migrieren Sie zuletzt. Hier liegt das höchste Risiko, deshalb braucht er die Stabilisierungszeit der vorherigen Phasen. Wenn der Checkout sicher auf der neuen Plattform läuft, ist die Migration abgeschlossen.
Realistische Zeitachse
In der Praxis lässt sich diese Migration in zwölf bis fünfzehn Monaten umsetzen, abhängig von Komplexität und Anzahl der Storefronts. Erste produktive Bereiche sind häufig nach drei bis vier Monaten live. Der Aufwand verteilt sich auf wenige Engineers, weil viele Plattformaufgaben durch eine Frontend as a Service Lösung abgedeckt werden.
Wichtig ist, dass die Business KPIs sich nicht erst nach dem letzten Schritt verbessern. Mobile Performance Wins zeigen sich oft direkt mit dem ersten migrierten Bereich. Conversion Effekte aus Personalization beginnen, sobald der Hauptkatalog läuft.
Was Sie vermeiden sollten
Drei Fehler sehen wir wiederholt.
Erstens, Big Bang Migration. Wer alles gleichzeitig austauschen will, bindet das Team über ein Jahr ohne Zwischenergebnisse.
Zweitens, paralleles Backend Replatforming. Das verdoppelt das Risiko ohne dass die Customer einen Mehrwert sehen, der diese Doppelinvestition rechtfertigt.
Drittens, Verzicht auf einen Unified Data Layer. Wer das neue Frontend direkt an die alten Schnittstellen koppelt, baut die nächste Erblast in den ersten Sprint ein.
Fazit
SFCC Customer brauchen keinen Komplettwechsel, um Composable zu werden. Eine sauber strukturierte Frontend Migration auf eine moderne Plattform liefert den Großteil des Composable Vorteils, ohne dass das funktionierende Backend angefasst wird. Sie behalten die zufriedenstellenden Core Funktionen, lösen die echten Engpässe und gewinnen ein Frontend, das Sie in den nächsten Jahren ohne Refactoring Marathons weiterentwickeln können.
Wenn Sie wissen wollen, wie eine solche Migration für Ihr Setup konkret aussieht, sprechen Sie uns an. Wir haben dieses Muster mehrfach erfolgreich umgesetzt und können Ihnen einen realistischen Plan auf Basis Ihrer Storefront skizzieren.