SAP Hybris End of Life: The Complete Migration Checklist for 2026

On 31 July 2026, mainstream maintenance for SAP Commerce on-premise ended (SAP Help Portal). Release 2205 was the last on-premise release. Anyone still running it now depends on customer-specific maintenance, with no regular security patches or legal updates.

We published this checklist in April, when there were four months left. The deadline has passed, the checklist has not: it is still the order in which we move Hybris installations to SAP Commerce Cloud. I have updated it for the situation after July and folded in what we used to cover in three separate posts: what carries over from Hybris, the phase plan and the work after go-live.

TL;DR: SAP Commerce on-premise (formerly SAP Hybris) left mainstream maintenance on 31 July 2026; since then only customer-specific maintenance is available. The target for most customers is SAP Commerce Cloud: same core as Hybris, but operated by SAP with continuous updates. This checklist covers the 26 steps in four phases, typical timelines (3 to 18 months depending on scope), indicative costs, SEO protection and the first weeks after go-live. If you are still on-premise, start with the assessment: it tells you how long you will stay exposed.

What Was SAP Hybris?

SAP Hybris was the e-commerce platform SAP acquired in 2013. SAP later renamed it SAP Commerce for the on-premise product and SAP Commerce Cloud for the version SAP operates; since release 2211 it is delivered as SAP Commerce Cloud only. When people say “Hybris” today, they almost always mean an on-premise SAP Commerce installation, and that is the version whose mainstream maintenance ended on 31 July 2026.

What Changed on 31 July 2026

“End of life” is the phrase people search for. The correct term is End of Mainstream Maintenance (EoMM), and it has specific consequences.

What stopped:

• Regular security patches. Your commerce platform, the one that processes customer and payment data, no longer receives routine security updates.
• Legal and tax updates. VAT changes and other regulatory adjustments are no longer shipped as standard maintenance.
• Third-party library updates. When a bundled dependency gets a CVE, the fix does not arrive in your on-premise release as a matter of course.
• Java runtime certification. New JDK versions are not certified for 2205, so the runtime ages with the platform.
• Product development. No new features, no performance work, no new APIs. The on-premise product is frozen.

What continues, at a price:

• Customer-specific maintenance. SAP offers support under individual agreements. The terms and prices depend on your contract, so ask your SAP account team for them in writing.
• Existing SAP Notes. The knowledge base stays available, but fixes for new issues may not exist.

What this means in practice after July, and which interim measures make sense, is covered in SAP Commerce on-premise support has ended: now what?. This post is about the way out.

Hybris, SAP Commerce, Commerce Cloud: What Stayed and What Changed

A note on names first. SAP acquired Hybris in 2013 and later renamed it: SAP Commerce for the on-premise product, SAP Commerce Cloud for the version SAP operates. “Hybris end of life” therefore refers to the on-premise version. Since release 2211, SAP Commerce is delivered as SAP Commerce Cloud only, and that is the migration target.

The most common misconception we hear: “Commerce Cloud is a completely new product.” It is not. The engine is the same; what changed is how it is operated.

What stayed:

• The type system (item types are still defined in XML)
• The extension mechanism and Spring as the container for services
• The Java backend and the commerce modules: catalogue, cart, checkout, pricing, order management

What changed:

• Operations. SAP provisions, scales, patches and monitors the infrastructure. Teams that used to spend half their time on servers can work on the shop.
• Updates. Instead of large upgrades every few years, SAP delivers updates continuously. New features ship switched off, and you activate them when your team is ready. The flip side: you can no longer postpone updates for years. The 2211-jdk21 framework update with Java 21 and Spring 6 shows what that means in practice.
• Deployment. Builds and deployments run through Cloud Portal instead of your own scripts.
• Storefront. The recommended frontend is the headless SAP Composable Storefront (formerly Spartacus), which talks to the backend through the OCC REST APIs. SAP deprecated the JSP-based Accelerator templates with release 2205 and, according to its published plan, removes them from Commerce Cloud in September 2027 (SAP KBA 3263872).

For your team this means: Java and type-system skills transfer. What they have to learn is the cloud deployment model, Cloud Portal and, if you still run Accelerator, an Angular frontend. That is training, not reskilling.

The Migration Decision Framework

Before the checklist, one question needs an answer: stay on SAP, or leave?

We are an SAP partner, so we have a commercial interest in you staying. Here is when each path makes sense.

Stay on SAP Commerce Cloud if:

• You run SAP ERP (S/4HANA or ECC) and rely on deep ERP integration: pricing, availability, orders, customer-specific terms. If that ERP is still ECC, its own end of SAP ECC maintenance in 2027 belongs in the same plan.
• Your B2B model uses SAP-specific features: complex pricing, contracts, customer-specific catalogues, approval workflows.
• Your team has SAP Commerce skills. Retraining on a completely different platform costs months.
• You need to move quickly. Commerce Cloud keeps your data model, business logic and many customisations; a complete re-platforming does not.

Consider leaving SAP if:

• You have no SAP ERP, or the integration is a simple order feed.
• Your storefront is pure B2C with standard catalogue, cart and checkout.
• Your team has no SAP skills and does not want to build them.
• You are aiming for a fully composable architecture anyway. That takes considerably longer than a Commerce Cloud migration; our analysis of composable commerce in B2B explains when it pays off.

For most on-premise customers, SAP Commerce Cloud is the pragmatic answer: lowest risk, fastest execution, existing investment preserved. Pragmatic does not mean automatic, though. Make it an active decision. An overview of the platform today is on our SAP Commerce Cloud page.

The Complete Migration Checklist

Twenty-six items in four phases. This is the checklist we use with our clients.

Phase 1: Assessment (Weeks 1 to 4)

This is the phase most companies rush. Everything after it depends on it.

1. Inventory every customisation. Export a complete list of custom extensions, ImpEx scripts, HAC customisations and modified platform APIs. Classify each item: still needed, replaceable by standard Commerce Cloud functionality, or obsolete. In our audits a considerable share usually falls into the last two categories; the 5 migration mistakes show why that matters.

2. Find the core modifications. Code that changes SAP’s delivered classes instead of using extensions, or that bypasses the type system and hits the database directly, has to be refactored before migration. These items are what blow timelines, so find them first.

3. Map all integrations. ERP, PIM, CRM, payment, shipping, tax, loyalty, marketing automation. For each: protocol (API, IDoc, file transfer, direct database connection), data volume, frequency, owner. File drops and direct database connections do not work in Commerce Cloud, and this is the item that most often causes “how did we miss that” conversations.

4. Check third-party extensions. Verify every add-on and third-party extension for Commerce Cloud compatibility with the vendor and test it in a cloud sandbox. Some have cloud-ready versions, others need a replacement.

5. Catalogue your storefronts. Number of sites, languages, catalogues. Multi-country setups with their own pricing, tax and fulfilment rules are a different project from a single storefront.

6. Profile your data. Count products (with variants), categories, customers, historical orders, content pages and media. Check quality at the same time: duplicates, orphaned references, inconsistent formats, data nobody has touched in years. Clean up in the source system; dirty data does not belong in a new environment.

7. Record baselines. Response times, throughput, conversion rate, error rates. Without these numbers nobody can prove after go-live whether the new platform performs better or worse.

8. Assess your SEO footprint. Pull the full URL inventory from Google Search Console. How many pages are indexed, and how much organic traffic do they bring? Sites with high SEO value need a detailed redirect strategy.

9. Document encryption and credentials. If you use Transparent Attribute Encryption with your own keys, document every encrypted attribute and plan its transfer to Commerce Cloud’s key management.

10. Clarify your licence and contract position. What does your current agreement say about the time after EoMM, and what does a Commerce Cloud subscription look like for your volume? Contract talks take weeks; start them in parallel.

Phase 2: Architecture and Planning (Weeks 5 to 10)

11. Choose your storefront approach. Three options:

• SAP Composable Storefront: SAP’s recommended frontend. Headless, decoupled from the backend, independently deployable. The right choice for a strategic investment; our guide on migrating from Accelerator to Composable Storefront describes the steps.
• Carry over the Accelerator storefront: the fastest way to get off on-premise, because the storefront code stays. But the templates have been deprecated since 2205 and are due to be removed in September 2027, so this is a stopgap with a fixed expiry date.
• Your own headless frontend: React, Next.js or Vue on the Commerce Cloud APIs. Maximum freedom, but you own the frontend entirely. We compare the options in Composable Storefront vs React/Next.js.

12. Design the target architecture. Commerce Cloud environments, integration architecture (SAP Integration Suite or direct APIs), CDN and caching strategy, monitoring and alerting.

13. Plan the integration rework. In Commerce Cloud everything runs through APIs or SAP Integration Suite. Every integration needs its own migration plan; budget three to five days per integration for analysis and redesign.

14. Define the data migration strategy. Big bang (full load in one cutover window) or iterative (progressive loads with delta sync). For more than a million products we recommend iterative loads with at least three trial runs. The available methods are covered in our post on data loading in SAP Commerce Cloud.

15. Plan environments, CI/CD and recovery. At least development, staging and production; larger projects add an integration test environment. Set up automated build, test and deployment pipelines from day one. Define recovery point and recovery time objectives and test the restore before go-live.

16. Set up governance and lock scope. A weekly steering meeting with decision authority, a decision log, sprint demos every two weeks and a product owner on the client side who makes scope decisions. Then write the scope down and sign it off. The biggest cause of delays is “while we’re at it, let’s also…”. Migrate first, enhance later.

Phase 3: Build and Migration (Weeks 11 to 30)

17. Set up the Commerce Cloud environments. Provision all environments, verify the build pipelines, and deploy through the whole chain once before any business logic is written.

18. Rebuild or migrate the storefront. Start with the templates that carry the most traffic: homepage, category pages, product detail pages, checkout.

19. Rework the integrations. Test each integration with real data, not mocks. Integration tests are where most migration defects surface, so test early and often.

20. Run trial data migrations. At least two full runs before the real cutover. Measure duration, accuracy and error rate, and fix issues between runs.

21. Implement SEO and performance. Deploy the redirect map, canonical URLs, XML sitemap and robots.txt, and crawl the staging environment. Tune CDN caching and API response times; set target values for load times and Core Web Vitals.

Phase 4: Testing and Go-Live (Weeks 31 to 38)

22. Run user acceptance testing with the business. Business users, not developers, test browsing, search, cart, checkout, payment, returns and B2B workflows, in every storefront, language and customer segment.

23. Load test at scale. Simulate peak days. Commerce Cloud scales automatically; your own code and integrations do not necessarily.

24. Validate the SEO migration. Compare URL inventories, check every redirect, validate structured data with Google’s Rich Results Test.

25. Rehearse and execute the cutover. Write a runbook detailed enough for anyone on the team to execute: freeze content, run the final delta migration, switch DNS, check all integrations, monitor for 48 hours. Rehearse it at least once and document the rollback, including how orders placed after the switch get back to the old system if you have to revert.

26. Monitor after go-live. At least two weeks of close monitoring: error rates, conversion against the baseline, indexing, integration failures, support tickets. Set alerts for deviations from the baseline.

Go-Live Is Not the Finish Line

Real production traffic reveals bottlenecks that no test found. Plan for the weeks after go-live from the start:

• An optimisation sprint. Four to six weeks for caching, slow queries, API response times and frontend rendering.
• Training. Your team has to run Commerce Cloud, maintain content and troubleshoot on its own. Train in steps: operations first, then configuration, then development.
• A backlog for deferred features. Whatever was descoped during the migration belongs on a prioritised backlog, not in oblivion. Review it regularly instead of building everything at once.
• An update rhythm. Commerce Cloud expects you to adopt updates regularly. Plan fixed windows for them.

Timeline Calculator

Not every migration is the same. These factors drive the timeline:

Reading these numbers in September 2026: every month counts from now on, because every month runs on customer-specific maintenance. Fast-track projects can be live before the end of the year or early in 2027. Standard projects land in the course of 2027, and complex ones should be split into waves so the first markets leave the on-premise platform early. The fastest end of the range is described in our 90-day playbook.

Cost Estimates by Scenario

We are asked this in every first conversation, so here are indicative ranges from our projects rather than a vague “it depends”:

Fast-track (one storefront, few integrations): USD 300K to 500K. Assumes a focused scope, SAP skills in the team and the willingness to defer non-essential customisations.

Mid-market (two or three storefronts, moderate complexity): USD 500K to 800K. Most of our migration projects fall here: assessment, build, data migration, integration rework, performance tests and go-live support.

Enterprise (five or more storefronts, complex B2B, multi-country): USD 800K to 2M or more. The range is wide because a twelve-country B2B operation with custom pricing and deep ERP integration is a different project from five B2C storefronts with standard checkout.

These are one-time migration costs. Not included: Commerce Cloud licences (annual, depending on volume), third-party licences (PIM, search, CMS), internal effort and later enhancements. Plan a contingency of 15 to 20 percent for data quality issues and integration surprises. The licence side is broken down in our Commerce Cloud pricing guide.

The cost of waiting: customer-specific maintenance is priced individually and is generally well above what you paid for mainstream maintenance, without new features or regular patches. Compare that figure with the migration budget before you decide to wait another year.

SEO Migration: Don’t Lose Your Rankings

We have seen technically clean migrations lose a large part of their organic traffic because nobody planned the SEO transition. For many shops, organic search is one of the most important revenue channels.

Before migration:

1. Baseline everything. Export indexed URLs, clicks, impressions and average positions for your top queries from Search Console, weekly, because you need the trend and not a snapshot.
2. Crawl the current site. With Screaming Frog or Sitebulb: complete URL inventory, internal links, canonicals, structured data.
3. Map every URL. Old URL, new URL, redirect type (almost always 301).

During migration:

4. Build redirects early, in parallel with the new platform, and test them on staging.
5. Preserve metadata. Titles, descriptions, heading structure and structured data must carry over.
6. Have the XML sitemap ready and submit it right after the DNS switch.

After migration:

7. Monitor daily for four weeks: indexing rate, 404 errors, organic traffic against the baseline, positions for your top 50 queries.
8. Fix issues the same day. In the first weeks Google re-evaluates your entire site.

What We Took from the Franke Launch

At Franke, we brought the SAP Commerce Cloud platform live in 90 days; that figure refers to the commerce launch. The starting point was a neglected legacy platform implemented by a previous partner. We replaced it with a headless architecture for B2B and B2C, integrated it cleanly with S/4HANA and C4C, and today it connects more than ten global channels. The project received the SAP Quality Award for “Rapid Time to Value”. Details are in the Franke case study.

Three lessons from it apply to every migration:

• Audit before you migrate. Every customisation that turns out to be obsolete is code you do not have to migrate, test or maintain.
• Run workstreams in parallel. Platform, data, integrations and frontend in parallel with daily coordination, not one after the other.
• Deliver iteratively. Deploy to the cloud early, even if it is incomplete, and show stakeholders progress every week.

The Risk of Staying On-Premise

Since August, doing nothing has not been a plan but a state. What it means:

Security. The platform processes personal and payment data without regular security patches. That conflicts with the requirements of PCI-DSS, the GDPR and the Swiss nDSG, and in an audit “we didn’t migrate in time” is not an argument.

Compliance. Tax rules and data protection requirements keep changing. Without SAP updates you have to implement them yourself, in core modules few teams can change safely.

Cost. Customer-specific maintenance costs more than mainstream maintenance, and migrations do not get cheaper: developers with on-premise experience are getting rarer.

Talent. Developers want to work on current platforms. A frozen system makes hiring and retention harder.

Insurance and audit. Cyber insurers and auditors (SOC 2, ISO 27001, PCI-DSS) ask about maintenance status. An unmaintained commerce platform tends to end up as a finding in the report.

Next Steps

1. Book an assessment. Our structured migration assessment takes two to three weeks and delivers the customisation inventory, integration map, complexity rating, timeline and budget range. Request it here.
2. Read further. On-premise support has ended: now what? covers the interim measures; the 90-day playbook shows what fast execution looks like.
3. Choose your partner deliberately. Our overview of the best SAP Commerce Cloud partners in Switzerland lists the criteria that decide a migration project. If your ERP is moving too, we deliver the S/4HANA core and the complete CX stack with one team; see the overview for Cloud ERP and CRM.
4. Visit our on-premise campaign page for further resources.

The deadline has passed. The length of your exposure window is still up to you. Talk to us.

Frequently Asked Questions

When did SAP Hybris on-premise reach end of mainstream maintenance?

On 31 July 2026. Release 2205 was the last on-premise release of SAP Commerce, the product formerly called SAP Hybris. Since then SAP only offers customer-specific maintenance, so regular patches and legal updates no longer arrive automatically.

We are still on-premise after July 2026. What should we do now?

Clarify your contract status with SAP first, then close the most exposed security gaps and start the assessment for SAP Commerce Cloud. A two to three week assessment gives you the customisation inventory, integration map, timeline and budget range, so the months on customer-specific maintenance stay as few as possible.

How long does a migration from Hybris to SAP Commerce Cloud take?

A fast-track migration with one storefront and few integrations takes three to six months; the 90-day playbook describes the fastest end of that range. Standard projects with two or three storefronts take six to twelve months, complex multi-country deployments twelve to eighteen months.

Is SAP Commerce Cloud the same product as SAP Hybris?

The core is the same: the type system, the extension mechanism, Spring and the Java backend come from Hybris. What changed is everything around it: SAP operates the infrastructure, updates arrive continuously, deployments run through Cloud Portal and the recommended storefront is the headless SAP Composable Storefront.

Will our Hybris customisations work in SAP Commerce Cloud?

Extensions that follow SAP’s extension model (custom types, Spring bean overrides, OCC endpoints) usually migrate with small changes. Direct database access, modifications to SAP’s delivered code, file-based integrations and custom infrastructure scripts need rework. The largest single workstream is usually the storefront, especially if you still run an Accelerator storefront.

How much does a Hybris to Commerce Cloud migration cost?

As indicative ranges from our projects: USD 300K to 500K for a fast-track migration, USD 500K to 800K for mid-market projects with two or three storefronts, and USD 800K to 2M or more for complex multi-country B2B. Commerce Cloud licences, third-party tools and internal effort come on top; plan a contingency of 15 to 20 percent.