Business
9 min readIt's August 1st, 2026. You grab your coffee, pull up the storefront, and… it's still there. Orders are flowing. Nobody from Walldorf showed up to repossess your servers. Crisis averted, right?
Not so fast. Enter the fine print…
Let's be precise, because precision matters when you're taking this to a board. SAP confirmed that 2205 is the final on-premises release and that, after July 31, 2026, it moves to customer-specific maintenance with no further on-premises releases planned. That means no more security patches, support packages, legal change packages, or new functionality (Spinnaker Support). Per SAP's own Supported Releases page, support staff will still offer guidance and workarounds to customers with a valid agreement, but corrections and updates for the release have ended.
Technically, this isn't "end of life." SAP has said there's no defined sunset date for SAP Commerce on-premise (Akeneo). The executive translation, though, is simpler: your platform still runs, but nobody is fixing it anymore.
And you're in good company. More than 3,000 companies worldwide still run SAP Hybris, most of them mid-to-large enterprises with complex B2B needs in manufacturing, wholesale, and industrial goods (Emporix).
Here's the part that doesn't make the SAP press release. Hybris sits on a stack of open-source components, each with its own expiration date. According to TuxCare's SAP Commerce 2205 Survival Guide, Spring Framework 5.3 reached end of life in October 2024, Tomcat 9.0.x support ended in April 2026, SAP's Solr support ends this month, and SAPMachine 17 support concludes in March 2027.
So the technical debt isn't coming due. It's already past due. Every quarter you run on that stack, your platform gets harder to defend to your CISO, your auditors, and (don't forget) your cyber insurance carrier.
I once called PCI compliance in the cloud "an auditor's dream." An unpatched, internet-facing commerce engine processing card data and customer PII? That's an auditor's Christmas morning.
SAP's recommended path is SAP Commerce Cloud, better known as CCv2. It runs your code on Kubernetes backed by Microsoft Azure, specifically Azure Kubernetes Service, with Azure SQL DB as the database.
Sounds like an upgrade. Behaves like a migration. As Spinnaker Support puts it, this is mostly a deployment move rather than an architectural one, since the Java backend, type system, and extension mechanism are largely the same engine. In other words, you pay to move the same monolith to a new zip code.
Then there's the second shoe. SAP deprecated the JSP-based Accelerator storefront templates back in the 2205 release. It's pulling them out of Commerce Cloud 2211 in September 2027, with extended support ending in 2028 (Contentful; see also SAP Community guidance). Migrate your Accelerator storefront to CCv2 this year, and you get to rebuild your front end next year. Two migrations for the price of… well, two migrations.
And the price isn't small. TuxCare estimates the move often runs past $1M for complex environments, requires rewriting custom logic and integrations, and runs on SAP's timeline rather than yours. SAP's broader track record doesn't inspire confidence either: a Horváth study found that 60% of S/4HANA transformations blew past budget and schedule. Layer on GMV-based licensing, where your platform bill rises right alongside your revenue, and the long-term TCO picture gets, well, cloudy.
The other door SAP leaves open is doing nothing, formally known as Customer-Specific Maintenance (CSM). There's no surcharge for CSM, and you can still open cases and get workarounds where feasible. But coverage drops off sharply: no support packages, legal changes, third-party library updates, or new interfaces (Spinnaker Support).
More to the point, CSM doesn't patch Spring, Solr, Tomcat, MySQL, or the JDK, which is exactly where the exposure lives (TuxCare). CSM is a waiting room, not a destination.
Third-party support providers can patch the gap for a while, and for some of you that's a perfectly sensible bridge. But a bridge still has to lead somewhere.
Here's the thing SAP would prefer you didn't notice: if you're going to spend the time and money on a migration anyway, you get to decide what that money buys. A new address for the same monolith? Or a platform your team actually controls for the next decade?
That's where we come in. At Broadleaf Commerce, we built a modern commerce platform for exactly the kind of complexity that led enterprises to Hybris in the first place, minus the baggage:
Theory is nice. Proof is better. Landmark Group, one of the largest omnichannel retail, hospitality, and leisure organizations across the Middle East, North Africa, India, and Southeast Asia, moved every site and geography across the MENA region off SAP Hybris and onto Broadleaf.
The starting point will sound familiar: an aging monolith that couldn't handle quick changes and deployments, and a portfolio of brands that needed consolidating under a single interface. The result is a single codebase powering a multi-brand, multi-geography, multi-catalog, multi-site deployment, with one back-office console for business users.
And here's the kicker for this particular conversation: Landmark runs Broadleaf on its own self-managed Microsoft Azure infrastructure, across multiple data centers. Same cloud SAP wants to move you to. Very different terms. The business outcomes speak the executive language: faster development on one codebase, consolidated merchandising through a unified admin, and features built once and re-used across markets through shared services.
In keeping with the Rule of Three, here's the framework I'd bring to the room:
July 31st wasn't the day the lights went out. It was the day the meter started running. The enterprises that come out of this well won't be the ones who moved fastest. They'll be the ones who stopped letting a vendor's calendar make a decade-long architecture decision for them. Landmark Group already made that call.
As Peter Drucker observed, "The greatest danger in times of turbulence is not the turbulence; it is to act with yesterday's logic."
If you're weighing your options, let's talk. Even if it's just to pressure-test the plan you already have.
Did SAP Hybris actually reach end of life? Not in the strict sense. SAP Commerce 2205 reached End of Mainstream Maintenance on July 31, 2026, and moved into Customer-Specific Maintenance. SAP hasn't named a final sunset date, but new patches, legal updates, and library updates have stopped (SAP Help Portal).
Will my site stop working? No. Your storefront keeps running. The risk is cumulative: every newly discovered vulnerability in your platform or its open-source stack stays open unless you patch it yourself or pay someone else to.
We're already on SAP Commerce Cloud. Does this affect us? The on-premise EoMM doesn't apply to Commerce Cloud. However, if you're still on the JSP-based Accelerator storefront, it's being removed from Commerce Cloud in September 2027, with extended support ending in 2028 (Contentful). That's a front-end rebuild either way.
Is moving to Commerce Cloud a simple upgrade? Rarely. CCv2 runs the same core engine on Azure, so custom code, integrations, and storefronts typically need significant rework. Complex environments frequently land north of $1M (TuxCare).
What does Customer-Specific Maintenance cover? You can still open support cases and receive workarounds where feasible, but there are no new patches, SLAs, legal change packages, or third-party library updates. It also doesn't cover the open-source components (Spring, Solr, Tomcat, the JDK) underneath the platform.
Can we leave SAP Commerce without disrupting our SAP ERP? Yes. Modern commerce platforms, Broadleaf included, integrate with SAP ERP and S/4HANA via standard APIs and middleware. ERP stays your system of record; commerce becomes your experience layer.
How long does a migration take? Industry estimates for enterprise SAP Commerce migrations generally fall between four and twelve months, depending on complexity, data volume, and integration depth (Emporix). A phased approach can reduce risk and timeline pressure.
Has anyone actually moved off Hybris to Broadleaf? Yes. Landmark Group moved all of its sites and geographies across MENA off SAP Hybris onto Broadleaf, running a single codebase for its multi-brand, multi-geography, multi-catalog, multi-site business on its own Azure infrastructure.
Why Broadleaf rather than another alternative? Three reasons: your Java and Spring talent carries over directly; you choose where the platform runs (including Azure, if you like it there); and your licensing never scales with GMV.