Salesforce Commerce Cloud Frontend 2026: SFRA, PWA Kit, Storefront Next oder FMP-Decoupling?

Für Betreiber von Salesforce Commerce Cloud gab es jahrelang keine echte Frontend-Entscheidung zu treffen. SFRA war der Standard, PWA Kit der komponierbare Upgrade-Pfad für Teams mit eigenem React-Know-how, alles andere Custom-Build. Das änderte sich am 6. Juli 2026, als Storefront Next in die General Availability ging. SFCC-Betreiber haben damit vier eigenständige Wege für die Präsentationsebene, und jeder beantwortet die Fragen, die wirklich zählen, unterschiedlich: Wie hoch ist der Aufwand, wie stark der Lock-in, wie Agent-ready ist der Storefront für KI-Shopping-Agenten, und wie schnell lässt sich die Entscheidung später revidieren.

Dieser Beitrag ist ein Entscheidungsleitfaden, kein Urteil. SFRA, PWA Kit und Storefront Next sind alle drei Salesforce-native Optionen mit echten Trade-offs. Der vierte Pfad, das Entkoppeln des Frontends über eine separate Frontend Management Platform (FMP) bei gleichzeitigem Verbleib von SFCC als Commerce-Backend, ist eine ergänzende Option, die Sie neben den drei anderen kennen sollten, kein Ersatz-Pitch.

Der Entscheidungspunkt 2026 für SFCC-Betreiber

Läuft Ihr Storefront heute auf SFRA, müssen Sie nicht wechseln. Doch drei Dinge haben die Ausgangslage 2026 verändert: die GA von Storefront Next, anhaltender Kostendruck durch die Managed-Runtime-Betriebskosten von PWA-Kit-Deployments, und der wachsende Wunsch von Marketing-Teams nach Launch-Geschwindigkeit, für die serverseitig gerenderte ISML-Templates nie gebaut wurden. Rechnen Sie Agent-Readiness (strukturierte Daten, Schema.org, API-Flächen, die KI-Shopping-Agenten verarbeiten können) als vierten Faktor dazu, haben die meisten SFCC-Betreiber zum ersten Mal seit dem PWA-Kit-Launch wieder eine echte Architektur-Entscheidung auf dem Tisch.

SFRA: der Platzhirsch, weiterhin im Einsatz

SFRA (Storefront Reference Architecture) ist serverseitig gerendert, ISML-templated und tief im Salesforce-Implementierungspartner-Ökosystem verankert. Es ist stabil, gut dokumentiert und günstig zu besetzen. Was es nicht ist: schnell iterierbar. Jede Landingpage oder Kampagnen-Variante läuft über ein Developer-Ticket und eine ISML-Template-Änderung. Für Betreiber mit geringem Frontend-Anspruch und hohem Stabilitätsbedarf bleibt SFRA 2026 eine vertretbare Wahl. Wer Core Web Vitals oder wöchentliche Kampagnen-Kadenz anstrebt, stößt hier an die Decke, nicht an den Boden.

PWA Kit: komponierbar, aber weiterhin Salesforce-eigen

PWA Kit brachte SFCC-Betreibern einen React-basierten Storefront auf Salesforces Managed Runtime. Gegenüber SFRA ist das ein echter Sprung in der Developer Experience, und es hat Betreiber Jahre vor Storefront Next an komponentenbasiertes Frontend-Denken herangeführt. Der Haken: Managed Runtime bleibt eine von Salesforce kontrollierte Hosting-Ebene, die Release-Kadenz hängt am Salesforce-Zyklus, und die Komponierbarkeit ist begrenzt durch das, was Commerce API und Managed Runtime freigeben. Teams, die früh auf PWA Kit gesetzt haben, stellen 2026 zurecht die Frage: War das Composable, oder nur React in einer neuen Verpackung.

Storefront Next: Salesforces neue Antwort (GA 6. Juli 2026)

Storefront Next ist Salesforces bisher direkteste Antwort auf die Reibungspunkte von PWA Kit und lohnt sich als Pilot für Betreiber, die vollständig im Salesforce-Stack bleiben wollen. Zum Zeitpunkt dieses Beitrags ist die Plattform seit knapp drei Wochen generally available, entsprechend dünn sind Produktions-Referenzfälle, die Reife der Migrations-Tools und langfristige Roadmap-Zusagen noch. Storefront Next reduziert einen Teil des operativen Managed-Runtime-Aufwands, den PWA Kit mitbrachte, bleibt aber ein Single-Vendor-Stack: Release-Zyklus, Hosting-Entscheidungen und Erweiterbarkeits-Decke liegen weiterhin bei Salesforce. Das ist ein vertretbarer Trade-off für Betreiber, denen eine Vendor-Beziehung wichtiger ist als Frontend-Unabhängigkeit. Ein Test auf einem unkritischen Storefront-Bereich vor der vollständigen Festlegung ist sinnvoll, allein weil die Plattform neu ist.

Der FMP-Decoupling-Pfad: ein komponierbares Frontend über SFCC

Die vierte Option rührt Ihr SFCC-Backend gar nicht erst an. Commerce API bzw. Open Commerce API bleibt Ihre Commerce-Logik, Ihr Order Management und Ihre Preis-Engine, und Sie entkoppeln die Präsentationsebene über ein dediziertes Headless Frontend für Salesforce Commerce Cloud, das mit SFCC über dessen API spricht, statt in Salesforces Hosting- und Release-Modell zu leben. Das ist das Prinzip hinter unserer Agentic Frontend Management Platform: Das Frontend wird unabhängig deploybar, unabhängig agent-ready und unabhängig upgradebar, während SFCC weiterhin tut, was es als Commerce-Backend gut kann. Dahinter steht Composability & Orchestration, die Daten-Orchestrierungsebene, die SFCCs Commerce API, PIM und OMS ohne Custom-Glue-Code mit dem neuen Frontend synchron hält. Das ist kein Rip-and-Replace von Salesforce, sondern eine Möglichkeit, die zwei Release-Zyklen zu trennen, die Storefront Next und PWA Kit weiterhin bündeln.

Die Optionen im Überblick

• Aufwand zur Einführung. SFRA: Niedrig, bereits im Einsatz. PWA Kit: Mittel-hoch, React-Neubau. Storefront Next: Mittel, neue Plattform, GA Juli 2026. FMP-Decoupling: Mittel, Frontend-Neubau, Backend unangetastet.
• Vendor-Lock-in. SFRA: Hoch, ISML + Salesforce-Hosting. PWA Kit: Mittel-hoch, Managed Runtime erforderlich. Storefront Next: Hoch, Single-Vendor-Stack. FMP-Decoupling: Niedrig, backend-agnostische Frontend-Ebene.
• Agent-Readiness. SFRA: Niedrig, begrenzte Kontrolle über strukturierte Daten. PWA Kit: Mittel. Storefront Next: Unklar, noch zu neu zur Prüfung. FMP-Decoupling: Hoch, API-first gebaut mit Schema.org-Unterstützung.
• Wer den Release-Zyklus kontrolliert. SFRA: Salesforce-Release-Zyklus + SI-Partner. PWA Kit: Salesforce Managed Runtime. Storefront Next: Salesforce-Roadmap. FMP-Decoupling: Betreiber + gewählter Frontend-Anbieter.
• Zeit für einen späteren Kurswechsel. SFRA: Langsam, eng gekoppelt. PWA Kit: Mittel. Storefront Next: Noch unbekannt. FMP-Decoupling: Schnell, Frontend und Backend entkoppelt.

Was das für SFCC-Betreiber bedeutet

• Läuft Ihr Storefront stabil auf SFRA und ist Ihr Frontend-Anspruch gering, besteht 2026 kein dringender Handlungsbedarf. Prüfen Sie neu, sobald Kampagnen-Geschwindigkeit oder Core Web Vitals zum Geschäftsproblem werden, nicht davor.
• Nutzen Sie PWA Kit und stören sich an Managed-Runtime-Kosten oder Release-Reibung, bewerten Sie Storefront Next und ein FMP-Decoupling nebeneinander, bevor Sie sich festlegen.
• Prüfen Sie Storefront Next, pilotieren Sie zunächst auf einem einzelnen Storefront-Bereich. Drei Wochen GA-Historie reichen nicht, um ein vollständiges Replatforming darauf zu setzen.
• Ist Agent-Readiness (strukturierte Produktdaten, Schema.org, API-first-Architektur für KI-Shopping-Agenten) eine Priorität für 2026/2027, wägen Sie das explizit ab. Hier unterscheiden sich die vier Optionen am stärksten.
• Wollen Sie SFCC dauerhaft als Commerce-Backend behalten, aber die Frontend-Release-Zyklen von Salesforces Roadmap entkoppeln, ist der FMP-Pfad genau für diese Anforderung gebaut.

FAQ

Ist Storefront Next ein Ersatz für PWA Kit? Salesforce positioniert es als die neuere Frontend-Option für SFCC, PWA Kit ist zum Zeitpunkt dieses Beitrags aber nicht deprecated. Wer heute auf PWA Kit läuft, kann dort bleiben; für Neubauten ist Storefront Next der naheliegendere erste Test.

Müssen wir von SFCC weg migrieren, um eine Frontend Management Platform zu nutzen? Nein. Der FMP-Decoupling-Pfad behält SFCC als Commerce-Backend über dessen Commerce API bei. Nur die Präsentationsebene wandert auf ein separates, unabhängig deploybares Frontend.

Wie ausgereift ist Storefront Next aktuell? Die Plattform ging am 6. Juli 2026 in die General Availability. Mit drei Wochen Historie ist mit dünner Third-Party-Tooling-Landschaft, wenigen öffentlichen Migrations-Fallstudien und einer noch reifenden Roadmap zu rechnen. Behandeln Sie Storefront Next als starken Pilot-Kandidaten, noch nicht als Standardwahl für ein vollständiges Replatforming.

Welche Option lässt sich am schnellsten korrigieren, falls die Wahl falsch war? Ein FMP-Decoupling, weil Frontend- und Backend-Release-Zyklen bereits getrennt sind. SFRA lässt sich am langsamsten ändern, weil ISML-Templates und Hosting eng an den Salesforce-Release-Zyklus gekoppelt sind.