How to Plan a SAP Commerce Migration: What to Retire, Redesign, and Rebuild
Most teams scope a SAP Commerce migration the same way: inventory everything the current system does, then plan to rebuild all of it on the new platform. Feature parity as the spec. It feels safe, and it is the most expensive mistake you can make.
A mature SAP Commerce build (SAP Hybris, if you've been running it long enough to remember the old name) is two things wearing one codebase. Part of it is real business logic: the rules that run your contract pricing, your approval chains, your account hierarchies. The other part is workaround code, the type-system gymnastics and impex pipelines and Accelerator overrides you wrote to bend an old platform into a shape it resisted. Scope by parity and you fund the rebuild of both. You pay, a second time, to reconstruct your own prison.
The trap gets worse on on-premise. If you're still running an Accelerator-based storefront, you aren't facing one migration. You're facing two rebuilds at once: the platform move and a full frontend rebuild that the old architecture coupled together. Parity-thinking treats that as one line item to reproduce. That's the budget detonator.
So the first job in a SAP Commerce migration is not choosing a platform. It's classifying what you already have. (If you haven't yet settled the question of whether to move, our companion piece on life after SAP Commerce on-premise makes that case. This article assumes the decision is made and you own the how.)
The Classification: Retire, Redesign, Adopt
Every customisation in your current build goes into one of three buckets. Get the sorting right and the migration scopes itself.
Bucket one, workaround code, retire it: This is code that exists only because the old platform fought you. It has no reason to exist on a backend you can change at the core. The Hybris-flavoured examples are familiar:
- Type-system gymnastics to model something the type system resisted, custom items and relations layered on to express a structure that should have been native.
- Impex import pipelines built to force-feed data the platform couldn't ingest cleanly.
- Deep Accelerator overrides where you rewrote half the storefront to change behaviour the framework wouldn't let you reach otherwise.
The tell is mass. When a customisation grew until it became more code than the thing it customised, that mass is almost entirely workaround. It carries no business meaning. It is the cost of the old platform, and on the new one it simply stops existing. This is the bucket that funds the migration, the weight you put down rather than carry across.
Bucket two, differentiated business logic, redesign it natively: This is the logic that actually runs your business and that your competitors don't have. Contract pricing with customer-specific terms. Multi-step approval chains. Procurement and punchout integration. Account hierarchies that mirror how your buying organisations are actually structured. This comes with you. It is the reason you're a hard account to displace.
But it comes across redesigned, not ported line for line. Most of your current implementation of these rules is tangled together with bucket-one workaround code, because the old platform forced the rules and the workarounds into the same files. Rebuild the rule cleanly on a platform that lets it be expressed directly, and you keep the business logic while shedding the scaffolding it was trapped in.
Bucket three, commodity, adopt the default: Cart mechanics. Tax calculation. Standard checkout flow. Search plumbing. You almost certainly customised some of this once, and you've maintained it ever since. None of it differentiates you. Take the platform's version and stop paying to own a private copy of solved problems.
The discipline is in being honest. Most teams over-fill bucket two, because every customisation feels differentiated to the person who wrote it. The skill, and it is a skill, is admitting that a given chunk is actually a workaround you can retire, or a commodity you can adopt. Bucket two should be the smallest of the three. If it isn't, you haven't sorted hard enough yet.
Choosing the Target Path
Now the classification drives the platform decision, instead of the other way round. Picture the target on two axes: how much control you keep over the core, and how much you assemble yourself versus get out of the box. Four patterns fall out.
- Stay ERP-subordinate: Commerce remains a satellite of the suite. This is the path of least political resistance because nobody has to defend a new vendor. It also keeps the exact constraints you're migrating to escape. Your bucket-two logic stays boxed in by a data model that was built for the back office, not for commerce.
- Standard SaaS: Fast to stand up, and genuinely good for the commodity. But your differentiated bucket-two logic doesn't fit the fixed model, so you start writing workarounds again. You've rebuilt the prison with a nicer paint job.
- Composable DIY: Maximum flexibility, assembled from best-of-breed parts. You can express any rule you like, but now you own the integration burden between every piece. The workaround mass you just retired comes back as glue code between services.
- Unified and flexible: One coherent backend you can change at the core, with the commodity already handled out of the box. This is the quadrant Vendure occupies, and it's the only one where bucket two gets redesigned natively without you assembling the entire stack yourself. Catalogue, pricing, orders, customers, and your business logic live in one extensible core rather than a web of integrations you maintain.
That last point is the one that ties back to the classification. "Redesign natively" is only a real option on a platform you can change at the core level. On a rigid system, your differentiated rules become workarounds the moment they don't fit the fixed model, and you're sorting the same mess again in three years. Native redesign pays off exactly once: when the platform bends to your business instead of the reverse. That is also where speed comes from: on a unified backend, a change to pricing or approval logic ships as one coordinated release, not a negotiation across half a dozen services.
Sequencing the Cutover
You don't have to bet the business on a single big-bang switchover. The pattern that de-risks a SAP Commerce migration is the strangler fig: stand the new backend up alongside the existing system and move capability by capability, not all at once.
Move the data in the order of how stateful and unforgiving each domain is:
- Catalogue: Largely static, easiest to validate, lowest blast radius.
- Pricing: More logic, but still reproducible and testable offline.
- Accounts: Hierarchies and permissions, where your bucket-two structure starts to bite.
- Open orders: Last, always. They're live, stateful, and unforgiving. Migrating an in-flight order is migrating a moving target.
Run the new backend alongside SAP through the cutover. That parallel period is what lets you roll back a single slice without rolling back the whole project, which is the difference between a contained incident and a board-level one.
Parity testing matters here, but only where it earns its keep: on the differentiated bucket-two logic. Verify that contract pricing produces the same numbers and approval routing sends the same requests to the same approvers. Don't spend the quarter regression-testing the commodity cart you deliberately adopted from the platform. You changed it on purpose.
Feasibility at scale is not the open question. Munch runs its marketplace on Vendure across four countries, peaking around 10,000 payment transactions a day. The question a SAP Commerce migration has to answer is one of sorting and sequencing, not whether the target can carry the load. Vendure is currently working with companies migrating their commerce stack off SAP, so the path is one others are walking now.
Where Cost and Risk Actually Live
When this reaches your CFO, the headline is simple: the cost of a SAP Commerce migration concentrates in two places, and neither is licences.
The first is redesigning the bucket-two logic. That's real engineering on the rules that differentiate you, and it's money well spent because you're rebuilding the assets, not the scaffolding.
The second is re-integration, and it's the one most plans underestimate. Integration was never free configuration, even inside a single vendor's own suite. SAP Commerce and S/4HANA never shared a data model for customer and business-partner master data. Commerce thinks in Customers and B2B Units; the ERP thinks in Business Partners with Sold-to, Bill-to, and Ship-to roles. Connecting them always meant a real synchronisation layer with field mapping and conflict resolution. The "one SAP family" was custom integration work, not a setting you switched on. Whatever you migrate to, budget integration as engineering, because it always was.
The savings hide in the retire bucket: the workaround mass you stop carrying, and stop paying engineers to maintain, forever.
The real risk is mis-sorting. Tag a differentiated rule as commodity and you quietly lose a business rule your customers depend on. Tag a workaround as differentiated and you pay to rebuild your prison brick by brick. The classification isn't a planning step you do once and file. It's the thing that determines whether the migration costs what it should.
The Platform Choice Follows the Sort
A SAP Commerce migration is a sorting exercise before it is a platform decision. Separate the customisations that are real business logic from the ones that exist only to work around the old platform, and the rest of the project organises itself: retire the workarounds, redesign the differentiators natively, adopt the commodity. The platform decision follows the classification, not the reverse, and the right target is the one where your differentiated logic gets rebuilt cleanly instead of boxed in again.
Sort that right and the migration scopes itself.
If you want to sort your own build into the three buckets and pressure-test the path off SAP for your business, discuss your migration path.
Further Reading
Share this article
