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

July 31, 2026. That’s the date SAP stops shipping security patches, compliance updates, and platform support for SAP Commerce on-premise (SAP Help Portal, 2026). Not a soft deprecation. Not a gradual wind-down. A hard maintenance cutoff.

If you’re reading this in April 2026, you have four months. That’s tight but not impossible — we migrated Franke in 90 days and won an SAP Quality Award for it. But that project had aggressive preparation. If you haven’t started, read every word of this checklist.

TL;DR: SAP Hybris (Commerce) on-prem mainstream maintenance ends July 31, 2026. After that: no security patches, no compliance updates, no Java support, no SLA-backed support. Over 3,200 companies run SAP Commerce (6sense, 2025). Migration to SAP Commerce Cloud typically takes 6-12 months, but fast-track projects can complete in 4-6 months. This post is the complete checklist: 24 items across 4 phases, cost estimates by scenario, and an honest assessment of what happens if you do nothing. Start your assessment now.

What’s Actually Happening on July 31, 2026

Let’s be precise about what changes — and what doesn’t. “End of life” gets thrown around loosely. The actual term is End of Mainstream Maintenance (EoMM), and it has specific consequences.

What stops immediately:

• Security patches. No more regular security updates. Your commerce platform — the one processing customer payment data — will run on unpatched software. Every month after EoMM increases your attack surface.
• Legal and tax compliance updates. VAT changes, tax regulation updates, PCI-DSS compliance changes — SAP won’t ship updates for these. You’re on your own.
• Third-party library updates. When a dependency gets a CVE, SAP won’t update it in your on-prem release. You will either fork or accept the vulnerability.
• Java VM version support. New JDK versions won’t be certified. Over time, your application server runs on an ageing, unsupported Java runtime.
• Platform improvements. No new features, no performance optimisations, no API enhancements. The product is frozen.

What continues — at a cost:

• Customer-specific support (CSS). SAP will provide support, but it moves from mainstream SLA terms to customer-specific agreements. These are expensive — typically 2-4x the cost of mainstream maintenance — and come with no guaranteed response times for patches.
• Access to existing SAP Notes. You can still search the knowledge base. But fixes for new issues may not exist.

This isn’t theoretical. 83% of data migration projects fail or exceed their budgets (Bloor Group, 2023). The companies that succeed are the ones that start early and plan properly.

A note on terminology: You’ll see “SAP Hybris,” “SAP Commerce,” and “SAP Commerce Cloud” used in different contexts. SAP Hybris was the original brand name acquired in 2013. It was rebranded to SAP Commerce (the on-prem product) and SAP Commerce Cloud (the managed cloud product). When people say “Hybris end of life,” they mean the on-prem version — SAP Commerce on-premise version 2205 is the last supported release. SAP Commerce Cloud (the cloud-hosted product) continues receiving quarterly updates and is the target migration destination.

For a detailed breakdown of what stops and what continues, see our EoMM preparation guide.

The Migration Decision Framework

Before jumping into the checklist, you need to answer one question: stay on SAP, or leave?

We’re an SAP partner. We have a commercial interest in keeping you on SAP. So let us be honest about when each path makes sense.

Stay on SAP Commerce Cloud if:

• You run SAP ERP (S/4HANA, ECC) and rely on deep ERP-commerce integration. The native connectors save 200-400 hours of custom integration work.
• Your B2B commerce model uses SAP-specific features — complex pricing, contract management, customer-specific catalogues, approval workflows. Commerce Cloud’s B2B Accelerator handles these natively.
• Your team has SAP Commerce skills. Re-skilling to a completely different platform adds 3-6 months and significant cost.
• You need to move fast. Commerce Cloud migration preserves your data model, business logic, and many customisations — a complete re-platform doesn’t.

Consider leaving SAP if:

• You have no SAP ERP, or the ERP integration is minimal (simple order feed). The SAP premium doesn’t pay for itself without deep backend integration.
• Your storefront is purely B2C with standard catalogue, cart, and checkout flows. Shopify Plus or a composable stack may be simpler and cheaper.
• Your team has no SAP skills and you don’t want to acquire them. Finding SAP Commerce developers is getting harder every year.
• You want to move to a composable or headless architecture long-term — though be warned, that takes 9-15 months, not 4 (read our composable commerce analysis).

For most SAP Commerce on-prem customers, the pragmatic answer is SAP Commerce Cloud. It’s the lowest-risk path, the fastest execution, and the one that preserves your existing investment. That said, “pragmatic” doesn’t mean “automatic” — make this an active decision, not a default.

Explore our SAP Commerce Cloud solution page for a full overview of what the platform offers today.

The Complete Migration Checklist

Twenty-four items across four phases. This is the checklist we use with our migration clients. Print it, pin it to the wall, track every item.

Phase 1: Assessment (Weeks 1-4)

This is the phase most companies rush or skip entirely. Don’t. Everything downstream depends on getting this right.

1. Inventory every customisation. Export a complete list of custom extensions, ImpEx scripts, custom HAC modules, and modified platform APIs. Classify each as: still needed, replaceable by Commerce Cloud native functionality, or obsolete. In our experience, 25-35% of customisations are removable (see our 5 migration mistakes post).

2. Map all integrations. Document every system your commerce platform talks to: ERP, PIM, CRM, payment gateway, shipping provider, tax engine, loyalty system, marketing automation. For each integration, record: protocol (API, IDoc, file-based), data volume, frequency, and the team that owns it.

3. Catalogue your storefronts. How many sites? How many languages? How many product catalogues? Multi-country setups with separate pricing, tax rules, and fulfilment logic add significant complexity. A single-storefront, single-country migration is a fundamentally different project from a 12-country, 6-language deployment.

4. Measure your data volume. Count: products (including variants), categories, customers, orders (historical), content pages, media assets. This drives your data migration strategy and timeline. A platform with 50,000 SKUs migrates very differently from one with 5 million.

5. Assess your SEO footprint. Pull your full URL inventory from Google Search Console. How many indexed pages? What’s the organic traffic value? High-SEO-value sites need a detailed redirect strategy. Losing rankings during migration can cost more than the migration itself.

6. Evaluate team readiness. Do your developers know SAP Commerce Cloud? Have they worked with the Composable Storefront (Spartacus) or the SAP Commerce Cloud Accelerator? If not, factor in training time. Cloud deployment patterns (Kubernetes, CI/CD pipelines, environment management) differ significantly from on-prem operations.

7. Review your licensing position. Check your current SAP Commerce contract terms. Understand what happens at EoMM with your specific agreement — some contracts auto-transition to CSS, others require explicit opt-in. Talk to your SAP account executive early. Licensing negotiations take weeks, and you don’t want contractual surprises during migration.

Phase 2: Architecture & Planning (Weeks 5-10)

7. Choose your storefront approach. Three options:

• Composable Storefront (Spartacus/Angular): SAP’s recommended modern frontend. Headless, decoupled from the backend. Best for new builds and teams comfortable with Angular. Allows independent frontend releases.
• Commerce Cloud Accelerator: The traditional JSP-based storefront, migrated to the cloud. Fastest path if you want to preserve your existing storefront code. Less modern, but proven.
• Custom headless frontend: Your own React/Next.js/Vue frontend consuming Commerce Cloud APIs. Maximum flexibility, but you own the frontend entirely.

For most migrations under time pressure, the Accelerator approach is fastest. For a strategic investment, Composable Storefront is the right choice. We cover the trade-offs in detail in our composable commerce analysis.

8. Design your target architecture. Document the cloud architecture: Commerce Cloud environments (dev, staging, production), integration architecture (SAP Integration Suite vs direct API), CDN and edge caching strategy, and monitoring/alerting setup.

9. Plan your integration rework. On-prem integrations often use direct database connections, file drops, or on-prem middleware. In Commerce Cloud, everything goes through APIs or SAP Integration Suite. Each integration needs a migration plan. Budget 3-5 days per integration for analysis and redesign.

10. Define your data migration strategy. Decide: big-bang migration (full data load in a cutover window) or iterative migration (progressive loading with delta sync). For platforms with over 1 million products, we strongly recommend iterative migration with at least three trial runs before go-live.

11. Create your SEO migration plan. Map every on-prem URL to its Commerce Cloud equivalent. Plan 301 redirects for any URLs that change. Set up a pre-migration benchmark in Google Search Console. See the SEO section below for details.

12. Establish your environment strategy. Commerce Cloud provides development, staging, and production environments. Set up CI/CD pipelines early. Automate deployments from day one — manual deployments at this stage are a red flag.

13. Lock scope. Write it down. Sign it off. The single biggest cause of migration delays is scope creep — “while we’re at it, let’s also…” No. Migrate first, enhance later. This discipline saved us 4 weeks on the Franke project.

Phase 3: Development & Migration (Weeks 11-30)

14. Set up Commerce Cloud environments. Provision and configure all environments. Verify build pipelines work. Validate that you can deploy, test, and promote code through the full pipeline before writing business logic.

15. Rebuild or migrate your storefront. If using the Accelerator, port your JSP templates and frontend assets. If using Composable Storefront, build the new frontend from the Commerce Cloud APIs. For either approach, start with the homepage, category pages, and product detail pages — the highest-traffic templates.

16. Rework integrations. Migrate each integration to the cloud architecture designed in Phase 2. Test with real data, not mocks. Integration testing is where 60% of migration bugs surface (Standish Group, 2020). Test early. Test often.

17. Execute data migration (trial runs). Run at least two full trial migrations before the real cutover. Measure: total time, data accuracy, and error rate. Fix issues between runs. Each trial should be faster and cleaner than the last.

18. Implement SEO changes. Deploy the redirect map. Configure canonical URLs. Set up the XML sitemap. Verify robots.txt. Test with a crawling tool (Screaming Frog, Sitebulb) against the staging environment.

19. Performance optimise. Commerce Cloud has different performance characteristics from on-prem. CDN caching, API response times, and cold-start behaviour all need testing and tuning. Set target metrics: page load time under 3 seconds, Time to Interactive under 5 seconds, Core Web Vitals passing.

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

20. Run comprehensive UAT. User Acceptance Testing with actual business users, not just developers. Cover: product browsing, search, cart, checkout, payment, order confirmation, returns, B2B workflows (if applicable). Test in every storefront, every language, every customer segment.

21. Performance test at scale. Load test with realistic traffic patterns. Simulate peak-day traffic (Black Friday, seasonal surges). Commerce Cloud auto-scales, but your custom code and integrations might not. Identify bottlenecks before they find you in production.

22. Validate SEO migration. Compare the staging URL inventory against the production URL inventory. Verify every redirect works. Check that the sitemap is complete. Test structured data (JSON-LD) with Google’s Rich Results Test.

23. Execute cutover. The cutover plan should be rehearsed at least once. Key steps: freeze content changes on old platform, run final delta data migration, switch DNS, verify all integrations, monitor error rates for 48 hours. Have a rollback plan documented and tested.

24. Post-go-live monitoring. Monitor for 2 weeks minimum: error rates, conversion rate compared to pre-migration baseline, search engine indexing rate, integration failure rates, and customer support ticket volume. Set up alerts for any deviation from baseline.

Timeline Calculator

Not every migration is the same. Here’s what drives the timeline:

Reading these numbers in April 2026: If you’re in the fast-track category, you can still make the July deadline with aggressive execution. Standard complexity? You’ll miss the deadline but can be live by Q4 2026 — meaning 3-5 months on customer-specific support. Complex? You needed to start 12 months ago. The best you can do now is start immediately and minimise your time in the danger zone.

Cost Estimates by Scenario

We get asked this in every initial conversation. Here are honest ranges based on our project portfolio:

Fast-track (single storefront, limited integrations): $300K-$500K. This assumes a focused scope, existing SAP skills on the team, and willingness to defer non-essential customisations to post-migration. Think of it as a platform lift with controlled scope.

Mid-market (2-3 storefronts, moderate complexity): $500K-$800K. The bulk of our migration projects fall here. Budget includes assessment, development, data migration, integration rework, performance testing, and go-live support. Doesn’t include Commerce Cloud licensing — that’s a separate annual cost.

Enterprise (5+ storefronts, complex B2B, multi-country): $800K-$2M+. The range is wide because enterprise complexity varies enormously. A 12-country B2B operation with custom pricing engines, approval workflows, and deep ERP integration is a fundamentally different project from a 5-storefront B2C operation with standard checkout.

These are migration costs — the one-time project to move from on-prem to cloud. SAP Commerce Cloud licensing is annual and depends on your GMV and order volume. For a full breakdown, see our Commerce Cloud pricing guide.

What’s not included in these estimates: Commerce Cloud license fees (annual), third-party tool licenses (PIM, search, CMS if you use external providers), internal team time, and any post-migration enhancement work. Factor an additional 15-20% contingency buffer for unknowns — data quality issues, integration surprises, and scope clarifications that inevitably arise during migration.

Cost acceleration after the deadline: Migration partners — including us — are seeing demand spike. Every consultancy with SAP Commerce skills is fully booked through Q4 2026. If you start in July, you’ll pay premium rates for premium urgency. Starting in April gives you more options and better pricing.

The hidden cost of doing nothing: Customer-specific support after EoMM costs 2-4x mainstream maintenance. For a company paying $200K/year in SAP maintenance, that’s $400K-$800K per year just to keep the lights on — without any improvements, new features, or guaranteed security patches. Two years of CSS costs more than most migrations.

SEO Migration: Don’t Lose Your Rankings

This section exists because we’ve seen companies execute flawless technical migrations and then lose 40-60% of organic traffic because nobody planned the SEO transition. Organic traffic often represents 30-50% of e-commerce revenue. Do the maths on what losing half of that means for your business.

Before migration:

1. Baseline everything. Export from Google Search Console: all indexed URLs, click data, impression data, average position for top queries. Record this weekly starting now — you need the trend line, not a single snapshot.
2. Crawl your current site. Use Screaming Frog or Sitebulb. Get the complete URL inventory, internal link structure, canonicals, and structured data. This is your reference document.
3. Map every URL. Build a spreadsheet: old URL → new URL → redirect type (301 in almost every case). If your URL structure is changing (e.g., /products/category/product-name to /p/product-name), this spreadsheet is critical.

During migration:

4. Implement redirects early. Don’t save this for cutover week. Build the redirect rules as you build the new platform. Test them on staging.
5. Preserve metadata. Page titles, meta descriptions, heading structures, and structured data (JSON-LD, product schema, breadcrumb schema) must all carry over. Re-creating these from scratch is a guaranteed ranking loss.
6. Keep your XML sitemap accurate. The new sitemap should be ready before go-live. Submit it to Search Console immediately after DNS switch.

After migration:

7. Monitor daily for 4 weeks. Watch: indexing rate (how fast Google picks up new URLs), 404 error rate (missed redirects), organic traffic compared to baseline, and ranking positions for your top 50 queries.
8. Fix issues fast. If Search Console shows a spike in 404s or a coverage drop, fix it that day. Not next sprint. That day. The first 2-4 weeks after migration are when Google is re-evaluating your entire site.

What About the Franke Approach?

We migrated Franke from SAP Hybris to SAP Commerce Cloud in 90 days. SAP gave us a Quality Award for it. The full playbook is published here: From SAP Hybris to Commerce Cloud in 90 Days.

The short version: 30 days of preparation before kickoff, ruthless scope management (35% of customisations eliminated), parallel workstreams, and iterative delivery. Not every company can do 90 days — Franke had a focused scope and an aligned team. But the methodology applies to any timeline.

Key takeaways from the Franke approach that apply to every migration:

• Audit before you migrate. We found that 35% of Franke’s customisations were either obsolete or replaceable by Commerce Cloud native functionality. That’s 35% less code to migrate, test, and maintain.
• Parallel workstreams. Don’t sequence storefront, integrations, and data migration. Run them in parallel with daily coordination. This alone can compress a 12-month timeline to 8 months.
• Iterative delivery, not big-bang. Deploy to cloud early, even if incomplete. Get real feedback from real infrastructure. Agile delivery shows 42% success rates compared to 13% for waterfall (Standish Group, 2020).

Read the full Franke case study for the detailed results.

The “Do Nothing” Risk Assessment

Some companies will look at this checklist and decide: we’ll deal with it after July 2026. Here’s what that looks like.

Security risk. Your platform stops receiving security patches. SAP Commerce processes customer data, payment information, and PII. Running an unpatched commerce platform violates the spirit — and possibly the letter — of PCI-DSS, GDPR, and Switzerland’s nDSG. If you’re audited, “we didn’t migrate in time” isn’t a defence.

Compliance risk. VAT rules change. Tax regulations evolve. Data protection requirements update. Without SAP shipping compliance patches, you need to implement these yourself. Most companies don’t have the expertise to modify SAP Commerce core compliance modules safely.

Cost escalation. Customer-specific support costs 2-4x mainstream maintenance. And the cost of migration doesn’t decrease over time — it increases. Developers with SAP Hybris on-prem experience are becoming rarer. Consultancies are booking up. Prices go up after the deadline, not down.

Talent drain. SAP Commerce developers are moving to cloud skills. Finding someone who wants to work on an end-of-life on-prem platform gets harder every quarter. Your existing team may leave for companies running modern stacks.

Competitive disadvantage. While you’re maintaining a frozen platform, competitors on Commerce Cloud are getting new features, performance improvements, and AI capabilities quarterly. Commerce Cloud ships 4 major updates per year. On-prem after EoMM ships zero.

Insurance and audit exposure. Cyber insurance providers are increasingly asking about platform maintenance status. Running an unpatched e-commerce platform with customer data may affect your coverage terms or premiums. External auditors — whether for SOC 2, ISO 27001, or PCI-DSS — will flag an end-of-maintenance commerce platform as a material finding. This creates board-level visibility you probably don’t want.

Next Steps

If you’ve read this far, you know the situation. Four months is tight but workable for fast-track scenarios. For everything else, start now and minimise your exposure window.

1. Book an assessment call. We run a structured migration assessment in 2-3 weeks. It gives you: customisation inventory, integration map, complexity score, timeline estimate, and budget range. Get started here.
2. Read the supporting material. Our EoMM preparation guide covers what stops in detail. The 90-day playbook shows what fast execution looks like. The composable commerce analysis covers the “leave SAP” option honestly.
3. Visit our on-prem campaign page for dedicated resources and migration offers.
4. Don’t wait for Q3. Every week you delay reduces your options. The difference between starting in April and starting in June is the difference between making the deadline and missing it.

The deadline doesn’t move. Your readiness can. Talk to us.