Ante PrimoracSAP Commerce on-premise EOL arrived on July 31, 2026, when version 2205, the final on-premise release, reached the end of mainstream maintenance. For enterprise B2B teams still running SAP Commerce (Hybris, if you have been on it long enough to remember the old name), this is a hard deadline. No more regular security updates. Growing operational risk. Increasing dependency on specialist knowledge that gets scarcer every year.
The natural instinct is to treat this as a platform selection exercise: evaluate SAP Commerce Cloud, a SaaS alternative, a composable stack, or an open-source option. That instinct is expensive. Here is the decision you are actually making, even if it does not look like one yet: you are choosing between funding the rebuild of real business logic and funding the rebuild of workaround code. If you start with platform selection, you will fund both.
The classification comes first
A mature SAP Commerce build is two things sharing one codebase. Part of it is differentiated business logic: the contract pricing rules, multi-step approval chains, procurement integrations, and account hierarchies that actually run your business. The other part is workaround code: the type-system gymnastics, impex import pipelines, and deep Accelerator overrides you wrote to bend the old platform into something that fit your operating model.
Scope a migration by feature parity and you fund the rebuild of both. You pay, a second time, to reconstruct the scaffolding the old platform forced on you.
The first job is not picking a target. It is sorting everything you have into three buckets.
Three buckets: retire, redesign, adopt
Retire. Workaround code that exists only because the old platform resisted your business model. The tell is mass: when a customisation grew until it was more code than the thing it customised, that mass is almost entirely workaround. It carries no business meaning. You stop carrying it, and you stop paying engineers to maintain it, forever.
Redesign. Differentiated business logic comes with you, but redesigned natively on the new platform. Most of your current implementation of these rules is tangled together with bucket-one workaround code. Rebuild the rule cleanly on a platform that lets it be expressed directly, and you keep the business logic while shedding the scaffolding.
Adopt. Commodity functions: cart mechanics, tax calculation, standard checkout flow, search plumbing. You almost certainly customised some of this once and maintained it ever since. None of it differentiates you. Take the platform version and stop owning a private copy of solved problems.
The discipline is in being honest. Every team over-fills the redesign bucket because every customisation feels essential to the person who wrote it. Redesign should be the smallest of the three. If it is not, you have not sorted hard enough yet.
The platform choice follows the sort
Once the classification is done, the platform decision organises itself. Four paths emerge:
Stay ERP-subordinate. Move to SAP Commerce Cloud and keep commerce as a satellite of the ERP suite. This is the path of least political resistance. It also preserves the exact architecture constraints you may be trying to escape: a commerce frontend whose data model was built for the back office, not for the buyer experience.
Standard SaaS. Shopify Plus or BigCommerce Enterprise. Fast to stand up, genuinely good for the commodity bucket. But your differentiated business logic does not fit fixed models, and you start writing workarounds again. You have rebuilt the prison with a nicer paint job.
Composable DIY. Maximum flexibility, assembled from best-of-breed services. 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.
Code-first open-source. One coherent backend you can change at the core, with commodity handled out of the box. This is the path where your redesigned business logic gets rebuilt cleanly, not boxed in again by a fixed data model. The backend bends to your business instead of the reverse.
The classification should determine which quadrant you land in. If your redesign bucket is small, SaaS works. If it is substantial, code-first open-source is the only path where native redesign is a real option.
The costs nobody budgets
When this reaches your CFO, the headline is straightforward: migration cost concentrates in two places, and neither of them is licences.
The first is redesigning differentiated business logic. That is real engineering on the rules that set you apart, and it is money well spent.
The second is re-integration, and most plans underestimate it. ERP integration was never free configuration, even inside SAP’s own suite. SAP Commerce and S/4HANA never shared a data model for customer 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. It always was.
Sequencing the cutover
You do not need a single big-bang switchover. The pattern that de-risks a migration of this scale is the strangler fig: stand the new backend up alongside SAP and move capability by capability.
Move data in the order of how stateful and unforgiving each domain is. Catalogue first: largely static, easy to validate, low blast radius. Pricing next: more logic but reproducible offline. Accounts after that: hierarchies and permissions, where your redesign decisions start to bite. Open orders last, always: they are live, stateful, and migrating an in-flight order is migrating a moving target.
Run both systems through the cutover. That parallel period is what lets you roll back a single slice without rolling back the entire project. That is the difference between a contained incident and a board-level one.
SAP Commerce on-premise EOL: sort first, decide second
An SAP Commerce on-premise EOL migration is a sorting exercise before it is a platform decision. Retire the workarounds, redesign the differentiators natively, adopt the commodity. The platform choice follows the classification, not the reverse. Get the sort right and the migration scopes itself.
