SAP Commerce Cloud Implementation: What Actually Happens in a Project

Most content about SAP Commerce Cloud implementations reads like a brochure. This post describes what actually happens in a project: the decisions that matter, the phases that take longer than planned, and the habits that separate a smooth go-live from a painful one.

SAP Commerce Cloud is a mature platform, but a mature platform does not make an implementation easy. Budgets and schedules are rarely broken by the software; they are broken by decisions nobody made early enough, data nobody looked at and integrations nobody scoped.

TL;DR: SAP Commerce Cloud implementations typically take three to nine months depending on scope. Four phases decide the outcome: discovery (architecture decisions and a customisation audit), build (iterative delivery in two- to four-week sprints), integration (ERP, PIM, payment, shipping) and go-live (data migration, performance tests, cutover). The discovery workshop and the customisation audit pay for themselves many times over during the build.

Looking for a partner rather than a DIY guide? Spadoom is an SAP Gold Partner delivering SAP Commerce Cloud in Switzerland, Germany, Austria and Italy, both the Cloud Edition and the new ERP Edition, together with the ERP core. Request a scoping call or read the Franke case study.

Phase	Typical duration	Focus
Discovery	Two to four weeks	Architecture, requirements, customisation audit
Build	Six to sixteen weeks	Data model, storefront, iterative sprints
Integration	Four to eight weeks, overlapping the build	ERP, PIM, payment, shipping
Go-live	Three to four weeks	Acceptance tests, performance tests, data migration, cutover

What happens during discovery?

Discovery is where projects are won or lost. It is where you find the technical debt of the old platform before it derails the build.

A solid discovery phase (two to four weeks) covers:

Architecture decisions. SAP Composable Storefront or a custom front end? How many environments? Which CI/CD pipeline? These choices are hard to reverse later.

Customisation audit. If you migrate from on-premise, classify every customisation: still needed, replaceable by standard functionality, or obsolete. A sizeable share usually turns out to be removable, and every piece you drop is code you do not have to migrate and maintain.

Data assessment. Profile the product catalogue, customer records, order history and content, and find quality issues before they block the migration. Projects lose weeks when nobody looks at the product data until the fourth sprint.

Integration mapping. Document every inbound and outbound connection: ERP, PIM, CRM, payment, shipping, tax, analytics. For each: protocol, data format, frequency and error handling.

Team structure and governance. Who owns what, how decisions are made, weekly demos or monthly reviews. Projects with unclear governance drag.

How should the build phase work?

Commerce Cloud implementations work best with iterative delivery: sprints of two to four weeks, each producing a working increment.

Sprint 1: data model and core configuration. Custom types, catalogue structure, pricing rules, promotion engine. The goal is a working catalogue on staging within the first weeks.

Sprints 2 and 3: storefront and checkout. Deploy the storefront with your product data and build checkout, cart logic and account management. Each sprint delivers something stakeholders can use and comment on.

Sprint 4 onwards: business logic and edge cases. Customer-specific and volume pricing, multi-warehouse inventory, B2B features such as approval workflows, purchase limits and buyer hierarchies.

The discipline that matters: every sprint ends with a working system stakeholders can test. “We’ll show you something in month four” is too late to change course.

What makes integration the hardest part?

Integration is often the largest single block of effort. These are the connections that matter most.

ERP (SAP S/4HANA, ECC). Order export, inventory sync, pricing, customer master data. Usually the most complex integration, and the one that must work: if orders do not reach the ERP, nothing else matters. SAP’s S/4HANA order management integration module covers real-time prices, stock, credit checks and synchronous order creation for B2B on the Composable Storefront, but the mapping to your ERP configuration is still project work. We deliver the commerce and ERP sides with one team; our post on the integrated S/4HANA Public Cloud and Sales Cloud V2 stack explains why that matters. If that ERP is still SAP ECC, plan the commerce integration against the target system: our hub on SAP ECC end of maintenance 2027 shows the deadlines and the migration paths.

PIM. Product data feeds, media, classification hierarchies. If the PIM is the master for product data, you need real-time or near-real-time integration.

Payment. Gateway connection, tokenisation, 3-D Secure, refunds. Commerce Cloud supports several payment extensions, and choosing and configuring the right one matters more than people expect.

Shipping and logistics. Rate calculation, label generation, tracking. Often several carriers with different APIs.

The pattern that works: start integration development in parallel with the later build sprints instead of waiting until the platform is “finished”. Otherwise you end up with a long integration phase bolted onto an already long build.

What does go-live actually involve?

User acceptance testing (two to three weeks). Business users, not developers, test every critical flow with real data. They find what developers never would.

Performance testing. Load tests with realistic traffic including a peak-day simulation, validated autoscaling and page load times against targets. Commerce Cloud handles the infrastructure scaling, but your custom code and data queries still have to perform.

Data migration dress rehearsal. Run the full migration end to end and measure the elapsed time: it defines your cutover window. Test the delta migration for data created during the transition.

Cutover. Execute the go-live runbook: freeze the old system, run the delta migration, switch DNS, validate key flows and monitor for 48 hours with the full team on standby. After that, measurement takes over: which KPIs to track and which tools to connect is covered in our post on Commerce Cloud analytics and store performance.

If you are migrating from SAP Commerce on-premise, keep in mind that mainstream maintenance for the on-premise version ended on 31 July 2026; our post on what to do now that on-premise support has ended covers the options.

What separates good implementations from bad ones?

Investment in discovery. Projects that spend two to four weeks on proper discovery save multiples of that during the build. Projects that skip it spend the build discovering what they should have planned.

Scope discipline. The biggest risk is not technical but scope creep. “While we’re at it, let’s also add…” is how a four-month project becomes a nine-month project. Define the first release, ship it, then iterate. You are not saying no forever; you are saying not yet.

Integration first. Start the integration architecture in discovery and integration development in sprint 2 or 3. The platform is not useful until it is connected to your ERP.

For the platform itself, see our SAP Commerce Cloud overview and the step-by-step setup further down. For budgets, our pricing and TCO guide breaks down licence, implementation and running costs. And if you are comparing partners, our overview of the best SAP Commerce Cloud partners in Switzerland sets out the criteria.

How do you set up SAP Commerce Cloud step by step?

On the technical side, a Commerce Cloud setup runs through ten steps. Data modelling and ERP integration determine the critical path; most delays come from underestimating one of the two.

1. Environment provisioning: SAP gives you the Cloud Portal and three environments (development, staging, production), each with its own database, search index and configuration.
2. Project scaffolding: pick a recipe (B2C, B2B or custom), activate the extensions you need and decide on the front end; the build configuration lives in manifest.json.
3. Data modelling: extend the product, customer and catalogue model through the type system and map your existing product data to it.
4. Storefront configuration: theme, navigation, CMS templates and content slots, responsive layouts and SEO settings.
5. ERP integration: real-time prices and ATP, customer master data, order replication and credit checks, usually through SAP Integration Suite.
6. Payment and shipping: payment provider, delivery modes per country and a tax engine for cross-border sales.
7. Content creation: product texts, images and landing pages in SmartEdit; bulk data through ImpEx or Hot Folders.
8. Testing: functional, integration, performance, security, browsers and devices.
9. Performance tuning: caching, search index, CDN delivery, query tuning and autoscaling for peaks.
10. Go-live and stabilisation: deploy, switch DNS and plan two to four weeks of close monitoring.

Want help making this real?

Spadoom delivers SAP Commerce Cloud end to end: the Cloud Edition for enterprise B2B and B2C, the ERP Edition for mid-market companies on S/4HANA Public Cloud, and Hybris migrations off on-premise. At Franke, we took over a stalled platform, took the commerce launch live in 90 days and cut manual orders by 75%; the project won the SAP Quality Award for “Rapid Time to Value”. We start every project with a discovery workshop that defines the architecture, maps the integrations and produces a realistic timeline. Talk to us.

Frequently asked questions

How long does a typical SAP Commerce Cloud implementation take?

It depends on scope. Most projects take three to nine months: a migration from on-premise with a moderate customisation footprint often three to six months, a greenfield B2B implementation with several storefronts, heavy integrations and custom logic six to nine months. At Franke, the commerce launch went live in 90 days. The biggest variable is integration complexity, not platform configuration.

How much does an SAP Commerce Cloud implementation cost?

For mid-market projects, implementation costs are usually in the mid six figures; complex enterprise programmes can exceed a million. The main cost drivers are the number of integrations, customisation complexity, data volume, the number of storefronts and markets, and whether you migrate from an existing SAP system or start from scratch.

What team do we need for an SAP Commerce Cloud project?

A typical mid-size project needs three to five implementation consultants (SAP Commerce, front end, integration) plus two to three people on the customer side (product owner, business analyst, IT contact). The customer-side product owner is the most important role, because they make scope decisions and provide business context. Projects without a dedicated product owner consistently take longer.

Should we use the Composable Storefront or a custom front end?

For most projects, start with the SAP Composable Storefront: it is integrated with the platform, actively maintained and covers standard B2B and B2C scenarios. Consider a custom React or Next.js front end if you need a fundamentally different user experience or run several very different storefronts; it adds weeks to the build and needs dedicated front-end developers for maintenance. Our comparison of the Composable Storefront and React/Next.js goes into detail.

What is the most common reason Commerce Cloud implementations go over budget?

Integration complexity that was not properly scoped in discovery, followed by scope creep during the build. Both can be prevented with a disciplined discovery phase that maps every integration and classifies every customisation, and with a clearly defined first release.

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.