commercetools macht Core Commerce & Product Catalog standalone buchbar: Was das für deine Fronte…
commercetools macht Core Commerce & Product Catalog standalone buchbar: Was das für deine Frontend-Entscheidung bedeutet
commercetools macht Core Commerce & Product Catalog standalone buchbar: Was das für deine Frontend-Entscheidung bedeutet
commercetools bündelt Core Commerce und Product Catalog jetzt als eigenständige, Sphere-basierte Module. Enterprises können einzelne Fähigkeiten dazubuchen, ohne die komplette Plattform zu ersetzen. Für deine Frontend-Entscheidung heißt das: Wird das Backend selbst modular, wird eine ebenso entkoppelte Frontend-Architektur nicht optional, sondern die logische Konsequenz.
Was commercetools angekündigt hat
Am 15. Juli 2026 hat commercetools bestätigt, dass Core Commerce und Product Catalog ab sofort als eigenständige, Sphere-basierte Module buchbar sind, unabhängig von der restlichen Plattform. CEO Doug McNary bringt die Stoßrichtung auf den Punkt: Teams sollen modernisieren können, "ohne ein komplettes Replatforming" durchzuführen. Praktisch bedeutet das: Ein Unternehmen kann zum Beispiel nur das Produktkatalog-Modul adoptieren und den Rest der bestehenden Systemlandschaft unangetastet lassen, statt in ein Alles-oder-nichts-Upgrade gezwungen zu werden.
Das ist eine echte Verschiebung gegenüber dem klassischen commercetools-Pitch der letzten Jahre, der stark auf die komplette MACH-Suite ausgerichtet war. Mit standalone buchbaren Modulen positioniert sich commercetools näher an dem, was Unternehmen in der Realität tun: schrittweise migrieren, einzelne Schmerzpunkte lösen, Risiko in kleinen Schritten abbauen statt in einem 18-Monats-Großprojekt.
Warum das mehr als ein Marketing-Move ist
Modulare Backend-Angebote sind kein neues Konzept, aber die Art, wie commercetools sie hier framt, trifft einen Nerv: Replatforming-Angst ist der größte Bremsblock für Enterprise-Commerce-Entscheidungen. Wenn ein Anbieter glaubwürdig zeigt, dass Adoption in Teilschritten funktioniert, senkt das die Einstiegshürde für genau die Kunden, die bislang gezögert haben, weil "die ganze Plattform wechseln" zu riskant war.
Für Teams, die commercetools bereits nutzen oder erwägen, ist die eigentliche Frage aber nicht "Kann ich das Backend modular kaufen?" Die Frage ist: "Was mache ich mit meinem Frontend, wenn ich das tue?"
Die Kehrseite: Ein modulares Backend braucht eine ebenso flexible Frontend-Schicht
Hier liegt der Haken, den die Ankündigung selbst nicht adressiert. Wenn du Core Commerce oder Product Catalog als eigenständiges Modul adoptierst, aber dein Frontend weiterhin fest an eine einzige, verdrahtete Storefront gebunden ist, gibst du die neu gewonnene Backend-Flexibilität sofort wieder ab. Jede Modul-Erweiterung, jeder zusätzliche Adoptionsschritt zieht dann erneut eine Frontend-Anpassung nach sich, genauso aufwendig wie vorher, nur jetzt häufiger, weil das Backend selbst inkrementeller wird.
Ein Composable Frontend löst genau dieses Problem. Es spricht mit den commercetools-APIs, Core Commerce, Product Catalog oder perspektivisch weiteren Sphere-Modulen, ohne dass die Storefront-Schicht bei jedem neuen Backend-Baustein neu gebaut werden muss. Die Frontend Management Platform (FMP) übernimmt die Rendering-, Performance- und Betriebsebene, während das Backend seine eigene Modernisierungs-Reise in seinem eigenen Tempo gehen kann.
Frontend-Unabhängigkeit als logisches Gegenstück
Die These ist einfach: Inkrementelle Backend-Modernisierung funktioniert nur, wenn das Frontend genauso inkrementell mitziehen kann. Ein Composable Headless Frontend, das unabhängig vom jeweils aktiven commercetools-Modul betrieben wird, macht aus "wir haben jetzt ein Modul mehr adoptiert" ein Konfigurations-Update statt ein Rebuild-Projekt.
Das gilt besonders, wenn Teams commercetools schrittweise neben bestehenden Legacy-Systemen einführen, genau das Szenario, das der Sphere-Modul-Ansatz adressiert. Wer sich näher mit den strategischen Modernisierungsfragen rund um Agentic Storefronts beschäftigt, findet ergänzend unsere Einordnung zu commercetools Sphere und der autonomen Experience-Schicht, in der wir den Agentic-Aspekt der Sphere-Architektur separat einordnen, unabhängig von der hier beschriebenen Modularisierungs-Strategie.
Für wen das jetzt konkret relevant wird
Drei Team-Konstellationen profitieren am direktesten von dieser Klarheit: Enterprises, die commercetools bereits einsetzen und jetzt einzelne Module gezielt erweitern wollen, ohne den Rest der Systemlandschaft anzufassen. Mid-Market-Teams in DACH, die commercetools als Zielplattform evaluieren und die Modul-Ankündigung als Argument gegen ein 18-Monats-Großprojekt werten. Und Teams, die aktuell auf einem Legacy-Monolithen sitzen und die Sphere-Module als schrittweisen Einstieg nutzen wollen, statt in einem einzigen Big-Bang-Replatforming zu wechseln. In allen drei Fällen entscheidet die Frontend-Architektur mit, ob die neue Backend-Flexibilität tatsächlich ankommt oder in der Storefront-Schicht wieder verloren geht.
Was sich für dein Team ändert
| Szenario | Backend-Flexibilität | Frontend-Realität |
|---|---|---|
| Modulares Backend, monolithisches Frontend | Hoch, einzelne Module buchbar | Niedrig, jede neue Modul-Adoption zieht einen Frontend-Umbau nach sich |
| Modulares Backend, Composable Frontend | Hoch, einzelne Module buchbar | Hoch, Frontend bleibt stabil, Backend-Module werden angebunden statt neu gebaut |
| Klassisches Alles-oder-nichts-Backend | Niedrig, Komplett-Replatform nötig | Abhängig vom Frontend-Setup, Modernisierung insgesamt langsamer |
FAQ
Was genau ist an Core Commerce und Product Catalog standalone buchbar? Beide sind jetzt als eigenständige, Sphere-basierte Module verfügbar, die Unternehmen unabhängig von der restlichen commercetools-Plattform adoptieren können, ohne ein vollständiges Replatforming.
Muss ich mein Frontend wechseln, wenn ich ein neues commercetools-Modul adoptiere? Nicht zwingend, aber nur, wenn dein Frontend bereits entkoppelt ist. Ist es fest an eine bestehende Storefront gebunden, zieht jede neue Modul-Adoption in der Praxis auch Frontend-Anpassungen nach sich.
Wie schnell lässt sich ein Composable Frontend an ein neues commercetools-Modul anbinden? Typisch sind wenige Wochen statt Monate, weil die Storefront-Schicht bereits API-first gegen commercetools spricht und ein neues Modul in der Regel nur einen zusätzlichen Datenquellen-Anschluss braucht, keinen Rebuild.
Was unterscheidet diesen Beitrag von euren anderen commercetools-Artikeln? Unsere Einordnung zur autonomen Experience-Schicht behandelt die Agentic-/KI-Seite von Sphere. Dieser Beitrag behandelt die neue Adoptions- und Modularisierungs-Strategie, ein anderes Thema auf derselben Backend-Basis.
Nächste Schritte
Wenn dein Team über die Adoption einzelner commercetools-Module nachdenkt, lohnt sich der Blick auf die Frontend-Seite, bevor der erste Modul-Vertrag unterschrieben ist. Sieh dir an, wie ein Composable Frontend für commercetools aussieht oder buch ein Gespräch, in dem wir das an eurem konkreten Modul-Fahrplan durchgehen.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr. Er begleitet Enterprise- und Mid-Market-Teams in DACH dabei, Backend-Modernisierung, commercetools, Adobe Commerce und andere MACH-Plattformen, von der Frontend-Seite her abzusichern, damit neu gewonnene Backend-Flexibilität nicht sofort wieder an eine starre Storefront gebunden wird.
*Alle Daten basieren auf öffentlich verfügbaren Informationen (u. a. commercetools-Ankündigung vom 15.07.2026, verifiziert über AOL, Yahoo Finance, EnterpriseTimes und MarTechCube), Erfahrungen aus Sales-Gesprächen mit DACH-E-Commerce-Brands sowie eigenen Plattform-Tests. Stand: Juli 2026. commercetools-Funktionen können sich weiterentwickelt haben.*