From SAP Hybris to Commerce Cloud in 90 Days: A Migration Playbook

Ninety days from kickoff to go-live is fast for an SAP Commerce project. Most companies plan eight to twelve months for a move from SAP Hybris to SAP Commerce Cloud, and for large, heavily customised platforms that is the right plan. For a mid-size platform with a prepared team and a locked scope, 90 days is achievable. This post describes the method we use for it: what happens before the clock starts, what each sprint delivers and what we deliberately leave out.

We know the pace from our own work. At Franke, we brought the SAP Commerce Cloud platform live in 90 days; that figure refers to the commerce launch, part of a longer partnership in which we replaced a legacy platform with a headless architecture. The project received the SAP Quality Award for “Rapid Time to Value” (Franke case study).

TL;DR: A mid-size SAP Hybris platform can reach SAP Commerce Cloud in 90 days if 30 days of preparation come first: platform audit, data profiling, environments, team alignment. Then three sprints: core platform and first data load (days 1 to 21), integrations and frontend (days 22 to 50), performance, UAT, dress rehearsal and go-live (days 51 to 90). What makes it work is scope discipline, parallel workstreams and weekly demos. Since on-premise mainstream maintenance ended on 31 July 2026, the same plan is the fastest way out.

Need a partner instead of a DIY guide? Spadoom is an SAP Gold Partner for Cloud ERP and Customer Experience and delivers SAP Commerce Cloud implementations across Switzerland, Germany, Austria and Italy, both the Cloud Edition and the ERP Edition for S/4HANA Public Cloud. Request a scoping call.

Why Is 90 Days Achievable?

In our experience, long migration timelines are inflated more by waste than by complexity. A 90-day migration does not cut corners; it removes three things that consume time without adding value.

Analysis paralysis. Teams spend months documenting requirements that already exist in the running system. The current platform is the best specification you have, so read it instead of rewriting it.

One-to-one replication of customisations nobody needs. A workaround from 2017 does not belong on the new platform just because it exists on the old one.

Sequential phases with handoff delays. Every sign-off, handover and context switch between teams costs days, often a week.

Remove those three, and the actual work (data migration, platform configuration, reconnecting integrations, testing) fits into 90 days for a mid-size commerce platform. For larger ones, the same method still shortens the project, just not to 90 days; our migration checklist shows the typical ranges by scenario.

What Happens Before the Clock Starts? (Weeks -4 to 0)

The 90-day clock starts at kickoff. The 30 days before it decide whether the project becomes a controlled sprint or a scramble.

Platform audit (weeks -4 to -3)

We map everything in the current SAP Hybris instance:

• Custom extensions: count them, classify them (still needed, replaceable, obsolete) and estimate the effort for each.
• Data models: custom types, relations and attributes, and which of them map directly to Commerce Cloud.
• Integrations: every inbound and outbound connection (ERP, PIM, CRM, payment, shipping, tax) with protocol, format and frequency.
• Customisation hotspots: the small part of the custom code that carries most of the business logic.

The audit regularly shows that a share of the extensions were workarounds for on-premise limitations that Commerce Cloud covers in the standard. Those leave the scope on the spot, and every one of them is code you do not have to migrate, test or maintain. The five most common migration mistakes start exactly where this audit is skipped.

Data profiling (weeks -3 to -2)

Before anyone touches the migration tools, understand the data. Profile every entity for completeness, consistency and quality. Find duplicates, orphaned records and data nobody has touched in years. Build and test the extraction and load pipeline with a small sample. Problems found here cost hours; found in Sprint 3 they cost weeks.

Environment setup (weeks -2 to -1)

Provision the SAP Commerce Cloud environments (development, staging, production), configure the build and deployment pipelines in Cloud Portal, set up monitoring and alerting, and give everyone access. Unspectacular work, and all of it necessary. The SAP Commerce Cloud documentation covers the environment and deployment model in detail.

Team alignment (week -1)

Finalise the backlog. Give each workstream (platform, data, integrations, frontend, testing) a clear owner. Agree on the Definition of Done for each increment, and set up daily stand-ups and weekly stakeholder demos, so that everyone knows on day 1 what they are working on.

What Gets Done in Sprint 1? (Days 1 to 21)

The first three weeks bring the core platform up on Commerce Cloud with your data models and base configuration.

• Data model migration: custom types, enums and relations, validated against the audit.
• Core business logic: the critical customisations identified in the audit, such as cart calculation, pricing rules, promotions and tax calculation.
• Base storefront: the SAP Composable Storefront with your product catalogue. No custom styling yet; functional correctness comes first.
• First data load: a full migration to staging, with record counts, data integrity and key business flows validated.

What does not happen in Sprint 1: visual refinements, non-critical integrations (analytics, reviews, loyalty), performance tuning and edge-case logic. Saying no to these is what keeps the sprint on time.

Milestone on day 21: a working storefront on Commerce Cloud staging with real data, core business logic and a basic checkout. Stakeholders can browse products, add them to the cart and place an order. It does not look finished yet, but it works.

How Do Integrations Come Together in Sprint 2? (Days 22 to 50)

With the core platform proven, Sprint 2 reconnects the ecosystem, in order of business criticality:

1. ERP and order management: order export, inventory sync, price updates
2. Payment provider: reconnecting the payment gateway through Commerce Cloud’s payment integration
3. Shipping and logistics: rate calculation, labels, tracking
4. PIM and content: product data feeds, media sync
5. CRM and CDP: customer data synchronisation

For each integration: validate the existing API contract, update endpoints and authentication, run end-to-end tests with real data and document any behavioural differences.

In parallel, the frontend team applies the brand styling, builds custom UI components, optimises for mobile and handles SEO: metadata, structured data and redirects from the old URLs.

Milestone on day 50: a fully integrated Commerce Cloud deployment with all critical integrations live, a brand-consistent frontend and an end-to-end order flow from browsing to fulfilment.

What Makes Sprint 3 Different? (Days 51 to 90)

The last phase is about confidence. The system works; now you prove it is ready for production.

Performance testing (days 51 to 60). Load tests with realistic traffic patterns and a peak-day simulation. Find and remove bottlenecks, validate auto-scaling, compare page load times against the targets.

User acceptance testing (days 55 to 70). Business users test every critical flow with real customer accounts and product data, and all integrations under realistic conditions. All P1 and P2 issues get resolved.

Data migration dress rehearsal (days 65 to 75). Run the full pipeline end to end and measure the elapsed time, which defines your cutover window. Validate the delta migration for data created between rehearsal and go-live, and test the rollback procedure. This step is not optional.

Go-live and stabilisation (days 85 to 90). Execute the runbook: delta migration, DNS switch, then 48 hours of monitoring with the full team on standby.

What Makes a 90-Day Timeline Hold?

Looking back at our fastest commerce launches, including Franke, five factors made the difference.

Scope discipline. We migrate what the business needs, not everything that exists. Obsolete customisations stay behind, without nostalgia.

Parallel workstreams. Platform, data, integrations and frontend run in parallel with daily sync points. When one team is blocked, the others keep moving.

Early investment in data. Profiling starts before kickoff, so on day 1 everyone knows what is being migrated and what is left behind.

Iterative delivery with weekly demos. Stakeholders see progress every week, issues surface early and course corrections take days, not months.

An experienced team. People who have done this before recognise the patterns and pitfalls early. That pattern recognition saves more time than any tool.

Speed and quality are not opposites. At Franke, the SAP Quality Award was given for “Rapid Time to Value”, which says exactly that.

Already Past the EoMM Deadline?

Mainstream maintenance for SAP Commerce on-premise ended on 31 July 2026 (SAP Help Portal). If you are still on-premise, you are now on customer-specific maintenance: no regular security patches, no legal updates, individually priced support. What that means in detail, and which interim measures make sense, is covered in SAP Commerce on-premise support has ended: now what?.

The arithmetic of the playbook has not changed: 30 days of preparation plus 90 days of migration make roughly 120 days. What has changed is that every one of those days now runs outside mainstream maintenance. That is a reason to start the preparation now rather than wait for a perfect moment, and to keep the scope as tight as the playbook requires. If your platform is too large for 90 days, split it into waves so the first markets leave the on-premise system early.

For a broader look at what SAP Commerce Cloud delivers today, see our SAP Commerce Cloud solution page. If you are still choosing an implementation partner, our overview of the best SAP Commerce Cloud partners in Switzerland lists the criteria that matter.

---

We review your SAP Hybris instance, map your customisations, profile your data and build a realistic migration plan, 90 days where the scope allows it. Get in touch.

Frequently Asked Questions

Is 90 days realistic for every SAP Commerce migration?

No. Ninety days works for mid-size commerce platforms with a clean preparation phase and a locked scope. Deployments with several storefronts, heavy integration work or large data volumes usually need four to six months or more. The deciding variable is how much unnecessary customisation and technical debt the platform carries.

What is the biggest risk in a 90-day migration?

Data migration. That is why data profiling starts in the preparation phase, before the 90-day clock runs. By day 1 of Sprint 1 you know the data volume, quality issues and transformation rules, and the dress rehearsal in Sprint 3 validates the full pipeline before go-live.

How many people does a 90-day migration need?

A lean team is typical: a few Spadoom consultants covering SAP Commerce, frontend and integration, plus a product owner, business analyst and IT liaison on the client side. Parallel workstreams with clear ownership matter more than headcount; a larger team with sequential handoffs is usually slower.

What happens to SEO when you migrate from Hybris to Commerce Cloud?

URL changes need a complete redirect plan: map all old URLs, implement 301 redirects, carry over metadata and structured data, and submit the new sitemap. When redirects are complete, organic traffic usually recovers within a few weeks. Monitor Search Console daily in the first month and fix 404s the same day.

Can the old Hybris platform and Commerce Cloud run in parallel?

Yes, and we recommend it. The old platform keeps serving production traffic while UAT and performance tests run on Commerce Cloud. The cutover window is typically a few hours for the delta migration and DNS switch. Switching DNS back is only a clean rollback if orders placed on the new platform after cutover are replayed to the old system, so plan that step in the runbook.