SAP Commerce On-Premise After 31 July 2026: What Changed and Your Four Options

Mainstream maintenance for SAP Commerce on-premise, the platform many teams still call Hybris, ended on 31 July 2026 (SAP Help Portal). Release 2205 was the last on-premise release, and SAP has not planned another. This page is our running guide for everyone still on it: what changed, what support is left, and how the realistic options compare.

Nothing broke on 1 August. Storefronts stayed up and orders kept flowing, which is exactly why this phase is easy to underestimate. The cost of staying does not show up as an outage. It shows up as open vulnerabilities, compliance work your team now owns, and a migration that gets harder to staff every quarter.

TL;DR: Since 31 July 2026, SAP Commerce on-premise (release 2205) runs on customer-specific maintenance: known problems are still resolved, but there are no support packages, legal changes or library updates, and new problems may cost extra. You have four options: run on as a time-boxed bridge, rely on customer-specific maintenance while you plan, migrate to SAP Commerce Cloud (or, if you run S/4HANA Public Cloud, the new ERP Edition), or replatform off SAP. For most SAP-integrated B2B shops, migrating within the SAP stack keeps the ERP integration and costs least in total. Talk to us about your estate.

What changed on 1 August 2026

“End of mainstream maintenance” is precise SAP vocabulary. Since 1 August 2026, for SAP Commerce on-premise:

• No new support packages or security patches. When the next vulnerability lands in the platform or a bundled library (Spring, Solr, Apache components), SAP will not ship a fix for 2205. The system that holds customer accounts and touches payment flows accumulates open issues from here on.
• No legal and tax changes. VAT rate changes, invoicing rules and privacy-driven adjustments are now custom development on your side, multiplied by the number of countries you sell in.
• No third-party library updates and no new Java versions. SAP will not test or certify new JVM releases for on-premise. The runtime you have today ages in place.
• No new technology or interface updates. As payment, logistics and ERP partners update their APIs, keeping integrations working is your job.
• No new storefront features. SAP Composable Storefront (formerly Spartacus) and new capabilities such as AI-driven merchandising are developed for SAP Commerce Cloud (SAP Help Portal).

SAP’s End of Mainstream Maintenance FAQ is the reference for the product-specific details; check it before you commit a budget.

What customer-specific maintenance still covers

After mainstream maintenance, SAP releases move into customer-specific maintenance automatically. Per SAP’s own definition (SAP Support, customer-specific maintenance):

• It continues under your existing support agreement; there is no separate contract.
• Problem resolution covers known problems. Resolving new problems may be subject to an additional fee.
• There are no legal changes, no new support packages and no guaranteed technology updates such as new database, operating system or Java versions.

In other words, you keep a support channel, but not a maintained product. That is useful as a bridge while a migration runs. It is not a place to stay for years, and it is the reason we no longer describe the on-premise path as “extended support”: there is nothing being extended, only a narrower service.

Where the cost of staying hides

The licence invoice is the visible part. Most of the cost of running on-premise after EoMM sits in lines that rarely appear in the same spreadsheet:

Cost line	On-premise after EoMM	SAP Commerce Cloud
Infrastructure (production, staging, development, disaster recovery)	You own hosting, network and uptime	Included in the subscription
Security patching	Your team builds and tests fixes, or accepts the risk	Delivered by SAP with platform updates
Tax, legal and Java updates	Custom development	Delivered by SAP
Operations	Dedicated platform staff	Smaller, focused on business logic
Specialist talent	A shrinking pool of on-premise developers	A larger Commerce Cloud talent pool
Feature backlog	Every new capability is a custom project	Regular platform releases

We deliberately do not put generic CHF figures on this table: they depend on your deployment, the number of storefronts and how much of the operation you run yourself. What we do in an assessment is fill it in with your numbers. Our SAP Commerce Cloud pricing and TCO guide explains how the subscription side is structured.

Two costs deserve a separate mention. Talent: fewer developers want to work on an unsupported platform, and if one person holds the critical knowledge of your customisations, that is a business risk. Opportunity cost: every feature the business asks for (a new checkout flow, a PWA frontend, B2B self-service) turns into a custom build on a frozen platform.

Option 1: Run on and absorb the risk

This is the default, because it requires no decision, and it is the only option whose cost grows every month.

For a small, low-change B2B shop behind a hardened network, running on for a few more months while a migration is prepared can be a defensible, calculated risk. Running on with no migration plan is a deferred incident. The exposure compounds: every unpatched vulnerability stays unpatched, compliance work shifts to your team, and your audit position weakens. “We process payments on software that is no longer maintained” is a sentence your CISO will have to say out loud at some point.

Choose this only as an explicit, time-boxed bridge with a signed-off risk assessment, while one of the other options is already in motion.

Option 2: Customer-specific maintenance as a planned bridge

In practice this runs alongside option 1: you are on customer-specific maintenance whether you chose it or not. The difference is whether you use it deliberately. It buys a support channel for known problems and a vendor you can still call. It does not buy new features, security patches or a roadmap.

It makes sense in one scenario: a large, complex estate that cannot migrate inside 12 months (regulatory freeze, M&A, a parallel ERP programme) and needs a documented bridge. If that is you, clarify with SAP now how new problems would be handled and priced for your contract, rather than after the first incident, and put the end of the bridge on the same board slide as the migration start date.

Option 3: Migrate to SAP Commerce Cloud

The natural path, and the one where your existing investment survives: data model, business logic, much of the customisation and, above all, the ERP integration carry over. It is also the option we know best, so weigh our view accordingly and check it against the references.

• Franke: we took over a stalled legacy commerce platform and brought SAP Commerce Cloud live in 90 days. The commerce launch won the SAP Quality Award for “Rapid Time to Value”, and manual orders dropped by about 75%. The 90-day playbook describes the method.
• ANWR Group: a headless B2B/B2C platform on SAP Commerce Cloud managing more than 5 million product SKUs, with 80% faster product data synchronisation.
• Distrelec: from a monolithic SAP Commerce setup to a headless architecture, with 70% faster time-to-market and a 15% higher conversion rate.

Realistic timelines: 6 to 12 months for a typical migration, 4 to 6 months for a disciplined fast-track, 90 days at the aggressive end with full preparation.

If you migrate, prepare like this. Most of the time and money in a migration is decided before the first line of code moves:

1. Audit every customisation. Classify each one as still needed, replaceable by a standard platform capability, or obsolete. Custom caching, scaling scripts and deployment pipelines are typical on-premise workarounds that Commerce Cloud handles natively.
2. Map every integration. ERP, PIM, CRM, payment, logistics: this is where the surprises hide.
3. Profile your data early. Years of duplicates, orphaned references and inconsistent catalogue structures do not improve by moving.
4. Clean up before you move. Remove unused extensions, externalise hard-coded configuration, retire dead integrations and purge old test data.
5. Deliver iteratively. Core platform first, then storefronts and markets one by one, rather than one big-bang weekend.

We cover these in detail in the five most common SAP Commerce migration mistakes and the step-by-step SAP Hybris migration checklist.

The ERP Edition angle. A frequent objection from mid-sized on-premise shops was that full Commerce Cloud is sized and priced for enterprises. SAP Commerce Cloud, ERP Edition, announced in May 2026, changes that calculation for companies on SAP S/4HANA Public Cloud: a packaged B2B commerce layer that works through ERP-native screens, with SAP carrying much of the integration (DSAG impulsant, in German). Spadoom is one of the first pilot partners, with a Swiss mid-market B2B customer; we describe what the ERP Edition changes for SMEs here. If your ERP is still ECC, the commerce decision and the ERP decision belong together, and our S/4HANA readiness assessment is the sensible first step. The Commerce Cloud and S/4HANA Public Cloud B2B guide shows how the two fit.

Option 4: Replatform off SAP

Leaving SAP Commerce is a legitimate option, and for some companies the right one. If your commerce needs have simplified to what Shopify Plus does out of the box, or your architecture strategy is genuinely composable and you have the engineering organisation to own it, a replatform deserves a real evaluation. Our view on when composable commerce makes sense in B2B goes through the criteria.

Put numbers on the items that replatform pitches tend to leave out:

• ERP integration rebuild. Pricing, availability checks, credit checks, order orchestration and master data are the most valuable and least visible part of your current platform. On a replatform you rebuild them, usually via middleware that becomes its own project.
• B2B depth. Contract pricing, punch-out, approval workflows and multi-level account structures are mature in SAP Commerce and often add-ons or custom builds elsewhere.
• The data work does not shrink. Catalogue, customer and order data still have to move; you add the integration workstream on top.
• Timeline. Replatform projects for an SAP-integrated estate typically run 6 to 12 months or longer, the same window as an SAP-to-SAP migration, without the carry-over.

If you run SAP ERP and your B2B requirements are real, the total cost of ownership usually favours staying in the SAP stack. If you do not, run the evaluation and ask every vendor for integration line items, not just licence comparisons.

The timeline math, side by side

Path	Time to a maintained state	Exposure while you wait	What you have at the end
Run on	Never	Grows indefinitely	The same platform, older
Customer-specific maintenance as a bridge	Immediate, but reduced scope	Known problems covered, new ones may cost extra	A support channel, no roadmap
Migrate to Commerce Cloud or ERP Edition	3 to 12 months	Limited to the project length	A maintained, evolving platform; investment carried over
Replatform off SAP	6 to 12 months or more	Limited to the project, usually longer	A new platform, rebuilt integrations, a new learning curve

Three of the four paths include months on a platform that no longer gets patches. That exposure started on 1 August whether you decided anything or not. What you still control is how long it lasts.

What we would do in your position

First week: a two-page risk assessment of the current estate, covering versions, customisation surface, integration inventory and compliance obligations. First month: a decision between customer-specific maintenance as a bridge, migration and replatform, with real quotes on the table rather than directional estimates. The order matters, because partner delivery slots get scarcer as more of the waiting companies move at once. If you are still comparing implementation partners, our overview of SAP Commerce Cloud partners in Switzerland sets out what to check.

We run this assessment as a fixed-scope engagement. The support ended; the options did not. They now come with a clock.

Request a migration assessment, read more on our SAP Commerce Cloud solution page or start with the on-premise decision page.