5 Herausforderungen bei der Migration vom SAP Commerce Accelerator zum Composable Storefront
Seit Jahren ist SAP Accelerator-basierter Commerce (ACC) das Arbeitspferd hinter vielen Enterprise-Commerce-Plattformen. Doch da digitale Erlebnisse zunehmend mehr Agilität und Personalisierung erfordern, wagen immer mehr Unternehmen den Schritt zum SAP Composable Storefront (ehemals Spartacus).
Der Umstieg verspricht Flexibilität, Skalierbarkeit und eine zukunftssichere Architektur – dennoch ist die Migrations alles andere als Plug-and-Play. Basierend auf den Erkenntnissen unserer Entwickler, die komplexe Migrationsprojekte geleitet haben, sind dies die fünf größten Herausforderungen, auf die sich Unternehmen beim Wechsel vom Accelerator zum Composable Storefront vorbereiten sollten.
1. Erhöhte API-Abhängigkeiten
Mit ACC übernahmen serverseitige JSPs und Templates einen Großteil der Storefront-Logik. Das Composable Storefront verändert es komplett: Als vollständig entkoppeltes Frontend stützt es sich für nahezu jede Datenkomponente auf die OCC REST APIs.
Dieser Wandel bringt Vorteile in Modularität und Headless-Integration. Dennoch erfordert er auch die Aktivierung neuer APIs, die Optimierung bestehender sowie das Schließen von Lücken, wenn das Backend die benötigten Services noch nicht bereitstellt. Für Unternehmen mit Legacy- oder stark angepassten Accelerator-Setups kann das bedeuten, dass ein unerwartet hoher Aufwand an Backend-Engineering notwendig wird, bevor der neue Storefront überhaupt zum Leben erweckt wird.
2. Anpassen und Debuggen von Spartacus-Komponenten
Der Composable Storefront wird mit einer umfangreichen Auswahl an fertigen (Out-of-the-Box, OOTB) Komponenten — ausgeliefert – von Produktlisten bis hin zu Checkout-Flows. Doch wie viele Entwickler festgestellt haben, ist deren Anpassung nicht immer unkompliziert.
Debugging Spartacus kann sich anfühlen wie das Schälen einer Zwiebel: Schichten aus Angular, NgRx und SAP-Logik verschleiern manchmal, wo die eigentliche Änderung vorgenommen werden muss. Das Erweitern von Komponenten oder Überschreiben von Kernverhalten ohne zukünftige Upgrade-Pfade zu gefährden, ist ein Balanceakt. Teams, die von ACC kommen, müssen sich häufig Best Practices für Anpassungen neu aneignen – mit zusätzlichem Fokus auf Wartbarkeit.
2. Anpassen und Debuggen von Spartacus-Komponenten
Der Composable Storefront wird mit einer umfangreichen Auswahl an fertigen (Out-of-the-Box, OOTB) Komponenten — ausgeliefert – von Produktlisten bis hin zu Checkout-Flows. Doch wie viele Entwickler festgestellt haben, ist deren Anpassung nicht immer unkompliziert.
Debugging Spartacus kann sich anfühlen wie das Schälen einer Zwiebel: Schichten aus Angular, NgRx und SAP-Logik verschleiern manchmal, wo die eigentliche Änderung vorgenommen werden muss. Das Erweitern von Komponenten oder Überschreiben von Kernverhalten ohne zukünftige Upgrade-Pfade zu gefährden, ist ein Balanceakt. Teams, die von ACC kommen, müssen sich häufig Best Practices für Anpassungen neu aneignen – mit zusätzlichem Fokus auf Wartbarkeit.
3. Performance, Dateigröße, und Caching-Strategien
Eine der sichtbarsten Veränderungen für Kunden betrifft die Performance. Accelerator-Storefronts werden serverseitig gerendert, während Spartacus als Single Page Application (SPA) zu Beginn ein großes Paket an Skripten und Styles lädt. Das bringt neue Herausforderungen mit sich: Die anfänglichen Seitenaufrufe können langsamer sein. Darüber hinaus wird die Cache-Invalidierung kritisch, und ohne eine robuste Deployment-Strategie sehen Kunden möglicherweise noch lange veraltete Storefronts, nachdem neue Versionen bereits veröffentlicht wurden. Daher ist es entscheidend, Caching, CDN-Strategien und Performance-Tuning richtig umzusetzen – das ist nicht nur ein technisches Detail, sondern ein zentraler Bestandteil für ein reibungsloses digitales Erlebnis.
4. Migration stark angepasster Features
Die meisten Enterprise-Accelerator-Storefronts sind alles andere als „von der Stange“. Im Laufe der Zeit sammeln sie Schichten von Anpassungen an wie Warenkorb-Workflows, Checkout-Anpassungen, Produktkonfiguratoren und Integrationen mit Drittsystemen. Folglich ist der Wiederaufbau dieser Funktionen im Composable Storefront selten eine Eins-zu-eins-Übung. So erfordert zum Beispiel die Migration eines komplexen regelbasierter Produktkonfigurator ein Umdenken bei UI-Typen (Checkboxen, Dropdowns, Bilder), das Management des Zustands über Warenkorb und Checkout hinweg sowie die Integration mit CPQ oder variant configurators. Ähnlich gilt: Die Unterstützung von Punchout-Katalogen, OCI-Integration oder Multi-Recipient-Checkout-Flows bedeutet oft umfangreiches Re-Engineering. Genau deshalb erreichen viele Projekte ihre ressourcenintensivste Phase: Es geht nicht nur darum, Features zu übertragen, sondern sie in einer entkoppelten Architektur neu zu konzipieren.
4. Migration stark angepasster Features
Die meisten Enterprise-Accelerator-Storefronts sind alles andere als „von der Stange“. Im Laufe der Zeit sammeln sie Schichten von Anpassungen an wie Warenkorb-Workflows, Checkout-Anpassungen, Produktkonfiguratoren und Integrationen mit Drittsystemen. Folglich ist der Wiederaufbau dieser Funktionen im Composable Storefront selten eine Eins-zu-eins-Übung. So erfordert zum Beispiel die Migration eines komplexen regelbasierter Produktkonfigurator ein Umdenken bei UI-Typen (Checkboxen, Dropdowns, Bilder), das Management des Zustands über Warenkorb und Checkout hinweg sowie die Integration mit CPQ oder variant configurators. Ähnlich gilt: Die Unterstützung von Punchout-Katalogen, OCI-Integration oder Multi-Recipient-Checkout-Flows bedeutet oft umfangreiches Re-Engineering. Genau deshalb erreichen viele Projekte ihre ressourcenintensivste Phase: Es geht nicht nur darum, Features zu übertragen, sondern sie in einer entkoppelten Architektur neu zu konzipieren.
5. Vorbereitung von SAP-Commerce-Cloud-Umgebungen
Bevor ein einziger Kunde das Storefront zu sehen bekommt, besteht schon einmal die Herausforderung, die Umgebung korrekt aufzusetzen. Spartacus auf der Commerce Cloud zu betreiben, ist nicht immer unkompliziert.
Teams stehen dabei häufig vor zahlreichen Abstimmungen mit dem SAP-Support, müssen zusätzliche Services konfigurieren und alles mit den CI/CD-Pipelines in Einklang bringen. Das Einrichten neuer Spartacus-Instanzen in der Cloud erfordert enge Koordination, gründliches Testen und mitunter viel Geduld. Richtig umgesetzt bildet es jedoch die Grundlage für reibungslosere Releases und bessere Skalierbarkeit.
Fazit: Eine strategische Transformation, nicht nur eine Migration
Der Wechsel von vom SAP Accelerator basierten zum Composable Storefront ist kein einfaches Upgrade. Es handelt sich um eine strategische Transformation, die Architektur, Prozesse und sogar die Entwicklungskultur betrifft.
Herausforderungen sind unter anderem: API-Abhängigkeiten, Anpassungshürden, Performance-Strategien, Re-Engineering von individuellen Features und die Vorbereitung der Cloud-Umgebung. Doch der Nutzen ist ebenso bedeutend: Eine zukunftssichere, Composable Commerce-Architektur, die Unternehmen befähigt, schneller zu innovieren, intelligenter zu integrieren und reichhaltigere Kundenerlebnisse zu bieten.
Wie unsere Teams aus erster Hand erlebt haben, ist die Reise anspruchsvoll – doch für Organisationen, die im modernen Commerce wettbewerbsfähig bleiben wollen, ist sie die Mühe wert.