Accelerate commerce by decoupling your SAP Commerce Cloud storefront

To prepare for this eventual deletion and to prevent disruptions to your business, you should begin planning a move to a composable, headless architecture using a decoupled front end and the newer SAP OCC REST-based API extensions.

The OCC extensions already expose many of the SAP Commerce Cloud features that you offer to your customers through the existing storefronts. SAP has stated that they are committed to developing the OCC extensions to expose new B2C, B2B and B2B2C commerce features as they become available. In addition, you can easily add custom OCC endpoints for any business-specific features and functionality. These custom endpoints make it easier for a greater collaboration between the IT, marketing and business teams for improved customer experience.

As for the application frontend, there are many decoupled solutions to explore, such as SAP Commerce Cloud Composable Storefront (aka Spartacus), a third-party storefront - such as Vue Storefront or React Storefront, or even develop your custom solution. Each solution has implementation-specific pros and cons, including choices around integrating a content management solution.

Advantages of headless

Whichever solution you choose, using a modern headless decoupled commerce platform offers several advantages over the traditional monolithic architecture:

• Faster innovation: Frontend and backend services can be worked on and deployed separately, allowing your teams to work more efficiently.

• Greater flexibility: A decoupled storefront is designed to be highly flexible, so you can create a perfectly tailored storefront to your specific business needs.

• Reduced risk: A decoupled storefront allows you to choose your own implementation partners and tech stack, which ensures you are not locked into a proprietary vendor solution.

Mitigating risk

Significant architectural shifts like this one can seem very daunting and complex. However, some strategies can be used to mitigate risk by migrating your site functionality, content and integrations in a more step-wise, controlled manner.

• Domain-driven design: Besides re-implementing legacy features, new functionality is only implemented in the new architecture and environment. Eventually, the “switch is flipped,” and the new platform takes over for the legacy platform.

• Parallel adoption: All features are duplicated across both architectures/environments, and eventually, when feature parity is achieved, the “switch is flipped” to use the new frontend platform.

• Strangler pattern: A router, or facade layer, decides whether to serve the page (or part of a page) from the new solution or the legacy solution. You can still use Legacy functionality while the new solution is built out.

Get in touch to discuss your current commerce experience, infrastructure and options for navigating the deprecation of SAP Accelerator Storefronts.