alokai-logo-header-desktop.svg
Practical migration strategies to navigate the end of SAP Accelerators and future-proof frontend systems
sap

Practical migration strategies to navigate the end of SAP Accelerators and future-proof frontend systems

July 1, 2025
8 min read
IN THIS ARTICLE

The transition offers retailers an opportunity to modernize frontend systems and provide a flexible, scalable way to manage ecommerce websites.

SAP will soon stop supporting and shipping code for its SAP Commerce Cloud storefront accelerators, and retailers are finding many opportunities to future-proof their ecommerce frontend solutions with a modern headless system. Read the full FAQ here

Headless frontends are flexible, scalable, and improve the user experience. While migrating to a new frontend solution may seem overwhelming at first, headless architecture is more reliable than its legacy counterparts, and it opens the door to emerging technologies, like artificial intelligence (AI) and augmented reality (AR).

According to McKinsey, retailers that make software and emerging technologies the core of their services are laying a foundation for future growth aligned with development and business goals, such as faster time-to-market for new features, improved uptime, and better performance. 

Instead of relying on tightly coupled templates, they can build frontends that match their brands.

The end of SAP UI Accelerators

SAP Commerce Cloud, formerly known as SAP Hybris (or simply “Hybris”), is a comprehensive ecommerce platform. Its out-of-the-box capabilities include storefront UI accelerator templates that provide B2C, B2B, B2B2C, and industry-specific ecommerce experiences to millions. These have historically been the standard storefronts for net new SAP Commerce Cloud implementations. 

However, SAP will remove the storefront accelerators by Q3 2027.

As in the past, SAP has already begun phasing out its legacy ecommerce accelerators. The software developer addresses frequently asked questions about the transition in this document

While it's a major change for companies that have been using SAP’s accelerators for years, retailers have options when it comes to choosing a headless frontend solution compatible with SAP backend systems. 

The benefits of modernization

sap-modernization-benefits.jpg

Despite the work involved and challenges that lie ahead, modernizing an ecommerce frontend has many benefits:

  • Enhanced performance: Modern frontends load faster with more concurrent users and scale automatically, which improves site performance and SEO and reduces cart abandonment rates

  • Better customer experience: From personalized recommendations to omnichannel support, modern frontends meet increasing customer demands via zero-downtime releases

  • Easier integrations: Payment gateways, customer relationship managers (CRMs), AI agents, and analytics tools are examples of systems that become easier to integrate with the use of modern frontend technologies, APIs, and standard protocols

  • Lower costs: Because they deploy separately from the backend and therefore require less testing, modern frontends significantly reduce the cost of software development and improve time-to-market for new features

  • Improved security and compliance: A modern frontend is built to be secure by design and helps your organization meet and maintain compliance with regulations and standards like GDPR, CPRA (formerly CCPA), or WCAG

Pathways to replacing SAP accelerators

SAP Commerce users have 3 main choices for their new frontend architecture:

  • Alokai

  • SAP Composable Storefront

  • A custom headless platform. 

Each option provides a more modern approach than the SAP Commerce accelerator templates. However, they are different in terms of underlying technology, flexibility, scalability, and vendor relations.

Alokai (formerly Vue Storefront)

Alokai is a headless, frontend-as-a-service framework built with React (or the older Vue.js variant). It’s designed for composable commerce and integrates with SAP Commerce Cloud and many other ecommerce platforms through GraphQL APIs. Alokai is best suited for retailers that want a performance-oriented architecture at a lower cost than maintaining a custom frontend stack.

The platform lets developers build highly customizable storefronts that can evolve as customer expectations change. 

For retailers adopting modern JavaScript practices, seeking a scalable frontend without building from scratch, and requiring responsive, enterprise-grade technical support, Alokai is a strong choice.

alokai-unified-data-layer.png

Learn more about Alokai for SAP – request a personalized demo!

SAP Composable Storefront (formerly Spartacus)

SAP Composable Storefront is SAP’s official headless frontend framework. It replaces the legacy Commerce Cloud Accelerator storefronts and connects directly with SAP Commerce through OCCv2 APIs. 

For retailers wanting to stay within the SAP ecosystem while adopting a composable frontend strategy, SAP Composable Storefront is the approach to take.

The solution is prebuilt with Angular components for core ecommerce features. Like the legacy accelerators, these components are built on SAP’s architecture and are maintained by SAP. 

While not as flexible as custom frameworks, SAP Composable Storefront offers an integrated SAP experience. It’s a good fit for enterprise teams that need headless capabilities but prefer to work with their long-term vendor rather than third-party, open-source, or custom alternatives.

Custom storefront builds (React or Angular)

Custom frontend systems offer the highest level of control, flexibility, and scalability. They avoid vendor lock-in and typically avoid licensing fees. Using React or Angular, these fully headless solutions are usually deployed to the cloud (AWS, Google, or Azure) and connect to backend systems, such as SAP Commerce, through GraphQL APIs. 

Because SAP Commerce Cloud runs on Azure, it often makes sense to deploy a headless solution that connects to an SAP backend on Azure to avoid ingress/egress data charges and reduce latency. However, other enterprise IT systems connected to the custom headless frontend must be considered in the final decision.

Retailers that choose to build a custom headless frontend system with React also benefit from using the Next.js framework. Next.js is a flexible React framework. It includes building blocks to create fast, full-stack web applications. For example, the Next.js framework lets developers build endpoints for APIs directly within the application. It also handles file-based routing, server-side rendering (SSR), static site generation (SSG), and many built-in optimizations.  

Additional benefits of custom storefront solutions

Regardless of whether the frontend system is built with React or Angular, some of the benefits of a custom headless frontend include:

  • Precise branding: Retailers can design a storefront that reflects their specific brand and differentiates them from common templates

  • Vendor agnosticism: Developers are free to use the libraries, tools, and third-party solutions they prefer, and adopt new solutions as technologies evolve

  • System ownership: Custom solutions are free from long-term license commitments with a single vendor and are designed to achieve a retailer’s unique business goals

  • Control: Retailers can update on their timeframe instead of being forced to upgrade on a vendor’s schedule, which reduces the risk of breaking custom changes when backwards-incompatible patches roll out

  • Futureproofing: By modernizing the frontend, retailers open the door to integrating emerging tech in their eCommerce environment, like AI, AR, virtual reality (VR), voice commerce, and more

To get started with a custom frontend solution, the first step is to select a software development partner, such as Intellias. The right partner will have decades of experience designing custom systems for retail clients, including expertise in headless frontend development in the technology of choice.

Upgrading smartly using the strangulation method

Although support for SAP accelerators is ending soon, migration to a headless storefront doesn’t need to happen all at once. 

An effective strategy for reducing risk and managing complexity during the ecommerce migration is the strangler pattern. With this approach, developers gradually replace pages and features over time, preventing major disruptions to the site.

Here’s how the strangler pattern works:

  • Developers run both the legacy and the new headless frontends in parallel

  • Requests are routed either to the legacy system or the new system, depending on what has and has not been migrated

  • Over time, all the pages and features move to the new site

  • The old site is essentially “strangled” out of existence and eventually decommissioned

Source: Microsoft
Source: Microsoft

The smarter, step-by-step approach

The strangler pattern supports continuous delivery and avoids large rollouts. It also provides an opportunity to collect feedback from users, which developers can then use to improve the new system before the legacy system is fully retired.

  1. Usually, the rollout strategy begins with isolated pages that have minimal dependencies. Contact pages, FAQs, and terms & conditions pages are good candidates for the first phase. 

  2. Product detail pages, search results, or landing pages are moved once session handling and user state management are fully addressed and stable. 

  3. Finally, the pages requiring the most stability, such as checkout systems, carts, and user accounts, are moved to complete the migration. 

Developers who use the strangler pattern can also test high-impact areas and new technologies, monitor performance and user behavior, and refine the system as the migration progresses.

composable-step-by-step.png

Optimizing the OCCv2 API

During frontend migration, developers also have an opportunity to improve communication between the frontend and backend of the system via the OCCv2 API. 

While this API is capable of many things, most of its capabilities predate SAP Composable Storefront and other headless frontends. Consequently, this API often carries years of technical debt that limit what the frontend can do. Furthermore, many of these technologies do not align with customizations in the SAP Commerce platform.

By enhancing the OCCv2 layer during migration, developers simplify their task while providing a better experience for site users. Optimizing the OCCv2 layer also lays the groundwork for future improvements.

As developers rework the frontend, they often take the opportunity to:

  • Streamline existing API calls and remove unused endpoints

  • Introduce new, purpose-specific endpoints for frontend components

  • Ensure that out-of-the-box API calls account for and execute custom logic that has been added to the out-of-the-box platform

  • Add GraphQL APIs to improve data delivery

  • Optimize cart, checkout, and login flows for speed and consistency

These changes support faster page loads and more efficient development cycles. A clean OCCv2 API also opens the door to innovation and improves security. It becomes easier to integrate third-party services, support omnichannel environments, or reimagine the storefront experience. 

These backend technical enhancements often lead to customer-facing and time-to-market improvements that drive real business value.

During OCCv2 API optimization, developers often find other sources of technical debt within the SAP Commerce platform. For example, they may uncover custom code that does not adhere to SAP best practices. This leads to other improvements that contribute to the overall health of the ecommerce solution.

Avoiding concerns about session management or SEO

Running two frontends in parallel, even temporarily, is a risk. 

During a strangler pattern migration, parts of the site connect to the new frontend, but others run on the legacy SAP storefront accelerator. This dual-frontend state can create challenges for session continuity and SEO performance.

Session management

Session management is the immediate concern. When users navigate between pages served by different frontends, they should not be aware that they are transitioning between two different systems. Therefore, user sessions must persist. Regardless of which frontend they are using, users must be able to stay logged in, their history must remain intact, and items added to the cart must be available through checkout.

To maintain seamless user experiences, retailers should:

  • Centralize session and authentication logic to avoid duplication

  • Use shared cookies or tokens across both frontends

  • Ensure elements like headers and footers remain consistent between different frontends

Navigating SEO concerns

SEO is the second issue. Migrating pages to a new frontend can affect page structure, URLs, and metadata. Consequently, search rankings can drop, and organic traffic can suffer.

A solid SEO continuity plan includes mapping legacy and new URLs with 301 redirects while preserving metadata, structured content, and crawlability. 

Under a strangler pattern approach, this mapping needs to be refreshed each release to account for the next pages and features being migrated. When session handling and SEO are managed proactively, the migration process becomes smoother.

A modern frontend in practice: Intellias’ experience

In our practice, one retailer discovered that migrating from an SAP frontend to a custom-built system solved many ongoing problems. A large building supplier had three uniquely branded websites. The company had been operating with an SAP Commerce solution that used pre-formatted templates. Although the sites shared some similar code, each was developed in isolation. As a result, the user experience across the sites was inconsistent. Some functions were duplicated, and workflows were inefficient. Despite these concerns, the company wanted to ensure that each site retained its branding.

After contacting Intellias, the company began a headless frontend modernization effort. Using APIs and microservices, Intellias designed a platform that unified backend operations with the frontend systems. The ecommerce sites have access to the same backend system data and share 85% of the same code. 

To meet the client’s needs, Intellias engineers:

  • Rebuilt each storefront in React using a shared component library, which reduced the amount of code for each site but respected each brand’s unique identity

  • Introduced a GraphQL API layer to deliver real-time data on demand to each frontend

  • Deployed backend microservices using Kubernetes, with real-time data flows powered by Kafka

By exposing the necessary data and services needed for each site, the platform avoided unnecessary overhead and made future development easier to manage. With the headless frontend, developers could introduce new features or services to one site without disrupting the others. 

The new websites improved user experience and streamlined integration with third-party services. They also reduced the time spent launching a new website, from many months to just six weeks. 

With the help of the headless ecommerce site developed by Intellias, the building supplier reduced costs to launch a new branded site by 83% and achieved zero downtime during rollouts for the first time.

The future of ecommerce development

SAP’s decision to sunset its legacy accelerators has forced a long-overdue conversation about frontend architecture. For retailers still running on these templates, the next steps are no longer optional, but they don’t need to be disruptive.

The migration is also a turning point and an opportunity. Retailers are beginning to reimagine the way they deliver ecommerce services. 

Regardless of whether companies choose Alokai, SAP Composable Storefront, or a custom build, they are preparing their organizations for the future. 

shape

Ready to dive in? Schedule a demo

Get a live, personalised demo with one of our awesome product specialists.