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

We have migrated SAP Commerce platforms for companies like 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.

Here are the five most common mistakes companies make when migrating off SAP Commerce on-prem. Each one is preventable if you know what to watch for.

Mistake 1: Replicating on-prem customisations 1:1 in the cloud

This is the single most expensive mistake. 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 have 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.

Mistake 2: Underestimating data migration complexity

Data migration looks straightforward on paper: export from source, transform, import to target. In practice, it is 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 have evolved without cleanup.

Then there is 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 Distrelec-related 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 will 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 have not done one at scale.

Mistake 3: Not cleaning up tech debt before migrating

Migrating a messy system produces a messy cloud deployment. Tech debt does not 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 was not 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.

Mistake 4: Choosing a waterfall approach instead of iterative delivery

The classic plan: spend 3 months on requirements, 4 months on build, 2 months on testing, then a big-bang go-live. We have seen it. It fails at scale.

Waterfall fails in commerce migrations for three reasons:

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.

Mistake 5: Waiting too long and rushing under deadline pressure

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 do not act until it is too late for a comfortable timeline.

A rushed migration is an expensive migration. Here is 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 is 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.

The pattern behind all five mistakes

Every mistake on this list shares a root cause: treating migration as a technical exercise instead of a business transformation. 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 have 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.

Ready to avoid these mistakes?

If you are planning a SAP Commerce migration, start with a migration assessment. We will audit your customisations, profile your data, estimate your timeline, and identify the pitfalls specific to your setup.

Get in touch — let’s make sure your migration lands on the right side of these five lessons.