Diese Woche bringt zwei Ereignisse auf einmal: Storyblok hält heute (30. Juni, 15:00 Uhr CET) sein &…
Composable Commerce Migration: Schritt für Schritt vom Monolithen zur modernen Architektur
Die Anforderungen an moderne E-Commerce-Plattformen wachsen schneller, als monolithische Systeme mithalten können. Neue Vertriebskanäle, KI-gestützte Personalisierung und steigende Performance-Erwartungen der Kunden setzen Entscheider unter Druck. Kein Wunder, dass die Composable Commerce Migration für viele CTOs und Tech Leads im DACH-Raum 2026 ganz oben auf der Agenda steht.
Doch eine Migration dieser Tragweite ist kein Schalter, den man umlegt. Sie ist ein strategisches Vorhaben, das sorgfältige Planung, klare Architekturentscheidungen und ein realistisches Verständnis der eigenen Systemlandschaft erfordert. Dieser Beitrag liefert einen praxisnahen Überblick: Was bedeutet Composable Commerce Migration konkret? Welche Phasen durchläuft ein typisches Projekt? Und worauf kommt es an, damit der Wechsel gelingt?
Was ist Composable Commerce und warum ist die Migration so relevant?
Composable Commerce beschreibt einen Architekturansatz, bei dem E-Commerce-Plattformen nicht mehr als monolithische Einheit betrieben werden, sondern aus unabhängigen, austauschbaren Best-of-Breed-Komponenten zusammengesetzt sind. Jede Komponente, ob Produktdatenverwaltung (PIM), Checkout, Suche oder Content Management, kann unabhängig entwickelt, skaliert und ersetzt werden. Die Kommunikation zwischen den Komponenten erfolgt über standardisierte APIs.
Das steht in direktem Kontrast zu klassischen Plattformen wie SAP Commerce, Salesforce Commerce Cloud oder Shopware in seiner monolithischen Ausprägung, bei denen Frontend, Backend und Geschäftslogik eng miteinander verwoben sind. Änderungen in einem Bereich erfordern Tests und Deployments des gesamten Systems, Releases werden zum Risiko, und Innovationsgeschwindigkeit sinkt mit wachsender Systemkomplexität.
Die Zahlen sprechen eine klare Sprache: Laut aktuellen Branchenstudien haben bereits über 90 Prozent der US-amerikanischen E-Commerce-Unternehmen modular-API-getriebene Systeme eingeführt. In Europa, und besonders im DACH-Raum, befindet sich die Adoption in vollem Gange. Unternehmen, die heute nicht anfangen, riskieren morgen den Anschluss zu verlieren.
Der häufigste Fehler: Big-Bang-Migrationen
Bevor wir auf den richtigen Weg eingehen, lohnt es sich, den falschen zu benennen. Viele Unternehmen nähern sich einer Composable Commerce Migration wie einem klassischen Plattformwechsel: alles auf einmal, ein festes Go-live-Datum, dann Umschalten. Dieser Big-Bang-Ansatz ist bei modernen Architekturen besonders riskant.
Die Gründe liegen auf der Hand. Eine Composable-Architektur besteht aus vielen beweglichen Teilen, und jede Abhängigkeit zwischen diesen Teilen muss neu definiert werden. Datenmigration, API-Integration, Frontend-Entwicklung und organisationale Veränderungen laufen parallel. Verzögerungen in einem Bereich blockieren alle anderen. Das Ergebnis sind überzogene Budgets, verpasste Deadlines und frustrierte Teams.
Der bewährte Gegenentwurf ist die inkrementelle Migration: Schritt für Schritt, Domäne für Domäne, mit klaren Rollback-Strategien und messbaren Milestones.
Phasen einer erfolgreichen Composable Commerce Migration
Phase 1: Bestandsaufnahme und Domänenanalyse
Jede erfolgreiche Migration beginnt mit einem ehrlichen Blick auf den Status quo. Was läuft auf dem bestehenden System? Welche Integrationen existieren? Wo liegen die Schmerzen im aktuellen Setup?
Besonders wichtig ist die Domänenanalyse: Die fachlichen Kernbereiche des Unternehmens werden identifiziert und voneinander abgegrenzt. Typische Domänen im E-Commerce sind Produktmanagement, Bestellverwaltung, Kundenkonto, Suche und Empfehlungen, Content und Marketing sowie Checkout und Payment. Jede Domäne wird daraufhin analysiert, welche spezifischen Anforderungen sie hat und wie stark sie aktuell mit anderen Bereichen verknüpft ist.
Das Ergebnis dieser Phase ist eine klare Übersicht der Systemlandschaft und eine priorisierte Roadmap, welche Domänen zuerst herausgelöst werden sollen.
Phase 2: Architekturdesign und Tool-Selektion
Mit der Domänenübersicht in der Hand beginnt die eigentliche Architekturarbeit. Welche Best-of-Breed-Lösungen passen zu welcher Domäne? Composable Commerce bedeutet nicht, dass es eine Einheitslösung gibt. Die Auswahl der richtigen Tools ist entscheidend.
In der Praxis empfiehlt es sich, für jede Domäne einen strukturierten Evaluierungsprozess durchzuführen: Anforderungen definieren, Kandidaten recherchieren, technische Proof-of-Concepts durchführen und Total-Cost-of-Ownership-Berechnungen anstellen. Besonders bei Headless-CMS-Lösungen wie Contentful, Storyblok oder Sanity, bei Commerce-Engines wie commercetools, Elastic Path oder Shopify Plus sowie bei Suchlösungen wie Algolia oder Meilisearch gibt es mittlerweile ein reifes Ökosystem an Enterprise-tauglichen Optionen.
Parallel dazu wird die API-Layer-Architektur definiert. In vielen Projekten hat sich ein API Gateway, ergänzt durch eine Backend-for-Frontend (BFF) Schicht, als robuste Grundlage erwiesen. Der BFF-Layer aggregiert Daten aus mehreren Microservices und liefert optimierte Responses direkt an das Frontend, ohne dass dieses die Komplexität des Backends kennen muss.
Phase 3: Strangler Fig Migration
Das bewährteste Migrationsmuster für Composable Commerce ist das Strangler Fig Pattern. Die Idee: Das alte System bleibt zunächst vollständig in Betrieb. Neue Funktionalitäten und Domänen werden parallel auf der neuen Architektur entwickelt. Schrittweise werden Teile des Traffics auf die neue Infrastruktur umgeleitet, bis das alte System vollständig abgelöst wurde.
In der Praxis sieht das häufig so aus: Zunächst wird die Content-Schicht herausgelöst, da sie in der Regel die geringsten Abhängigkeiten zu Transaktionsdaten hat. Ein Headless CMS übernimmt die Auslieferung von Landingpages, Kategorieseiten und Blogbeiträgen. Das Frontend wird als modernes Framework, etwa Next.js oder Nuxt, neu aufgebaut und erhält seine Daten über APIs.
Im zweiten Schritt folgt häufig die Suche: Eine eigenständige Suchplattform ersetzt die eingebaute Suche des Monolithen und liefert messbar bessere Performance und Relevanz.
Erst wenn Frontend und Suche stabil laufen, wird der kritischste Bereich in Angriff genommen: Checkout, Bestellverwaltung und Kundenkonto. Diese Domänen sind am stärksten mit Datenbankstrukturen, ERP-Systemen und Zahlungsdienstleistern verknüpft und erfordern die sorgfältigste Planung.
Typische Herausforderungen in der Strangler-Fig-Phase
Wer das Muster zum ersten Mal anwendet, stößt auf vorhersehbare Stolpersteine. Die häufigste Herausforderung ist die Session- und Authentifizierungsverwaltung: Wenn Teile einer Plattform auf dem alten System laufen und andere bereits auf der neuen Architektur, müssen Nutzersitzungen konsistent über beide Welten hinweg funktionieren. Hier hat sich ein zentraler Identity Provider, etwa Keycloak oder Auth0, als Bindeglied bewährt.
Ein weiterer Klassiker ist die Datenkonsistenz bei geteilten Domänen. Wenn das Bestandssystem und das neue Commerce-Backend für eine Übergangszeit parallel Produktdaten oder Lagerbestände halten, entstehen unweigerlich Inkonsistenzen. Klare Ownership-Regeln, welches System die "Source of Truth" für welche Daten ist, müssen vor dem Start der parallelen Betriebsphase definiert sein.
Schließlich unterschätzen viele Teams den Aufwand für das interne Routing. Ein Reverse Proxy oder API Gateway, das anhand von URL-Pfaden, Feature Flags oder Nutzerattributen entscheidet, welches Backend eine Anfrage beantwortet, muss robust konfiguriert und sorgfältig überwacht werden.
Phase 4: Daten-Migration und Datenqualität
Ein oft unterschätzter Aspekt jeder Composable Commerce Migration ist die Datenqualität. Jahrelange gewachsene Produktdaten, Kundenkonten und Bestellhistorien müssen strukturiert, bereinigt und auf neue Datenschemata gemappt werden.
Erfahrungsgemäß offenbart jede Datenmigration technische Schulden, die im laufenden Betrieb unsichtbar waren: doppelte Produktattribute, inkonsistente Kategoriestrukturen, fehlende Pflichtfelder im neuen System. Eine frühzeitige Data-Audit-Phase mit klaren Acceptance Criteria für Datenqualität ist kein Nice-to-have, sondern eine Voraussetzung für eine reibungslose Migration.
Technisch haben sich ETL-Pipelines mit Transformations- und Validierungsschritten bewährt. Eine parallele Betriebsphase, in der beide Systeme mit Daten versorgt werden, reduziert das Risiko von Datenverlusten.
Phase 5: Testing, Performance und Go-live
In der Abschlussphase rücken Testing und Performance-Validierung in den Vordergrund. Composable-Architekturen bieten per se bessere Performance, wenn sie korrekt konfiguriert sind. Core Web Vitals, insbesondere Largest Contentful Paint (LCP) und Interaction to Next Paint (INP), sind die relevanten Metriken für die Nutzererfahrung.
End-to-End-Tests über alle integrierten Systeme hinweg, Load Tests für Checkout und API-Endpunkte sowie Monitoring mit Observability-Tools sind unverzichtbar, bevor Traffic auf die neue Architektur umgestellt wird. Feature Flags ermöglichen es, einzelne Nutzergruppen schrittweise auf die neue Plattform zu migrieren und bei Problemen schnell zurückschalten zu können.
Organisationale Veränderungen nicht unterschätzen
Composable Commerce ist nicht nur eine technische, sondern auch eine organisationale Transformation. Klassische Projektstrukturen, bei denen ein zentrales IT-Team die gesamte Plattform verantwortet, passen nicht mehr zu einer dezentralen Microservices-Landschaft.
Moderne Composable-Organisationen arbeiten mit autonomen Produktteams, die jeweils einen oder mehrere Services verantworten. Diese Teams sind cross-funktional, sie kombinieren Entwicklung, Product Management und fachliche Expertise. Sie deployieren eigenständig, ohne auf Release-Zyklen anderer Teams warten zu müssen.
Für Entscheider bedeutet das: Die Investition in Composable Commerce schließt die Investition in neue Arbeitsweisen und Team-Strukturen ein. Wer das ignoriert, wird technisch modern, aber organisationally blockiert.
Was kostet eine Composable Commerce Migration?
Eine pauschale Antwort gibt es nicht, aber einige Orientierungspunkte helfen bei der Einschätzung. Entscheidend sind die Komplexität der bestehenden Systemlandschaft, die Anzahl der zu integrierenden Systeme (ERP, PIM, WMS, CRM), der gewünschte Migrationsumfang sowie die interne Entwicklungskapazität.
Typische Enterprise-Migrationsprojekte im DACH-Raum bewegen sich im Rahmen von sechs bis achtzehn Monaten und erfordern interdisziplinäre Teams aus Solution Architects, Backend-Entwicklern, Frontend-Entwicklern und DevOps-Engineers. Der ROI zeigt sich durch höhere Conversion Rates, schnellere Time-to-Market für neue Features und geringere Betriebskosten durch unabhängig skalierbare Dienste.
Fazit: Migration ist kein Projekt, sondern eine Reise
Composable Commerce Migration ist kein einmaliges Vorhaben mit einem klaren Ende. Es ist der Beginn einer neuen Art, E-Commerce-Technologie zu betreiben: iterativ, modular und kontinuierlich verbesserbar. Unternehmen, die diesen Weg konsequent gehen, gewinnen Agilität, reduzieren technische Schulden und positionieren sich für die nächste Innovationswelle im Commerce, sei es KI-gestützte Personalisierung, Agentic Commerce oder neue Ausgabekanäle.
Die entscheidende Frage ist nicht ob, sondern wie der Umstieg gelingt. Mit der richtigen Strategie, einem inkrementellen Vorgehen und erfahrenen Partnern an der Seite ist der Weg von der Monolith-Welt zur modernen Composable-Architektur planbar und beherrschbar.
Mehr zur Laioutr-Plattform
Mehr dazu: Composable Commerce Platform: Der vollständige Guide für CTOs und Tech-Leader und Von Monolith zu Composable Commerce: Die Schritt-für-Schritt-Migration.