Headless Storefront Migration for a Major European Health and Personal Care Retailer

Client

The client is a major European health and personal care retailer with a mature ecommerce presence and a large everyday shopping audience. Its business operates across health, personal care, and family-focused categories where customers expect reliable digital journeys and up-to-date information.

Client Need

The retailer’s ecommerce platform had to support a broad everyday product mix, frequent content changes, and customer journeys that connected online shopping with store-related behavior. Over time, the legacy JSP storefront made that evolution harder: visible changes could be slowed by behavior embedded in the existing platform and difficult to adjust predictably. At the same time, SAP was moving away from the legacy storefront, so the team also had to plan ahead for the end of support.

The move to a headless model based on Composable Storefront addressed both concerns: it gave the team a more flexible and maintainable front end for ongoing changes while also moving the platform toward SAP’s supported storefront direction.

• Legacy JSP behavior was partly server-side and configuration-driven, so the team had to identify logic that was not visible from the detached front-end alone.
• The headless storefront needed explicit API data instead of direct server-side access, which made missing response fields or hidden decisions part of the migration scope.
• Legacy JSP and Composable Storefront had to coexist on the same SAP Commerce back-end, so changes for the new experience could not disrupt the existing one.
• SmartEdit, CMS components, shared catalog structures, and restrictions had to remain usable for business content operations during the transition.
• Undocumented configuration and production-only settings created migration risk because behavior could differ between environments or appear only after deployment.

Together, these conditions created the core migration tension: the team had to move the storefront into a headless model while preserving behavior that was still rooted in the legacy platform.

Solution

Specialized in ecommerce migration services, Expert Soft moved from a legacy JSP storefront to a headless Composable Storefront setup. The work covered front-end migration, back-end adaptation, defect investigation, code refactoring, and migration support across SAP Commerce, CMS operations, and storefront behavior.

The migration happened under coexistence conditions. The new headless storefront had to operate alongside the legacy front-end while using shared platform structures, including the SAP Commerce back-end, content catalog, CMS components, and SmartEdit-managed content workflows. That made the project less like a simple interface replacement and more like a controlled reconstruction of storefront behavior inside a new delivery model.

Expert Soft helped determine which patterns could be reused, which parts needed Composable Storefront-specific implementation, and where the front-end required clearer back-end contracts. The team analyzed page composition, configuration, CMS structures, API needs, cache behavior, and component dependencies, then adapted the implementation so the new storefront could preserve the behavior that mattered while becoming easier to evolve.

Migration Workstreams

Page-by-Page Storefront Migration

The storefront migration was organized around individual pages rather than a single broad conversion. For each page, the team analyzed the legacy slot structure, global and local components, and the way SAP Commerce content was assembled for the existing storefront.

Where Expert Soft’s SAP Commerce migration experience pointed to a reliable pattern, the team reused that approach. Where the new storefront needed different behavior, Composable Storefront-specific components were created or wired into the appropriate slots. This helped the client preserve required shopping and content journeys without assuming every JSP-era structure could be copied directly into the detached front-end.

CMS And SmartEdit Coexistence

Business users continued to manage content through SmartEdit, so migration decisions had to protect both rendering behavior and the operating model around content changes. The platform used a shared content catalog, with restrictions controlling whether specific pages or components applied to the legacy storefront, Composable Storefront, or both.

This made coexistence an operational concern. SmartEdit advanced edit mode still had to support page structure management, and live view validation still needed to show business users how changes would appear on the site. Expert Soft supported this shared CMS model by checking component availability, restrictions, page structures, and integration points so changes for the new storefront did not unintentionally disrupt legacy behavior.

Back-end Logic for A Headless Front-end

The detached front-end exposed back-end assumptions that the legacy JSP storefront could previously absorb more directly. When Composable Storefront needed data in a different format, or needed behavior that had not been exposed through an API, back-end logic had to be revisited rather than treated as an isolated front-end issue.

Expert Soft supported this work across several areas. A table-of-contents CMS component that worked on legacy article pages had to be wired into the correct extension points so it could function in Composable Storefront while still using the shared catalog. Order email placeholders and old price display depended on back-end label configuration whose legacy format did not match the new front-end’s expectations.

Analytics requirements also had to be carried over from the JSP storefront. In some cases, that meant extending the existing API so the back-end could provide the additional page or CMS component data the new front-end needed without introducing unnecessary requests. The front-end could then reproduce the required Google Tag Manager Data Layer events in the new storefront.

These tasks showed why headless migration can change back-end responsibilities. The back-end remained part of the storefront contract, and front-end-specific conventions had to be made explicit enough for both storefronts to keep working correctly.

Customer Lifecycle Personalization and Cache Behavior

The company provided a personalized storefront feature designed to react to customer life-stage signals, including pregnancy or child-related status. Its role is to decide when feature-related pop-ups or product prompts should appear in the shopping journey.

After migration, this became a cache-sensitive area because back-end-driven personalization did not always reflect the current user context in the rendered UI.

Expert Soft addressed the issue by reusing the existing triggers-based mechanism. The front-end could request the relevant personalization signals through a dedicated triggers endpoint and decide whether to display the targeted pop-up at render time. This kept the decision closer to the storefront and reduced reliance on cached, back-end-driven behavior.

The scope was deliberately bounded. The change applied to pop-up behavior, not full personalized page rendering. The same mechanism can support similar conditional features when the signal and rendering responsibility are defined clearly.

Pop-Up Architecture Refactoring

Checkout and shared UI flows included many interdependent pop-ups. In the legacy implementation, similar pop-ups could exist as separate components with duplicated logic, making the structure harder to maintain and reuse as the storefront evolved.

Expert Soft analyzed related tasks together instead of treating each pop-up as a separate fix. The team reviewed upcoming dependencies, mapped existing component relationships to avoid introducing circular dependencies during refactoring, sketched module and component boundaries, and extracted shared behavior into reusable structures where it made sense. This gave the new storefront a more modular pop-up architecture and reduced the risk of duplicated logic as future changes were introduced.

Caching And Production-Specific Issues

Some migration defects came from runtime differences rather than visible code changes. In offline order history, cached responses were reused across request contexts, so offline-order data could appear incorrectly when the cache did not distinguish the relevant order type or category. The issue required tracing cache behavior at the controller level instead of treating the symptom as a display bug.

Other issues appeared only under specific content or environment conditions. A shared store locator page used by both storefronts could break on the legacy side when changes were made for Composable Storefront. A production homepage issue was tied to a configuration flag or attribute enabled only in production.

In these cases, Expert Soft investigated cache context, content setup, restrictions, and environment-specific configuration so the migration could move forward without losing control over existing storefront behavior.

Across these workstreams, Expert Soft helped the migration move forward without separating the headless rollout from the operational reality of the existing platform. The team addressed the main coexistence, personalization, caching, CMS, and component-architecture risks that could otherwise make the new storefront harder to control in production.

Technologies

SAP Commerce Cloud, Composable Storefront, Angular, SmartEdit

Conclusion

A successful headless migration in enterprise ecommerce is not only a front-end technology change. It depends on understanding where existing platform behavior actually lives, which business workflows depend on it, and how each dependency should be carried into the new model.

For this major European health and personal care retailer, Expert Soft supported that transition by combining Composable Storefront migration work with SAP Commerce, CMS, SmartEdit, cache, personalization, and back-end logic analysis. The result was a more flexible storefront direction without losing control over the business-critical behavior that still kept daily ecommerce operations running.