In jedem Composable Vendor Pitch tauchen die gleichen Versprechen auf. Bessere Customer Experience, …
Composable Commerce Migration: Vom Monolith zur MACH-Architektur
Viele Unternehmen stehen heute vor derselben Herausforderung: Ihr bestehendes E-Commerce-System ist historisch gewachsen, eng verzahnt und kaum noch flexibel erweiterbar. Neue Features dauern Monate statt Wochen, Deployments sind risikoreich, und das Entwicklungsteam verbringt mehr Zeit mit dem Umgehen technischer Schulden als mit echter Produktentwicklung. Die Lösung liegt auf der Hand: eine Composable Commerce Migration hin zu einer modernen MACH-Architektur. Doch wie geht man das strategisch an, ohne den laufenden Betrieb zu gefährden?
Dieser Beitrag richtet sich an CTOs, Tech Leads und E-Commerce-Entscheider, die den Schritt in Richtung Composable Commerce planen oder bereits erste Schritte unternommen haben.
Was ist Composable Commerce und warum ist MACH der Standard?
Composable Commerce beschreibt einen Architekturansatz, bei dem ein E-Commerce-System nicht aus einer monolithischen Plattform besteht, sondern aus lose gekoppelten, austauschbaren Bausteinen zusammengesetzt wird. Jede Komponente erfüllt eine spezifische Funktion und kommuniziert über standardisierte APIs mit den anderen Teilen des Systems.
MACH steht für Microservices, API-first, Cloud-native und Headless. Diese vier Prinzipien bilden das technische Fundament moderner E-Commerce-Architekturen. Während frühere Systeme wie Magento, OXID oder hybris auf engem Coupling und proprietären Erweiterungskonzepten basierten, ermöglicht MACH echte Modularität: Ein Shop kann das beste verfügbare Tool für jede Funktion nutzen, sei es für Suche, Checkout, PIM oder CMS, ohne an einen einzigen Anbieter gebunden zu sein.
Laut aktuellen Marktdaten haben bis 2026 über 73 Prozent aller mittleren und großen E-Commerce-Unternehmen zumindest Teile ihrer Architektur auf Headless- oder MACH-Prinzipien umgestellt. Der Grund: Unternehmen, die auf Composable Commerce setzen, berichten von bis zu 80 Prozent schnelleren Deployment-Zyklen und signifikant höheren Conversion Rates.
Warum der Big-Bang-Ansatz scheitert
Ein häufiger Fehler bei der Composable Commerce Migration ist der Versuch, das gesamte System auf einmal zu ersetzen. Der sogenannte Big-Bang-Ansatz verspricht zwar eine saubere Trennung von Alt und Neu, bringt in der Praxis aber enorme Risiken mit sich.
Erstens unterschätzen Projektteams regelmäßig den Umfang des bestehenden Systems. Monolithen enthalten über Jahre gewachsene Geschäftslogik, die nirgendwo dokumentiert ist. Zweitens sind die Auswirkungen auf den laufenden Betrieb erheblich: Ein paralleles System aufzubauen, das identisch funktioniert, bindet massive Ressourcen. Drittens steigt die Komplexität des Projekts exponentiell, je mehr Komponenten gleichzeitig migriert werden.
Die Erfahrung aus zahlreichen Migrationsprojekten zeigt: Wer den Wandel als Transformation versteht, nicht als einmaligen Relaunch, ist langfristig erfolgreicher.
Der Strangler-Fig-Pattern: Migration ohne Risiko
Das empfohlene Vorgehen für eine Composable Commerce Migration ist das sogenannte Strangler-Fig-Pattern. Der Begriff leitet sich von einer Pflanzenart ab, die sich langsam um einen alten Baum windet und ihn schrittweise ersetzt, während der Baum noch steht und Früchte trägt.
Konkret bedeutet das: Das neue, composable System wächst parallel zum bestehenden Monolithen. Einzelne Funktionen werden sukzessive aus dem Monolithen herausgelöst und als eigenständige Services neu implementiert. Ein API-Gateway oder ein Reverse Proxy steuert, welche Anfragen an das alte und welche an das neue System weitergeleitet werden.
Für eine typische E-Commerce-Plattform bietet sich folgende Migrationsreihenfolge an:
Zunächst wird der Frontend-Layer herausgelöst. Das Headless-Frontend (z.B. basierend auf Next.js oder Nuxt.js) übernimmt die Darstellung, während das Backend noch der bestehende Monolith ist. Diese Phase ist vergleichsweise risikoarm, da die Geschäftslogik unberührt bleibt.
Im zweiten Schritt wird das Content-Management entkoppelt. Ein Headless CMS wie Contentful, Storyblok oder Sanity übernimmt die Verwaltung von Seiteninhalten, Kampagnen und Produktbeschreibungen. Diese Systeme sind API-first ausgelegt und lassen sich unkompliziert in das neue Frontend integrieren.
Danach folgt die Produktdatenverwaltung. Ein dediziertes PIM-System (Product Information Management) übernimmt die strukturierten Produktdaten und versorgt sowohl das neue Frontend als auch nachgelagerte Kanäle wie Marktplätze oder ERP-Systeme.
In einem weiteren Schritt wird die Suchlösung modernisiert. Algolia, Elasticsearch oder commercetools Search ersetzen die oft schwache Suchfunktion des Monolithen und bieten sofortige Verbesserungen in Relevanz und Performance.
Der schwierigste Schritt ist üblicherweise die Migration des Checkouts und der Order-Management-Logik. Hier liegt das Herzstück des Businesses, und entsprechend komplex sind Abhängigkeiten zu Zahlungsdienstleistern, Logistikanbietern und ERP-Systemen. Headless-Commerce-Engines wie commercetools, Medusa.js oder SCAYLE bieten hierfür spezialisierte Lösungen.
Technische Voraussetzungen für eine erfolgreiche Migration
Bevor die erste Komponente migriert wird, müssen bestimmte technische Grundlagen geschaffen werden.
API-Layer und Dokumentation: Der bestehende Monolith muss, sofern nicht bereits vorhanden, über eine strukturierte API angesprochen werden können. In vielen Legacy-Systemen ist dies nur durch die Entwicklung eines Adapters möglich.
Event-Driven Architecture: Für den parallelen Betrieb von Alt und Neu braucht es einen zuverlässigen Mechanismus zur Datensynchronisation. Event-Streams (z.B. via Kafka oder AWS EventBridge) stellen sicher, dass Bestellungen, Lagerbestände und Kundendaten konsistent über beide Systeme hinweg aktuell sind.
Observability und Monitoring: Mit zunehmender Anzahl von Microservices steigt die Notwendigkeit, das Gesamtsystem überwachen zu können. Distributed Tracing (z.B. mit OpenTelemetry), strukturiertes Logging und Alerting sind keine optionalen Nice-to-haves, sondern betriebsnotwendige Infrastruktur.
CI/CD-Pipelines: Composable Commerce lebt von schnellen Deployments. Ohne automatisierte Test- und Deployment-Pipelines wird die Geschwindigkeit, die die neue Architektur verspricht, nicht realisierbar sein.
Häufige Stolpersteine und wie man sie vermeidet
Auch mit dem besten Migrationsplan gibt es typische Fallstricke, die immer wieder zu Verzögerungen und erhöhten Kosten führen.
Fehlende Ownership: In Composable-Commerce-Projekten verteilt sich die Verantwortung auf viele Teams und Systeme. Ohne klare Service-Ownership und definierte SLAs entstehen Reibungsverluste, die das Tempo bremsen.
Vendor-Lock-in durch das Backdoor: MACH soll Flexibilität bringen, aber zu tiefe proprietäre Integrationen mit einem einzigen Anbieter können diesen Vorteil wieder zunichte machen. Eine API-Abstraktionsschicht zwischen eigener Geschäftslogik und externen Services schützt vor späteren Migrationsschmerzen.
Unterschätzung des Frontend-Aufwands: Ein Headless-Frontend ist keine einfache Theme-Anpassung. Die Entwicklung einer performanten, SEO-freundlichen Frontend-Applikation, die Anbindung an mehrere Backend-Services und die Umsetzung von A/B-Testing, Personalisierung und Analytics erfordert ein erfahrenes Engineering-Team und sorgfältige Planung.
Mangelnde Stakeholder-Kommunikation: Composable-Commerce-Projekte sind keine rein technischen Vorhaben. Marketing, E-Commerce-Management und Produktteams müssen frühzeitig eingebunden werden, da sich Workflows, CMS-Strukturen und Deployment-Prozesse grundlegend verändern.
Erfolgsmessung: Welche KPIs wirklich zählen
Eine Composable Commerce Migration ist eine erhebliche Investition. Um den Erfolg messbar zu machen, empfiehlt es sich, von Anfang an klare KPIs zu definieren.
Im technischen Bereich sind das: Time-to-Deployment (wie lange dauert es, ein neues Feature zu deployen?), Core Web Vitals (insbesondere LCP, CLS und INP), API-Latenz und Fehlerrate sowie Systemverfügbarkeit.
Im geschäftlichen Bereich sind relevante Metriken: Conversion Rate im Vergleich zur Referenzperiode, Bounce Rate, Seitengeschwindigkeit und ihre Auswirkung auf SEO-Rankings sowie die Time-to-Market für neue Features und Kampagnen.
Viele Unternehmen stellen nach einer erfolgreichen Migration fest, dass die Verbesserungen in der Developer Experience sich direkt auf die Innovationsgeschwindigkeit auswirken: Teams, die früher Monate auf ein Feature-Release warten mussten, deployen plötzlich mehrfach pro Woche.
Roadmap: Ein realistischer Zeithorizont
Wie lange dauert eine Composable Commerce Migration? Die ehrliche Antwort lautet: Es kommt darauf an. Für ein mittelständisches Unternehmen mit einem gewachsenen Monolithen und einem Team von 5 bis 10 Entwicklerinnen und Entwicklern ist ein Zeitraum von 12 bis 24 Monaten realistisch, um alle wesentlichen Komponenten zu migrieren.
Wichtig ist zu verstehen, dass "fertig" bei Composable Commerce kein fixer Zustand ist. Die Architektur ist darauf ausgelegt, kontinuierlich weiterentwickelt zu werden. Einzelne Services werden durch bessere Alternativen ersetzt, neue Kanäle werden angebunden, und die Plattform wächst mit den Anforderungen des Businesses.
Die erste Phase, also die Herauslösung des Frontends und des CMS, lässt sich bei guter Vorbereitung oft in drei bis sechs Monaten abschließen und liefert bereits sichtbare Ergebnisse in Form von verbesserter Performance und schnelleren Content-Deployments.
Fazit
Die Composable Commerce Migration ist kein Sprint, sondern ein Marathon. Wer sie strategisch angeht, inkrementell vorgeht und auf bewährte Patterns wie den Strangler-Fig-Ansatz setzt, minimiert Risiken und sieht schnell die ersten Ergebnisse. Die technischen Grundlagen, ein solider API-Layer, Event-Driven Architecture und starke CI/CD-Pipelines, sind dabei ebenso entscheidend wie die Einbindung aller relevanten Stakeholder.
Unternehmen, die den Schritt wagen, berichten unisono: Die Investition zahlt sich aus. Nicht nur in Form von besserer Performance und höheren Conversion Rates, sondern vor allem in der wiedergewonnenen Fähigkeit, schnell auf Marktveränderungen reagieren zu können.