SAP Commerce Cloud Setup: A Step-by-Step Implementation Guide

The setup of SAP Commerce Cloud is well documented and follows a clear sequence. Projects rarely go wrong in the steps themselves; they go wrong in the discipline around them: a data migration that was underestimated, performance tests that were skipped, or weeks spent rebuilding legacy customisations the standard already covers.

This guide walks through the ten steps from the first environment to go-live, and ends with the mistakes that cause most delays.

TL;DR: A SAP Commerce Cloud setup runs through ten steps: environment provisioning, project scaffolding, data modelling, storefront configuration, ERP integration, payment and shipping, content, testing, performance tuning and go-live. Typical implementations take four to eight months. The critical path runs through data migration and ERP integration; plan those two carefully and the rest follows.

What does the implementation process look like?

Step 1: Environment provisioning

SAP gives you access to the Cloud Portal, where you manage environments, builds, deployments and logs. You typically get three environments:

• Development: where your team builds and tests daily.
• Staging: the pre-production environment for integration testing.
• Production: the live environment serving customers.

Each has its own database, search index and configuration.

Step 2: Project scaffolding

Set up the project structure with the Commerce Cloud installer: choose a recipe (B2C, B2B or custom), activate the extensions you need and get the local development environment running. The project configuration for the cloud build is kept in a manifest.json file that must match your local extension setup.

The decisions that matter here: which recipe to start from, which extensions to activate (search, personalisation, integration) and which front end you will use. The SAP Composable Storefront (formerly Spartacus) or a custom headless front end are the options for new projects; the Accelerator templates are deprecated. That choice affects everything from performance to hiring, so make it early.

Step 3: Data modelling

Define the product model, customer model and catalogue structure. SAP’s type system lets you extend the base data model with custom attributes, relations and classification categories without touching the standard types.

Map your existing product data to Commerce Cloud’s structure. If you migrate from another platform, plan the transformation carefully: attribute mappings, category hierarchies, media. In our projects this step causes more schedule surprises than any other, because the quality of the source data only becomes visible once it is loaded.

Step 4: Storefront configuration

Configure the storefront:

• Theme and branding
• Navigation and category structure
• CMS page templates and content slots
• Responsive layouts for mobile, tablet and desktop
• SEO settings (URLs, meta tags, structured data)

Step 5: ERP integration

For SAP ERP customers this is the critical step. You configure the integration with S/4HANA or ECC for real-time pricing and available-to-promise (ATP) inventory, customer master data synchronisation, order replication from commerce to ERP, and credit checks and payment terms.

SAP Integration Suite on SAP BTP handles the middleware layer. Standard integration content speeds up the common flows considerably, but “standard” never means “no configuration”: there is always mapping work for prices, order types and customer data. If the ERP itself is changing at the same time, for example a move to S/4HANA Public Cloud, the two projects should be planned together; our post on the integrated S/4HANA Public Cloud and Sales Cloud V2 stack explains why.

Step 6: Payment and shipping

Integrate your payment provider (Stripe, Adyen, PayPal or others) and configure shipping. Commerce Cloud supports several payment and delivery modes per country, which matters for multi-market operations. A tax engine (Vertex, Avalara) handles tax calculation across jurisdictions, especially for cross-border commerce.

Step 7: Content creation

Fill the storefront with content: product descriptions, images, category and landing pages, banners. SmartEdit gives the marketing team a visual page editor. For bulk product data, use ImpEx scripts or Hot Folders; manual entry in Backoffice is fine for small catalogues.

Step 8: Testing

Test systematically:

• Functional: checkout, search, filters, account management.
• Integration: ERP pricing, inventory, order replication.
• Performance: load tests against expected traffic.
• Security: authentication, authorisation, handling of payment data.
• Browsers and devices: responsive layouts.

Step 9: Performance tuning

Before go-live:

• Cache configuration (page, fragment and API caching)
• Search index optimisation
• Image and asset delivery through the CDN
• Database query tuning for product queries and checkout
• Autoscaling settings for traffic peaks

Skip this step and your first seasonal peak will do the load test for you.

Step 10: Go-live and stabilisation

Deploy to production, switch DNS and open the storefront. Plan a stabilisation period of two to four weeks with monitoring, a rapid response team and daily performance reviews. The first weeks after launch are when everything testing missed shows up.

Data modelling and ERP integration determine the critical path across all ten steps. Most delays come from underestimating one of the two.

What are the most common implementation mistakes?

Over-customising. Commerce Cloud has strong standard functionality, yet teams build custom solutions without checking whether the standard already covers the case. Check what is built in before writing custom code. The custom route often looks faster at first; over the life of the platform it rarely is.

Underestimating data migration. Product data, customer accounts, order history and content all have to be migrated and validated. This is usually the most time-consuming step and the most common cause of delays.

Skipping performance testing. Commerce Cloud scales well when it is configured properly. Cache misses, unoptimised queries and heavy CMS pages only show up under real load. Test with realistic traffic patterns before go-live.

Ignoring mobile. A large share of commerce traffic comes from phones. The Composable Storefront is responsive by default, but custom components and CMS content need explicit mobile testing.

For the full picture of the platform, see our SAP Commerce Cloud overview; for what the project looks like from the business side, see what actually happens in a Commerce Cloud implementation. If you are still on SAP Commerce on-premise, note that mainstream maintenance ended on 31 July 2026. More on how we deliver is on our SAP Commerce Cloud solution page.

FAQ

How long does a SAP Commerce Cloud implementation take?

B2C implementations typically take three to six months depending on scope. B2B with ERP integration needs six to eight months, and complex multi-site, multi-country deployments can take eight to twelve months. The main variables are data migration, ERP integration scope and the number of custom extensions.

What technical skills does my team need?

Java developers who know the Spring framework for back-end extensions, Angular and TypeScript developers for the Composable Storefront, and integration specialists for the SAP ERP connection. For a first implementation, a dedicated Commerce Cloud architect is strongly recommended.

Can I start with B2C and add B2B later?

Yes. Commerce Cloud supports both models on the same platform, and many companies launch B2C first and add B2B in a later phase. The additional B2B work covers organisation management, approval workflows and contract pricing.

What is the difference between the Composable Storefront and Accelerator?

Accelerator is the older, server-side-rendered JSP storefront that is tightly coupled to the back end; SAP has deprecated it and plans its removal for September 2027. The SAP Composable Storefront (formerly Spartacus) is the headless Angular front end that talks to Commerce Cloud through the OCC APIs. New implementations should use the Composable Storefront or a custom headless front end.

How does deployment work?

The project configuration lives in a manifest.json file in your code repository. In the Cloud Portal you create a build from a branch and deploy it to development, staging or production. Rolling deployments allow production updates without downtime.