5 Mistakes Companies Make When Migrating Off SAP Commerce On-Prem

We’ve migrated SAP Commerce platforms for Franke, ANWR, and Distrelec. Every project taught us something. But the most valuable lessons came from the mistakes we helped clients avoid — or recover from.

83% of data migration projects either fail or exceed their budgets and schedules (Bloor Group, 2023). SAP Commerce migrations are no exception. The five mistakes below explain why most of those projects go wrong — and how to stay on the right side of the odds.

TL;DR: 83% of data migrations exceed budgets (Bloor Group, 2023). From our SAP Commerce projects with Franke, ANWR, and Distrelec, the five most common mistakes are: replicating on-prem customisations 1:1, underestimating data migration, ignoring tech debt, using waterfall delivery, and starting too late. Agile approaches show 42% success rates vs 13% for waterfall (Standish Group, 2020). Start early, clean up first, deliver iteratively.

Why Do Companies Replicate On-Prem Customisations 1:1?

90% of businesses that migrated e-commerce platforms reported sales and revenue improvements (commercetools, 2024). But the single most expensive mistake is trying to bring everything along unchanged. Companies spend years building custom functionality on their on-prem platform. When migration time comes, the instinct is to move everything as-is to SAP Commerce Cloud.

The problem? Many of those customisations were workarounds for on-prem limitations that Commerce Cloud has already solved. Custom caching layers, manual scaling scripts, bespoke deployment pipelines — Commerce Cloud handles all of these natively.

We’ve seen migrations where 30–40% of custom code was unnecessary on the target platform. Every line of unnecessary code adds migration time, testing effort, and future maintenance cost.

What to do instead: Before migrating a single line of code, audit every customisation. Classify each one: still needed, replaceable by platform capability, or obsolete. We run a structured assessment that typically identifies 25–35% of customisations as removable. That directly reduces migration cost and timeline.

How Does Data Migration Derail Timelines?

83% of data migration projects either fail or exceed their budgets and schedules (Bloor Group, 2023). Data migration looks straightforward on paper: export from source, transform, import to target. In practice, it’s the phase that derails the most timelines.

The problems start with data quality. On-prem systems accumulate years of inconsistent data — duplicate customer records, orphaned product references, orders with missing attributes, catalogue structures that evolved without cleanup. A peer-reviewed study found 94% of business spreadsheets contain errors (Poon et al., Frontiers of Computer Science, 2024), and that messiness transfers directly to systems fed by spreadsheet imports.

Then there’s the volume. A mid-size B2B commerce platform might have 50 million order line items, 2 million customer records, and 500,000 product variants. Moving that data cleanly requires careful ETL design, multiple test runs, and a delta migration strategy for the cutover window.

One project we worked on had data spanning 15+ years of trading history. The data mapping alone took three weeks — and that investment saved us from a catastrophic data quality issue that would have surfaced post-go-live.

What to do instead: Start data discovery in week one. Profile your data for quality issues before you write a single migration script. Build delta migration capability from the start — you’ll need it. And budget 20–25% of your total migration effort for data work. If someone tells you data migration is “just an export/import,” they haven’t done one at scale.

What Happens When You Don’t Clean Up Tech Debt First?

47% of IT leaders cite technical debt as a primary driver of overspending on digital infrastructure (IDC, 2024). Migrating a messy system produces a messy cloud deployment. Tech debt doesn’t disappear when you change platforms — it follows you.

Common tech debt we see in SAP Commerce on-prem deployments:

• Unused extensions. Installed years ago for a feature that was later abandoned. Still loaded, still consuming resources, still creating dependency conflicts.
• Hardcoded configurations. Environment-specific values baked into code instead of externalised. Works on-prem where you control the infrastructure. Breaks on cloud where environments are dynamic.
• Outdated integrations. Connections to systems that have been replaced or decommissioned. The integration still runs, still generates logs, still adds complexity.
• Test data in production. Leftover from UAT cycles that was never cleaned up. Pollutes analytics and creates false dependencies.

One ANWR project phase required two weeks of cleanup before the actual migration work could begin. That upfront investment cut the migration timeline by a month because the team wasn’t debugging ghost dependencies during build.

What to do instead: Run a tech debt audit 2–3 months before migration starts. Remove unused extensions, externalise configurations, deprecate dead integrations, and purge test data. Treat this as a standalone deliverable with its own timeline and sign-off. The migration team should inherit a clean codebase, not a museum.

Why Does Waterfall Delivery Fail in Commerce Migrations?

Agile projects succeed 42% of the time compared to just 13% for waterfall (Standish Group CHAOS Report, 2020). That gap widens in commerce migrations, where three factors conspire against big-bang delivery:

1. Requirements shift during the project. Business needs evolve. SAP releases platform updates mid-migration. What you specified in month one may be obsolete by month five.
2. Late testing finds late problems. When you test everything at the end, issues compound. A data mapping error discovered in month eight requires rework across the entire build.
3. Big-bang cutovers are high risk. Switching every market, every storefront, and every integration in a single weekend creates maximum exposure. One failure affects everything.

The Franke migration succeeded in 90 days partly because we delivered iteratively. Core platform first, then storefronts, then integrations — each phase tested and validated before the next one started.

What to do instead: Break the migration into 2–4 week delivery cycles. Each cycle produces a working, testable increment. Prioritise by business value: migrate your highest-traffic storefront first, get it stable, then expand. Use feature flags to control rollout. This approach finds issues earlier, spreads risk, and gives stakeholders visible progress from week two.

What’s the Real Cost of Starting Too Late?

This is the meta-mistake — and the most common one. Companies know about the EoMM deadline. They discuss it in steering committees. They add it to risk registers. And then they don’t act until it’s too late for a comfortable timeline.

A rushed migration is an expensive migration. Here’s what happens when you start too late:

• No time for cleanup. You migrate the mess as-is, then spend months fixing it in the cloud.
• Premium rates for talent. Every implementation partner is fully booked. You pay surge pricing for availability.
• Compressed testing. Corners get cut. Issues that should be caught in QA reach production.
• No fallback plan. If something goes wrong in a rushed cutover, there’s no buffer for recovery.

We see companies that start 12 months before EoMM complete their migrations for 30–40% less than those who start with 4 months to go. The work is the same. The cost difference comes entirely from pace, planning, and the availability of the right people.

What to do instead: Start now. Not next quarter. Now. Even if the migration itself takes only 90 days — as it did for Franke — you need time for assessment, cleanup, vendor selection, and team alignment. A 90-day migration requires a 30–60 day preparation phase. Build that into your timeline.

What Pattern Connects All Five Mistakes?

Every mistake on this list shares a root cause: treating migration as a technical exercise instead of a business transformation. 90% of businesses that migrated platforms reported revenue improvements (commercetools, 2024) — but only when they approached the move strategically.

The companies that migrate smoothly are the ones that:

• Audit before they build
• Clean up before they move
• Deliver in increments instead of big bangs
• Start early enough to have options

We’ve delivered SAP Commerce migrations for ANWR, Franke, Distrelec, and others — each with different constraints, timelines, and architectures. The common thread across successful projects is discipline in preparation.

For a complete picture of Spadoom’s SAP Commerce Cloud capabilities — from migration planning to Composable Storefront delivery — visit our SAP Commerce Cloud solution page.

Planning a SAP Commerce migration? We run structured migration assessments that identify removable customisations, profile data quality, and estimate realistic timelines. Get in touch — let’s make sure your migration lands on the right side of these five lessons.

Frequently Asked Questions

How long does a typical SAP Commerce Cloud migration take?

It depends on complexity, but our fastest migration (Franke) completed in 90 days. Most mid-size B2B platforms take 4–6 months including the preparation phase. The biggest variable isn’t platform size — it’s how much tech debt and custom code exists. Companies that run a cleanup phase first typically shave 20–30% off the build timeline.

What’s the difference between SAP Commerce on-prem and SAP Commerce Cloud?

SAP Commerce Cloud is the managed, cloud-hosted version of SAP Commerce. It handles infrastructure, scaling, deployments, and security patches automatically. On-prem gives you full control but requires you to manage all of that yourself. With SAP’s End of Mainstream Maintenance (EoMM) approaching, on-prem customers need to plan their move to Commerce Cloud or an alternative platform.

How much does a SAP Commerce migration cost?

Costs vary widely based on customisation volume, data complexity, and integration count. A useful benchmark: budget 20–25% of total effort for data migration alone. Companies that start early (12+ months before deadline) typically spend 30–40% less than those who rush. The migration assessment is the best first step — it produces a realistic cost estimate based on your actual codebase.

Can we migrate SAP Commerce in phases instead of all at once?

Yes, and we strongly recommend it. Iterative delivery — migrating one storefront or market at a time — reduces risk and finds issues earlier. Agile approaches have a 42% success rate compared to 13% for waterfall (Standish Group, 2020). Feature flags let you control rollout without big-bang cutovers.

What should we do about customisations during migration?

Don’t assume every customisation needs to move. In our experience, 25–35% of on-prem customisations are unnecessary on SAP Commerce Cloud because the platform handles them natively. Before migrating code, run a structured assessment: classify each customisation as still needed, replaceable by platform capability, or obsolete. This single step has the largest impact on reducing migration cost and timeline.