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

We have delivered SAP Commerce projects for Franke, ANWR and Distrelec, each with different constraints, timelines and architectures. The most useful lessons did not come from what went well. They came from the mistakes we helped clients avoid, or recover from when they had already made them.

Since mainstream maintenance for SAP Commerce on-premise ended on 31 July 2026 (SAP Help Portal), many companies are now planning the move under time pressure. That is exactly when these five mistakes get made. For the overall options (run on, bridge, migrate or replatform), start with our guide to SAP Commerce on-premise after end of mainstream maintenance. This post is about doing the migration well.

TL;DR: The five mistakes that make SAP Commerce migrations slow and expensive are: copying on-premise customisations 1:1, underestimating the data migration, moving tech debt instead of removing it, delivering in one big bang, and treating customer-specific maintenance as a plan. Each one is avoided in the preparation phase: audit customisations, profile data in week one, clean up first, deliver in increments and fix a date.

Mistake 1: Replicating on-prem customisations 1:1

The single most expensive mistake is trying to bring everything along unchanged.

Companies spend years building custom functionality on their on-premise platform, and when migration time comes, the instinct is to move all of it. That is understandable: every customisation was built for a reason. But many of them were workarounds for on-premise limitations that SAP Commerce Cloud has already solved. Custom caching layers, manual scaling scripts and bespoke deployment pipelines are handled by the platform.

Every line of code you carry over without need adds migration time, testing effort and future maintenance cost, and it makes each later upgrade harder (the same effect we describe in the seven SAP Commerce Cloud mistakes that derail projects).

What to do instead: Before migrating a single line of code, audit every customisation and classify it: still needed, replaceable by a standard platform capability, or obsolete. Only the first group moves. In our assessments this list is almost always shorter than the client expected, and every item removed shortens the project.

Mistake 2: Underestimating the data migration

Data migration looks straightforward on paper: export, transform, import. In practice it is the phase that derails the most timelines.

The problems start with data quality. On-premise systems accumulate years of inconsistent data: duplicate customer records, orphaned product references, orders with missing attributes and catalogue structures that grew without cleanup. Then there is volume. A mid-sized B2B platform can carry many millions of order lines, and moving them cleanly takes careful ETL design, several test runs and a delta strategy for the cutover window.

On long-running platforms with many years of trading history, the data mapping alone can take weeks. That time is not lost: it is what stops a data quality problem from surfacing after go-live.

What to do instead: Start data discovery in week one. Profile your data for quality issues before you write a migration script, and build delta migration capability from the start because you will need it. Plan data work as its own workstream with its own budget and owner. If someone tells you data migration is “just an export and import”, they have not done one at scale.

Mistake 3: Migrating tech debt instead of removing it

Migrating a messy system produces a messy cloud deployment. Tech debt does not disappear when you change platforms; it follows you.

The tech debt we most often find in SAP Commerce on-premise deployments:

• Unused extensions. Installed years ago for a feature that was later abandoned, still loaded, still creating dependency conflicts.
• Hard-coded configuration. Environment-specific values baked into code instead of externalised. That works on-premise, where you control the infrastructure, and breaks in the cloud, where environments are provisioned for you.
• Outdated integrations. Connections to systems that have been replaced or switched off, still running and still adding complexity.
• Test data in production. Left over from old acceptance tests, polluting analytics and creating false dependencies.

Time spent cleaning up before the build starts pays back during the build, because the team is not chasing ghost dependencies.

What to do instead: Run a tech debt audit before the migration starts. Remove unused extensions, externalise configuration, retire dead integrations and purge test data. Treat it as a standalone deliverable with its own sign-off. The migration team should inherit a clean codebase, not a museum.

Mistake 4: Delivering in one big bang

Large technology programmes have a poor track record: BCG found that more than two thirds of large-scale tech programmes are not expected to be delivered on time, within budget or within their planned scope (BCG, 2024). In commerce migrations, three things work against a single big-bang delivery:

• Requirements shift during the project. The business keeps moving, and SAP ships platform updates mid-migration. What you specified in month one may be outdated by month five.
• Late testing finds late problems. A data mapping error discovered in the final month means rework across the entire build.
• Big-bang cutovers concentrate risk. Switching every market, storefront and integration in one weekend means one failure affects everything.

The Franke commerce launch in 90 days worked because it was delivered in parallel, tested increments rather than one final switch; the 90-day playbook describes the approach.

What to do instead: Break the migration into delivery cycles of two to four weeks, each producing a working, testable increment. Prioritise by business value: migrate your highest-traffic storefront first, stabilise it, then expand. Test the ERP integration under realistic load from the middle of the project, not in the last week. Use feature flags to control the rollout.

Mistake 5: Treating customer-specific maintenance as a plan

Before 31 July 2026, this mistake was called “starting too late”. Now it has a new form: because the platform still runs and SAP still resolves known problems under customer-specific maintenance, it is tempting to treat that phase as a comfortable waiting room.

It is not. Customer-specific maintenance brings no new support packages, legal changes or library updates, and resolving new problems can carry a fee (SAP Support). Meanwhile a rushed migration is an expensive one: no time for cleanup, compressed testing, no fallback plan for cutover and higher rates because experienced SAP Commerce teams are booked by those who moved earlier.

What to do instead: Fix a target date and work backwards. Even a fast migration needs a preparation phase for assessment, cleanup and partner selection before the build starts. If you are still choosing an implementation partner, our overview of SAP Commerce Cloud partners in Switzerland lists what to check. The step-by-step SAP Hybris migration checklist covers the rest.

What connects all five mistakes

Every mistake on this list has the same root cause: treating the migration as a technical copy job rather than a chance to simplify. The companies that migrate smoothly audit before they build, clean up before they move, deliver in increments and fix a date early enough to have options.

One more point for companies on SAP ERP: most migration surprises sit at the seam between commerce and ERP (prices, availability, order transfer), not inside the shop. If an S/4HANA move is also on your roadmap, plan both together; our guide to SAP Commerce Cloud with S/4HANA Public Cloud in B2B shows how the two fit.

For our full SAP Commerce Cloud offering, from migration planning to Composable Storefront delivery, see our SAP Commerce Cloud solution page.

---

Planning an SAP Commerce migration? We run structured migration assessments that identify removable customisations, profile data quality and estimate a realistic timeline. Get in touch.

Frequently Asked Questions

How long does a typical SAP Commerce Cloud migration take?

Typical migrations take 6 to 12 months, disciplined fast-track projects 4 to 6. At the aggressive end, we brought Franke’s SAP Commerce Cloud platform live in 90 days. The biggest variable is not platform size but how much tech debt and custom code you carry over, which is why the preparation phase matters most.

What is the difference between SAP Commerce on-premise and SAP Commerce Cloud?

SAP Commerce Cloud is the SAP-managed, cloud-hosted version of SAP Commerce: SAP runs the infrastructure, scaling, deployments and platform updates. SAP Commerce on-premise (last release 2205) left mainstream maintenance on 31 July 2026 and now only receives customer-specific maintenance, so no new support packages, legal changes or library updates.

How much does an SAP Commerce migration cost?

It depends mainly on the number of customisations, integrations, storefronts and the state of your data, so a credible figure needs an assessment of your codebase. The largest savings come from removing customisations and data you do not need before the migration starts, not from negotiating the build rate.

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

Yes, and we recommend it. Migrate the core platform first, then one storefront or market at a time, each tested before the next starts. Feature flags let you control the rollout without a big-bang weekend cutover.

What should we do with our customisations during the migration?

Do not assume every customisation needs to move. Classify each one as still needed, replaceable by a standard platform capability, or obsolete. Many on-premise customisations, such as custom caching, scaling scripts and deployment pipelines, are handled natively by SAP Commerce Cloud.