7 SAP Commerce Cloud Mistakes That Derail Projects (and How to Avoid Them)

SAP Commerce Cloud is a solid platform. It is also complex enough that the same mistakes keep derailing projects, across industries, team sizes and budgets. The patterns are predictable, which is good news: predictable mistakes can be prevented.

Below are the seven we see most often, each with what to do about it.

TL;DR: SAP Commerce Cloud projects go wrong for seven recurring reasons: hiring Java generalists instead of Commerce specialists, skipping upgrades, over-customising the platform, vague requirements, ignoring performance, under-planning data migration and insufficient testing. Each has a specific prevention step, and the common thread is deciding early rather than fixing late. If you are still on SAP Commerce on-premise, read our guide to the options after end of mainstream maintenance first.

Mistake 1: Hiring Java generalists instead of Commerce specialists

Commerce Cloud runs on Java, so companies hire strong Java developers and expect them to be productive from day one. They will not be.

Commerce Cloud has its own data model (the type system), its own import mechanism (ImpEx), its own extension architecture, its own build and deployment pipeline, and its own caching and search indexing (Solr). A senior Java developer without Commerce Cloud experience needs months to get up to speed, and during that time makes the architectural mistakes that are expensive to undo: over-customising the type system, breaking the upgrade path, writing custom code where standard configuration would have done the job.

We have taken over projects where exactly this happened, and the cleanup cost more than hiring the right people from the start would have.

How to prevent it: Hire developers with proven SAP Commerce Cloud experience. Ask for specific project references and check SAP certifications. If you are building an internal team, pair each new developer with an experienced Commerce Cloud consultant for the first months. If you are still choosing an implementation partner, our overview of SAP Commerce Cloud partners in Switzerland sets out what to check.

Mistake 2: Skipping or deferring upgrades

SAP updates Commerce Cloud regularly (SAP Help Portal). Each update brings security patches, performance improvements, new features and fixes. Skipping them feels like it saves time; in reality it creates a compounding problem. The longer you wait, the more updates stack up, and the harder the eventual upgrade becomes.

After two or three skipped releases, the upgrade effort can rival the original implementation. Custom code that worked on version N may not compile on N+3, dependencies drift and testing effort multiplies. Platform-level changes such as the move to Java 21 and Spring 6 make this very concrete; we describe what that migration involves in our Java 21 and Spring 6 guide for SAP Commerce Cloud.

How to prevent it: Treat upgrades as routine maintenance, not projects. Reserve a fixed budget every year for Commerce Cloud updates and apply them within one release cycle of availability. If you cannot upgrade that often, your customisation footprint is probably too large, which brings us to mistake 3.

Mistake 3: Over-customising the platform

Commerce Cloud’s extension framework makes it easy to modify almost anything. Too easy. Every custom extension is code you own, maintain and test on every upgrade. Each one adds to the upgrade burden, increases the testing surface and creates potential compatibility issues.

An estate with a hundred or more custom extensions can turn every upgrade into a multi-month project. Consolidating them onto a small, justified set that covers the same business functions is often the fastest way to make upgrades routine again: same outcomes, a fraction of the maintenance.

The worst offenders: modifying core type system definitions, overriding standard controllers, and replacing standard functionality with custom implementations that do almost the same thing with minor differences.

How to prevent it: Before building any custom extension, ask whether standard configuration can do the job. If not, use the platform’s extension points and, on the storefront side, SAP Composable Storefront’s customisation mechanisms rather than modifying core code. Set a limit on custom extensions (10 to 15 is a reasonable target for a mid-complexity project) and document the business justification for every single one.

To see how we keep customisation lean while getting the most from the platform, visit our SAP Commerce Cloud solution page.

Mistake 4: Vague or unrealistic business requirements

Only 48% of digital initiatives meet or exceed their business outcome targets, according to a Gartner survey (Gartner, 2024). Unclear requirements are a frequent contributor.

“We want an e-commerce platform like Amazon” is not a requirement. “We need a B2B storefront with customer-specific pricing, minimum order quantities, approval workflows and a connection to our SAP ERP for real-time availability” is.

When business requirements are vague, the implementation team fills the gaps with assumptions, and those assumptions are often wrong. A few months later the gap becomes visible, and expensive: rework, scope creep and a system that does not match what users need.

How to prevent it: Define requirements at the process level, not the feature level. Use concrete examples: “When a purchasing agent from Account X logs in, they see their negotiated price list and their order history for the last 12 months.” Walk through every user journey: browsing, searching, configuring products, checking out, tracking orders and returns.

Mistake 5: Ignoring performance until it is too late

A slow storefront costs sales, and in B2B it also costs trust with buyers who use the shop every day.

Commerce Cloud performance depends on proper search indexing, caching configuration, CDN setup and efficient custom code. Many teams focus entirely on functionality during the build and only discover performance problems during load testing, or after go-live.

Common performance killers: unoptimised product queries, missing cache headers, too many API calls per page, large catalogues without proper indexing, and custom code that bypasses the platform’s built-in caching.

How to prevent it: Set performance budgets from day one, for example page load under 2 seconds for product listing pages and under 1.5 seconds for product detail pages. Run load tests after every sprint, not just before go-live, and monitor search query times, cache hit rates and API response times continuously.

Mistake 6: Under-planning data migration

Data migration for Commerce Cloud covers products, categories, prices, customers, historical orders and content (CMS pages, media). Each data type has its own ImpEx format, validation rules and dependencies. Products depend on categories, prices depend on products, orders depend on customers and products. The dependency chain is real.

Teams that treat migration as a one-off script discover in user acceptance testing that some products have broken images, customer accounts are duplicated and historical orders do not display correctly. By then the go-live date is in trouble. We cover the migration-specific pitfalls in more detail in the five most common SAP Commerce migration mistakes.

How to prevent it: Plan migration as a separate workstream with its own timeline, not as a task. Run at least three full migration cycles before go-live: one for structure validation, one for data quality verification and one as a dress rehearsal. Validate ImpEx files before import, and check image assets, category assignments and price associations programmatically.

Mistake 7: Insufficient testing

Insufficient testing is how many overruns materialise, because bugs found late cost far more to fix than bugs caught early.

Commerce Cloud projects need several types of testing: unit tests for custom code, integration tests for API connections, performance tests under load, and user acceptance testing with real business scenarios. Skipping any one of them creates risk.

The most dangerous gap is integration testing with the ERP. Commerce Cloud sends orders to the ERP and receives availability, prices and shipping updates. If this integration is not tested under realistic conditions (concurrent users, peak volumes, error scenarios), the problems show up on launch day. For companies on SAP S/4HANA, our guide to SAP Commerce Cloud with S/4HANA Public Cloud in B2B explains where that seam sits.

How to prevent it: Plan testing as a substantial share of total project effort. Start integration testing mid-project, not in the final week. Use automated suites for regression testing on every deployment, and run acceptance tests with actual business users working through real scenarios, not the implementation team clicking through happy paths.

Frequently Asked Questions

What’s the most expensive Commerce Cloud mistake to fix?

Over-customisation. Removing or refactoring deeply embedded custom extensions can cost more than the original implementation, and every extension adds effort to each upgrade. Every custom extension should have a documented business justification and an assessment of its impact on the upgrade path.

How long should an SAP Commerce Cloud implementation take?

Typical timelines are 4 to 9 months for a standard B2B or B2C storefront, and 8 to 14 months for complex multi-country, multi-language implementations. The main drivers are the number of integrations, the amount of customisation and the state of the data to be migrated.

Should I migrate from SAP Hybris on-prem to Commerce Cloud?

In most cases, yes. Mainstream maintenance for SAP Commerce on-premise ended on 31 July 2026; release 2205 now only receives customer-specific maintenance, without new support packages, legal changes or library updates. The question is how and how fast, and whether Commerce Cloud, the ERP Edition or a replatform fits your situation.

How many custom extensions is too many?

There is no absolute number, but 10 to 15 is manageable for most projects. Above 30, upgrade effort starts to compound. Above 50, each upgrade tends to become a multi-month project. Count your extensions regularly and consolidate where you can.

Can I use Commerce Cloud for B2B and B2C on the same platform?

Yes. Commerce Cloud supports multiple storefronts (sites) on a single instance, each with its own catalogue, pricing, customer model and checkout flow. B2B and B2C can coexist, but implementation complexity increases, so scope and budget accordingly.