SAP Hybris End of Life 2026: Why you migrate the PIM first — and the shop second

eCommerce

On 31 July 2026, mainstream maintenance ends for SAP Commerce on-premise (version 2205) — the last on-prem release of the platform formerly known as Hybris. The deadline applies to the on-premise line only; SAP Commerce Cloud keeps shipping quarterly updates. If you face a replatforming decision in 2026, that is a window, not an emergency exit. And the most important switch you set is not at the shop layer — it is one floor below, in your product data architecture.

What really ends on 31 July 2026 — and what does not

SAP has scheduled the end of mainstream maintenance for SAP Commerce on-premise on 31 July 2026. The authoritative announcement lives in the SAP Help Portal under the title “End of Mainstream Maintenance for SAP Commerce” (help.sap.com). It affects version 2205, the final on-premise release, shipped in May 2022.

Concretely, what ends:

• Security patches** for the on-premise codebase
• Bug fixes** and compliance updates
• JVM and third-party library support** within the certified matrix
• New functionality** — features have only landed in the cloud line since 2022 anyway
• The ability to build new applications on the EoMM version (per SAP KBA 3242156)

What does NOT end: SAP Commerce Cloud (Public Cloud) continues to receive quarterly updates. If you sit on the cloud variant — after a 2024 or 2025 lift-and-shift, say — the EoMM does not affect you. The 2026 deadline is a classical on-premise story: hosted in your own data center or with a hosting partner, your own application stack, your own release cadence.

An extended maintenance track, of the kind SAP offers for ECC or S/4HANA, has not been announced for SAP Commerce under the current maintenance strategy. Customer-Specific Maintenance exists as a formal option but is not a true extension — no guarantee of new patches, no legal changes, no recertification against current OS and database stacks. It buys time, not safety.

SAP’s own recommended migration path is unambiguous: SAP Commerce Cloud (Public Cloud, current release line) with SAP Composable Storefront — the official headless frontend, formerly Spartacus, Angular-based (SAP Community Blog). The cloud variant is a target option, not an automatic one. Whether it is right for you depends on data sovereignty, B2B depth, vendor-lock-in tolerance and a five-year TCO — not on the SAP discount on offer.

Why Hybris customers in 2026 face more than a shop question

Hybris has a longer history than most e-commerce platforms still in active use. Founded in 1997 in Zug, Switzerland, later headquartered in Munich. Acquired by SAP in 2013 — the purchase price was never officially confirmed, reported figures range from 1.3 to 1.5 billion US dollars (Wikipedia); Computerweekly). Since 2018 the product is officially branded SAP Commerce Cloud; the Hybris brand has been retired (Langia IT blog).

With release 2211 in December 2022, SAP also flipped the switch to cloud-only: from that release on, SAP Commerce ships exclusively in the cloud variant — new features, security patches and innovation no longer flow into the on-premise line (SAP Community Blog). The 2026 EoMM is the logical consequence of that strategy, not a sudden surprise. Gartner mirrors the signal: in its Peer Insights, the product is now listed as “SAP Hybris Customer Engagement and Commerce (Legacy)” — a label analysts do not assign casually.

So much for the market context. If you actually run a Hybris on-prem installation, you know the other side: years of custom extensions, a PCM layer entangled with promotion logic, storefront templates and ERP adapters, interfaces to OMS, WMS, DAM and sometimes a second master-data system. That is the reality of almost any B2B Hybris landscape in DACH machinery and industrial distribution: not “a shop,” but a grown data-and-process ecosystem with Hybris at the centre.

That is where the strategic trap of 2026 lies. If you frame the replatforming question as a pure shop question — “which platform replaces my Hybris?” — you carry the complexity into the new system. The real problem is not the shop. The real problem is the data model.

The real problem is the data model — not the shop

Hybris had a strength that became a brake. Product Content Management (PCM) was deeply built into the Hybris stack. Classifications, multi-level taxonomies, localised attributes, variant logic, asset linking — all in one database, all in one domain model, all maintained via the Hybris cockpits. For the architectural standards of 2013, that was modern. For the reality of 2026, it is the opposite.

When your product data lives inside the shop platform, three strategic decisions hang on one migration choice: changing the maintenance UI, changing data distribution, changing the frontend. Replatforming then no longer means “swap the shop.” It means: you build a new car while still driving it — and the engine (your data) is bolted to the steering wheel (your shop).

The consequence is a simple but decisive reordering. Before you touch a single line of shop code, you take the product data out of Hybris and park it in a dedicated data layer — a modern PIM. The moment product data lives independently from the shop, you have gained three things:

1. You can run shop selection without data risk. Shop choice becomes a frontend question, not a data question.
2. You can run in parallel. The old Hybris and the new shop both pull from the same data source — cutover becomes incremental, not big bang.
3. You make an investment you keep. Even if you swap the shop again in five years, the PIM stays. It is the one layer of your stack that does not need replatforming every seven to ten years.

This concept — PIM as decoupling layer — is the core of any honest ecommerce replatforming strategy. The methodology works with Shopware as target shop, just as well as with Spryker, commercetools or Elastic Path. It even works if you ultimately stay on SAP Commerce Cloud and only want to retire the on-prem footprint. It is not a vendor question; it is an architecture question.

The 5-phase playbook for your Hybris replacement

The following playbook is the sequence in which we run Hybris replacements in DACH B2B manufacturing projects. The five phases are not interchangeable. Phase 2 before Phase 4 is the single most important strategic statement of this article.

Phase 1: Inventory — what do you actually have?

Before you migrate anything, you map what you migrate. Sounds trivial, is not. In most Hybris landscapes after eight to twelve years of operations, nobody holds the full map in their head anymore.

Three audits run in parallel:

• Product data model audit.** Which classification systems are active (ETIM, eCl@ss, your own hierarchies)? Which attribute types, languages, units of measure, variant axes? How many products, variants, languages and channels? Which data flows in from ERP, which is enriched in PCM?
• Interface map.** ERP, OMS, WMS, DAM, a second master-data system, CRM, marketing automation, print pipelines. What goes out, what comes in, at which intervals, over which technology (files, IDocs, REST, message queue)? Which interfaces are documented, which “only the retired colleague still knows”?
• Custom code audit in the Hybris stack.** Which extensions are standard, which are bespoke, which are modifications to standard? Of those, which are functionally relevant, which are “legacy nobody touches anymore”?

Outcome: an architecture picture on one page, an interface map, an honest statement about the custom-code share. From our Hybris migration projects, this phase typically runs four to eight weeks, depending on the size of the Hybris landscape.

Phase 2: PIM consolidation — get the data out of Hybris

This is where the strategically most important work happens. You move PCM from Hybris into a dedicated PIM and establish it as single source of truth for product data.

What has to happen:

• Data model translation.** The Hybris PCM data model gets mapped onto the PIM data model. Classifications get consolidated. In our PCM audits at Hybris customers we routinely see 1,500-plus attributes, of which typically 60–70% are redundant, outdated or duplicated. Multi-level variant hierarchies get flattened or deliberately preserved.
• Data quality hub.** Mandatory fields, validation rules, workflows for product onboarding and maintenance. What used to be bespoke logic in the Hybris backend becomes first-class functionality in the PIM.
• Initial data migration.** An ETL run from the Hybris PCM into the new PIM, with cleansing steps (duplicates, empty attributes, inconsistent units of measure).
• Channel distribution back to Hybris.** The PIM learns to push data into the old Hybris shop — as a transitional source, so the Hybris shop keeps running while you do the work upstream in the PIM.

Exactly this step is feasible today — independent of which shop will take over the frontend in two years. That is the heart of the “PIM first” argument: phase 2 creates value from the first day the PIM goes live, and freezes no shop decision.

A modern PIM like apollon-OMN takes on that data-layer role. If you want to see how a PIM integrates into an existing Shopware setup, look at PIM integration for Shopware. For an honest market view beyond our own product, see the PIM software comparison.

Phase 3: Decouple the data model — the architecture question

With the PIM as data source, the first lever is set. Phase 3 cements it: you build an architecture in which every consumer of product data — shop, app, marketplace, B2B portal, print catalogue, sales configurator — connects via clearly defined APIs.

Three things emerge in this phase:

• Headless, API-first as target picture.** Product data is exposed via REST or GraphQL, assets through CDN-friendly endpoints, channel logic (who sees which assortment, in which language, at which price) sits in the distribution layer — not in the shop.
• Distribution logic.** Channel mapping, assortment control, asset variant generation, translation workflows. Classical PIM disciplines that should not live in the shop system — otherwise you build the next Hybris jam.
• Interface modernisation.** File-based ERP integrations get lifted to event- or API-based patterns, as far as the ERP allows.

Outcome: the shop becomes a frontend you can swap without touching the data layer. That is the insurance policy against the next EoMM, in whichever system.

Phase 4: Shop selection — now, not before

Only after phase 3 do you open the shop selection process. And now you may take an honest position, because the data layer is independent.

For DACH B2B mid-market companies with a manufacturing or distribution background, Shopware is in most cases the logical choice. The reasoning, based on public facts, without confidential TCO numbers:

• German vendor, European data sovereignty.** For mid-sized industrial customers with European compliance requirements, that is a real factor — not marketing copy but a procurement requirement.
• Open-source core, lower vendor lock-in risk.** Customers who have lived through the Hybris lock-in experience weigh this point heavily.
• B2B suite in the core.** Account hierarchies, tiered pricing, approval workflows, quotes — as standard features, not as customisation effort.
• Active DACH partner ecosystem.** Implementation, hosting, extensions, support — all in German language, German time zone, German invoicing.

That does not mean Shopware is always right. There are constellations in which commercetools with its pure composable approach is the better choice — especially for headless stacks with multiple frontends. Spryker matters where the glue-code share is high and the internal engineering team is large enough to operate a toolkit platform. Elastic Path plays in the API-first, enterprise-grade space. And SAP Commerce Cloud itself can be the pragmatic path if internal SAP know-how dominates and the contract fits.

Selection runs as a structured procurement with a requirements document, demo comparison, reference calls and a total-cost calculation over five years. What you no longer need to argue about is the data model — you decided that in phase 2.

Phase 5: Cutover — the final 60 days

With the data layer and shop selection in place, cutover becomes a controlled transition rather than a big bang. Four building blocks are critical:

• Parallel operation with a data-sync strategy.** Hybris stays live for a while, the new shop runs in parallel — both pull from the PIM, both write orders into ERP. Assortment, customer or regional splits steer who moves to the new shop and when.
• SEO migration.** Complete URL mapping between old and new world, 301 redirects at URL level (not just domain level), structured data re-emitted, XML sitemaps resubmitted. From our replatforming projects we see a clear pattern: a neglected SEO cutover typically costs B2B manufacturers six to twelve months of organic traffic — that item belongs in the business case.
• Data quality sign-off BEFORE go-live.** Random checks across products, images, prices, availability and translations. No go-live without a documented sign-off from the assortment owners.
• Post-live hardening.** Monitoring of performance, conversion, search-result quality, interface latencies, error rates. The first 30 days after go-live need a dedicated hardening team, not standard support.

If you want to see what the concrete Hybris-to-Shopware path looks like in practice, the next step is a joint architecture scan: Shopware migration overview.

The most common mistakes in a Hybris migration

From our replatforming projects of the past years, these are the five mistakes that most reliably cost real money:

1. “Swap the shop, keep the data model” — the most expensive variant. Carrying PCM complexity into the new system rebuilds the next replatforming trap inside 24 months. “Shop now, PIM later” is the most common self-deception in Hybris migration roadmaps.
2. Underestimating PCM migration. Data work is regularly 60–80% of project effort. Budgeting it inside the shop implementation and assuming “the data comes from the ERP anyway” misses the real workload.
3. Cloud as default choice without checking sovereignty needs. SAP Commerce Cloud is a valid path but not automatically the right one. Data residency, contract terms, lock-in profile and actual composable maturity belong in every selection.
4. Porting custom code 1:1. Pushing eight years of Hybris customisation 1:1 into the new stack guarantees the same maintenance gridlock in the new stack. Migration is the moment you sort custom code into “actually business critical” or “historical baggage.”
5. Cutover scheduled against the Q4 business. A go-live in November is a bad idea in B2B manufacturing — year-end assortment changes, framework contracts, stocktaking, trade-show preparations. Plan to the operational reality, not to the wishful date.

When is the right time

The EoMM date of 31 July 2026 is not the day your system goes dark. But it is the day your system shifts into a different risk class: no security patch, no certified JVM path, no compliance updates. Insurance audits, group IT mandates and supplier requirements will start asking about it from August 2026 onwards.

Realistic replatforming projects in B2B manufacturing run 12 to 24 months. Starting in May 2026 keeps you on track for a 2027 cutover. Starting in 2027 means running an unmaintained productive system into 2028 and very likely negotiating Customer-Specific Maintenance — an arrangement that typically comes at a premium and does not include an innovation path.

The call to action is not “migrate the shop tomorrow.” The call is: start phase 1 and phase 2 now, at the latest. Phase 2 — the PIM consolidation — creates value independent of the eventual shop decision. It is the one step you can take today without tying yourself to a shop vendor.

FAQ

Does SAP Commerce really end in 2026?

Mainstream maintenance for SAP Commerce on-premise (version 2205) ends on 31 July 2026 according to the official SAP Help Portal announcement. That affects only the on-premise line. SAP Commerce Cloud (Public Cloud) continues to receive quarterly updates and is unaffected by the EoMM. Whenever you read “Hybris dies in 2026,” check carefully which variant is meant.

What happens to my SAP Commerce Cloud installation?

If you sit on SAP Commerce Cloud (Public Cloud), your platform stays under active support. The 2026 EoMM does not apply to the cloud variant. SAP positions the cloud line including SAP Composable Storefront as its official innovation path. That said, data sovereignty, B2B depth and TCO profile still warrant an independent platform review — staying on the cloud is not a free pass for the next ten years.

How long does a Hybris migration take?

Realistic replatforming projects in B2B manufacturing run between 12 and 24 months from inventory to cutover. The phase ranges below are observations from our Hybris migration projects — they vary with landscape size, number of interfaces and share of custom code: phase 1 (inventory) typically four to eight weeks, phase 2 (PIM consolidation) three to nine months, phase 3 (decoupling) two to five months, phase 4 (shop selection and implementation) six to twelve months, phase 5 (cutover) two to three months. In practice the phases overlap — only the order of decisions is strictly sequential, not the work.

What does a Hybris migration cost?

Blanket cost numbers help nobody. The main drivers are: size and complexity of the product data model, number of interfaces, share of custom code in the Hybris stack, internationalisation depth, target platform and hosting model. More useful than a number is an honest phase-1 inventory — after four to eight weeks you have a defensible estimate for the following phases.

Do I migrate the PIM first or the shop first?

PIM first. If you swap the shop first, you carry PCM complexity into the new system and build the next Hybris trap. PIM consolidation is also the only migration step you can take today without committing to a shop target — it works with Shopware, Spryker, commercetools, Elastic Path or even SAP Commerce Cloud as later frontend. More context in our PIM software comparison.

Which migration path makes sense for Hybris customers in DACH B2B?

For DACH mid-market companies with a manufacturing or distribution profile, the combination of Shopware (as shop platform) plus a dedicated PIM (as data layer) is in most cases the most robust choice. Reasons: German data sovereignty, open-source core, B2B features in the core, broad partner ecosystem. For pure composable stacks or highly scaled headless setups, commercetools or Elastic Path may fit better. The decision belongs in a structured selection in phase 4, not in a gut call at the start.

What is SAP Composable Storefront (Spartacus)?

SAP Composable Storefront is the official headless frontend of SAP Commerce Cloud — Angular-based, formerly known as Spartacus. It replaces the legacy Accelerator storefronts and is SAP’s recommended frontend path within the cloud migration offer. If you migrate to SAP Cloud and want a modern headless setup, Composable Storefront is essentially the default. For Hybris on-prem customers who do not necessarily want to stay with SAP, Composable Storefront is not relevant — then the headless options of the chosen target platform apply.

Ready for the next step?

You run Hybris and you face the 2026 replatforming decision? We do this every day. apollon is Shopware agency, OMN PIM vendor and Hybris migration partner in one — the only constellation in DACH where you get data layer and shop layer designed from one architectural logic, rather than retrofitted after the fact.

In a 60-minute migration workshop we scan your data architecture with you, place your Hybris stack honestly into the five phases, walk you through a realistic migration path — from PIM consolidation through to the Shopware cutover — and size effort, timeline and risk for your concrete setup.

→ Request a migration workshop — Hybris → Shopware with apollon-OMN as data layer.

Sources linked inline. Status: May 2026. We update this article as SAP refines its maintenance strategy for SAP Commerce.