7 SAP Commerce Cloud Mistakes That Derail Projects — And How to Avoid Them

SAP Commerce Cloud is a solid platform. It’s also complex enough that the same mistakes keep killing projects. We’ve seen them across industries, team sizes, budgets. The patterns are so predictable it’s almost boring.

Seven mistakes. Here’s each one and how to prevent it.

TL;DR: More than two-thirds of large-scale tech programmes miss time, budget, or scope targets (BCG, 2024). SAP Commerce Cloud projects fail for the same predictable reasons: hiring Java generalists instead of Commerce specialists, skipping upgrades, unclear requirements, over-customisation, ignoring performance, bad data migration, and insufficient testing. Each mistake has a specific prevention strategy — the common thread is planning upfront instead of fixing later.

Mistake 1: Hiring Java Generalists Instead of Commerce Specialists

Gartner has named SAP a Leader in the Magic Quadrant for Digital Commerce for 11 consecutive years (Gartner MQ, 2025). But the platform’s depth is exactly what makes generalist hires a problem.

Commerce Cloud runs on Java. So companies hire strong Java developers and expect them to hit the ground running. They won’t.

Commerce Cloud has its own data model (type system), its own import mechanism (ImpEx), its own extension architecture, its own build and deployment pipeline, its own caching and indexing systems (Solr/OpenSearch). A senior Java developer with no Commerce Cloud experience needs 3-6 months to get up to speed. During those 3-6 months, they’ll make architectural mistakes that are expensive to undo. Over-customising the type system. Breaking the upgrade path. Writing custom code where standard configuration would’ve done the job.

We’ve inherited projects where this happened. The cleanup cost more than hiring the right people from the start.

How to prevent it: Hire developers with proven SAP Commerce Cloud experience. Ask for specific project references. Check SAP certifications. If you’re building an internal team, pair each new developer with an experienced Commerce Cloud consultant for the first 3 months.

Mistake 2: Skipping or Deferring Upgrades

Global e-commerce sales are projected to reach $6.334 trillion by 2027 (eMarketer, 2024). The platform evolves to keep pace, but only if you keep it current.

SAP releases major Commerce Cloud updates regularly. Each one includes security patches, performance improvements, new features, and bug fixes. Skipping updates 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 2-3 skipped releases, the upgrade effort can rival the original implementation. Custom code that worked on version N may not compile on version N+3. Dependencies drift. Documentation goes stale. Testing effort multiplies.

I’ve seen a client skip 4 releases and then spend 5 months catching up. That’s not a maintenance task. That’s a project.

How to prevent it: Treat upgrades as routine maintenance, not projects. Budget 2-4 weeks per year for Commerce Cloud updates. Apply updates within one release cycle of availability. If you can’t upgrade that frequently, your customisation footprint is probably too large. Which brings us to Mistake 3.

Mistake 3: Over-Customising the Platform

Seventy-five per cent of ERP implementation projects get derailed (Gartner, 2024). Over-customisation is one of the most common causes.

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.

We inherited one project with 150+ custom extensions. Every upgrade took 3 months. We consolidated to 12 extensions that covered the same functionality. Upgrades now take 2 weeks. Same business outcomes, fraction of the maintenance.

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

How to prevent it: Before building any custom extension, ask: can this be done with standard configuration? If not, can we use AddOns or the Composable Storefront’s dependency injection instead of modifying core? Set a hard limit on custom extensions. I reckon 10-15 is a reasonable target for a mid-complexity project. Document the business justification for every single one.

To understand how Spadoom helps organisations keep customisation lean while getting the most from the platform, explore 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 (Gartner, 2024). Unclear requirements are the single biggest contributor to that failure rate.

“We want an e-commerce platform like Amazon.” That’s not a requirement. That’s a dream without a budget.

“We need a B2B storefront with customer-specific pricing, minimum order quantities, approval workflows, and integration with our SAP ERP for real-time inventory.” That’s a requirement. See the difference?

When business requirements are vague, the implementation team fills the gaps with assumptions. Those assumptions are often wrong. Three months later the gap becomes visible. And expensive. Rework, scope creep, a system that doesn’t match what users actually 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 should 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, returning items.

Mistake 5: Ignoring Performance Until It’s Too Late

Thirty-four per cent of B2B sales are now digital (McKinsey, 2024). A slow storefront means lost sales. Every 100ms of additional load time chips away at conversion rates.

Commerce Cloud performance depends on proper Solr/OpenSearch indexing, caching configuration, CDN setup, and efficient custom code. Many teams focus entirely on functionality during the build phase and only discover performance problems during load testing. Or worse, after go-live. By then you’re scrambling.

Common performance killers: unoptimised product queries, missing cache headers, excessive API calls per page load, large product 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. Target: page load under 2 seconds for product listing pages, under 1.5 seconds for product detail pages. Run load tests after every sprint, not just before go-live. Monitor Solr query times, cache hit rates, and API response times continuously.

Mistake 6: Under-Planning Data Migration

Fifty per cent of ERP implementations fail on their first attempt (Panorama Consulting, 2025). Bad data migration is a frequent cause.

Data migration for Commerce Cloud involves products, categories, prices, customers, orders (historical), and content (CMS pages, media). Each data type has its own import format (ImpEx), 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-time script exercise discover at UAT that 10% of products have broken images, customer accounts are duplicated, and historical orders don’t display correctly. By then the go-live date is in trouble.

How to prevent it: Budget migration as a separate workstream, not a task. Run at least three full migration cycles before go-live: first for structure validation, second for data quality verification, third as a dress rehearsal. Use ImpEx validation in dry-run mode. Verify image assets, category assignments, and price associations programmatically. De facto, this workstream needs its own timeline.

Mistake 7: Insufficient Testing

Nearly half of C-suite executives say more than 30% of their IT projects are over budget and late (BCG, 2024). Insufficient testing is how many of those overruns materialise. Bugs found late cost roughly 10x more to fix than bugs caught early.

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

The most dangerous gap: integration testing with ERP. Commerce Cloud sends orders to ERP and receives inventory, pricing, and shipping updates. If this integration isn’t tested under realistic conditions (concurrent users, peak volumes, error scenarios) the problems show up on launch day. And launch day is the worst time to find problems.

How to prevent it: Plan testing as 15-20% of total project effort. Start integration testing by mid-project, not the final week. Use automated test suites for regression testing on every deployment. Conduct UAT with actual business users running real scenarios, not the implementation team clicking through happy paths.

FAQ

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. Prevention is dramatically cheaper than cure. Every custom extension should have a documented business justification and an impact assessment on the upgrade path.

How long should an SAP Commerce Cloud implementation take?

Typical timelines: 4-9 months for a standard B2B or B2C storefront. Complex multi-country, multi-language implementations: 8-14 months. Average ERP implementation timelines have dropped from 15.5 months to 9 months with SaaS adoption (Panorama Consulting, 2025). Commerce Cloud benefits from the same trend.

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

If you’re running on-prem Hybris, the answer is almost certainly yes. SAP has announced end-of-mainstream-maintenance timelines that make staying on-prem increasingly risky and expensive. The question isn’t whether to migrate. It’s when and how.

How many custom extensions is too many?

There’s no absolute number, but 10-15 is manageable for most projects. Above 30, upgrade effort starts to compound. Above 50, each upgrade becomes 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 the implementation complexity goes up, so scope and budget accordingly.