We sequence SAP Commerce storefront migration around OCC parity, CMS and SmartEdit behavior, B2B journeys, checkout, and route-level performance gates.
Keep legacy storefront journeys stable while route ownership, CMS dependencies, and checkout behavior are mapped.
Launch PLP, PDP, cart, checkout, and account routes only after OCC contracts, SmartEdit behavior, and Core Web Vitals budgets hold.
Composable Storefront succeeds when CMS, OCC, checkout, B2B, and performance are planned together.
Angular components mapped to SAP Commerce CMS types, slots, restrictions, and SmartEdit preview behavior.
OCC payloads reviewed for page data, cart, checkout, account, pricing, inventory, and B2B unit flows.
Approvers, org units, cost centers, saved carts, quick order, quotes, and replenishment handled deliberately.
Core Web Vitals, SSR boundaries, route-level data needs, image strategy, and third-party script budgets.
A composable build is only production-ready when the underlying Commerce APIs, CMS model, and role behavior match the journeys the business depends on.
surface
control
PDP data composed from CMS, product, price, stock, variant, and recommendation APIs.
evidence
Route fixture with OCC payload diff, fallback states, and LCP budget.
surface
control
Payment, tax, promotion, shipping, delivery mode, consent, and order submit paths tested end to end.
evidence
Contract tests for cart recalculation, order placement, and retry behavior.
surface
control
Order history, returns, addresses, saved carts, and B2B unit data stay aligned with platform rules.
evidence
Permission matrix and fixture set across anonymous, registered, and B2B roles.
surface
control
Editors can preview and place supported components without storefront-only assumptions.
evidence
CMS slot matrix with preview, restriction, and personalization notes.
The answers come from the OCC contract and 2211 readiness guides, focused on route parity, CMS behavior, and checkout safety.
The boundary is broader than /occ/v2. It includes DTO fields, enum values, CMS component models, anonymous cart behavior, user session rules, consent flow, cache headers, and error shapes. Each surface needs a backend owner.
Read source: Composable Storefront OCC contract hardeningKeep legacy journeys stable while PLP, PDP, cart, checkout, account, and CMS routes are mapped to composable equivalents. The 2211 guide separates platform compatibility, storefront risk, integration replay tests, data rehearsal, and cutover mechanics.
Read source: 2211 upgrade readiness checklistPDP, listing, cart, and recommendation routes need different payloads. The OCC guide recommends use-case-specific field sets so a performance optimization on one route does not remove fields another route requires.
Read source: Composable Storefront OCC contract hardeningCapture representative PDP, PLP, cart, checkout, login, registration, and CMS page requests, then replay them before release. The harness should cover CMS rendering, price display, cart restoration, and checkout behavior.
Read source: Composable Storefront OCC contract hardeningWe split work by route, so new storefront traffic follows API parity, CMS control, and monitoring gates.
Keep revenue-critical Accelerator flows stable while new routes are carved out.
Map PLP, PDP, cart, checkout, account, and CMS pages to composable equivalents.
Close DTO, facade, auth, cache, and error-handling gaps before the storefront depends on them.
Release composable routes in controlled slices with rollback and analytics checkpoints.