Migrate from SAP Hybris to SAP Commerce Cloud: A Step-by-Step Guide

With SAP Hybris on-premise mainstream maintenance ending in July 2026, many organizations have decided that SAP Commerce Cloud (CCv2) is their forward path. It is a logical choice if you have invested heavily in SAP Commerce customizations, your team knows the platform well, and you want to stay within the SAP ecosystem.

But here is the part that catches teams off guard: migrating from on-premise Hybris to SAP Commerce Cloud is not an upgrade. It is not a lift-and-shift. In many cases, it is closer to a re-implementation with the advantage of existing business logic as a reference. The infrastructure model, deployment pipeline, build process, and operational approach are fundamentally different.

This guide walks through the migration step by step, based on our experience with SAP Commerce architectures across multiple industries. We will be direct about what is easy, what is hard, and where teams typically lose time and money.

Let’s establish some baseline expectations that will save you from unpleasant surprises later.

Timeline: For a moderately complex Hybris implementation (10-30 custom extensions, 3-5 major integrations, one or two storefronts), expect 9-15 months from project kickoff to production go-live. Simpler implementations can be faster. Complex multi-country, multi-brand setups with dozens of integrations can take 18+ months.

It is not 1:1: You will not move every line of code. You should not try. The migration is an opportunity to rationalize, simplify, and modernize. Teams that attempt a pure 1:1 copy end up fighting the cloud platform’s architecture rather than leveraging it.

You need SAP Commerce Cloud expertise, not just Hybris expertise. If your team has only worked on-premise, budget for training or external support on CCv2-specific concepts: the Commerce Cloud Portal, manifests, environments, deployment pipelines, and cloud-specific monitoring.

Before planning the migration, you need a clear, honest inventory of what you are working with. This audit phase typically takes 2-4 weeks and covers three areas.

Custom Extensions Inventory

Catalog every custom extension in your Hybris instance. For each one, document:

• Purpose: What business function does it serve?
• Complexity: Lines of code, number of models, number of integrations
• Usage: Is it actively used? When was it last modified? Does anyone actually rely on it?
• Dependencies: What other extensions does it depend on? What depends on it?

In our experience across multiple SAP Commerce projects, 25-40% of custom extensions in a mature Hybris instance are candidates for removal. Some were built for requirements that no longer exist. Others are workarounds for bugs that SAP has since fixed. A few are duplicates of functionality that SAP added to the platform after the custom code was written.

Integration Map

Document every system your Hybris instance talks to:

• ERP systems (SAP ECC, S/4HANA, or third-party)
• PIM systems (SAP Commerce built-in, Akeneo, Informatica, etc.)
• Payment gateways (PSPs, tokenization services)
• Shipping and fulfillment providers
• Marketing and analytics platforms
• CMS systems (if external to Hybris)
• Search engines (Solr, external search services)
• Custom microservices

For each integration, note the protocol (REST, SOAP, IDoc, RFC, file-based), data volumes, frequency, and whether it is synchronous or asynchronous. This map will be critical in Step 6.

Data Assessment

Understand the size and shape of your data:

• Number of products, variants, categories
• Number of customer accounts
• Order history volume
• Content (CMS pages, media assets)
• Configuration data (promotions, pricing rules, warehousing rules)

This feeds directly into your data migration strategy and helps estimate environment sizing on CCv2.

This is the most important step, and the one most often rushed. The decisions you make here determine the trajectory of the entire project.

What to Keep

Start with your differentiating business logic. The custom code that represents genuine competitive advantage or unique business processes should be migrated. If you built a sophisticated multi-warehouse allocation algorithm or a complex pricing engine that handles your specific business rules, that logic needs to come with you.

What to Rebuild

Some code will need to be rewritten to align with CCv2 patterns. Common candidates:

• Job/cron scheduling: CCv2 uses a different approach to background processing than on-premise Hybris
• File handling: Cloud environments handle file storage differently (no persistent local filesystem in the same way)
• Session management: Clustering and session handling in CCv2 follows cloud-native patterns
• Logging and monitoring: You will use SAP Commerce Cloud’s Dynatrace integration and log infrastructure, not your on-premise monitoring stack

What to Drop

Be ruthless here. Every piece of code you migrate is code you will maintain forever. Common candidates for removal:

• Custom infrastructure management code (monitoring scripts, backup routines, deployment tools)
• Workarounds for on-premise performance limitations
• Legacy integrations with decommissioned systems
• Custom functionality that SAP has since added to the platform natively
• Features the business no longer uses

Storefront Decision

If you are running the classic Accelerator storefront, you need to decide whether to migrate it as-is, move to SAP Spartacus (the Angular-based SPA storefront), or build a fully custom headless frontend. Each option has significant implications:

• Accelerator migration: Fastest path, but you are carrying forward a legacy architecture. SAP’s investment is clearly in Spartacus and composable storefronts.
• Spartacus: SAP’s strategic direction, good component library, but it is a significant frontend rewrite. Plan 3-6 months of additional effort.
• Custom headless: Maximum flexibility, but you own the entire frontend stack. Requires strong frontend engineering capability.

SAP Commerce Cloud runs on Microsoft Azure, managed through the Commerce Cloud Portal (CCP). Your environment setup involves several components that do not exist in on-premise Hybris.

Commerce Cloud Portal

The CCP is your management interface for environments, builds, deployments, and monitoring. Familiarize your team with it early. Allocate time for training – it is not complex, but it is different from whatever you were using before.

Environment Strategy

CCv2 provides a defined set of environments based on your subscription tier. Typically:

• Izstrāde (d1, d2, etc.): For active development and integration testing
• Staging (s1): Pre-production validation
• Production (p1): Live environment

If your on-premise setup had six or seven environments for different testing phases, you will need to adapt your workflow. Some teams supplement CCv2 environments with local Docker-based development environments for faster iteration.

Manifest Configuration

The manifest.json file is central to CCv2 deployments. It defines your extensions, AddOns, properties, aspects (server groups), and web applications. Getting this right early prevents a lot of downstream pain.

{
  "commerceSuiteVersion": "2211",
  "enableImageProcessingService": true,
  "extensions": [
    "your-custom-extension-1",
    "your-custom-extension-2"
  ],
  "useConfig": {
    "extensions": {
      "location": "cloud/manifest-extensions.json"
    },
    "properties": [
      {
        "location": "cloud/common.properties",
        "persona": ""
      },
      {
        "location": "cloud/production.properties",
        "persona": "production"
      }
    ]
  },
  "aspects": [
    {
      "name": "backoffice",
      "properties": [
        {
          "key": "cluster.node.groups",
          "value": "integration,backgroundProcessing,services"
        }
      ]
    },
    {
      "name": "accstorefront",
      "webapps": [
        {
          "name": "mediaweb",
          "contextPath": "/medias"
        },
        {
          "name": "yourstorefront",
          "contextPath": ""
        }
      ]
    }
  ]
}

Start with a minimal manifest and add complexity incrementally. Trying to replicate your full on-premise configuration in one go is a common source of early frustration.

With your architecture decisions made and your target environment configured, you can start moving code. This is the longest phase and where most of the hands-on engineering happens.

Build System Changes

On-premise Hybris uses Ant. CCv2 also uses the standard Commerce build system, but the build is triggered through the CCP or via the CCv2 API. Your build must be reproducible from a clean checkout of your repository. If your current build depends on local tooling, scripts, or manual steps, those need to be automated or eliminated.

Repository Structure

CCv2 expects a specific repository structure. Your custom code goes into the core-customize directory, your JavaScript storefront (if using Spartacus) goes into js-storefront, and cloud-specific configuration goes into designated locations. Restructuring your repository is typically a one-time effort, but it needs to be done carefully to preserve git history.

Extension Refactoring

For each custom extension you decided to keep in Step 2, you need to:

1. Review for cloud compatibility: Remove any code that assumes local filesystem access, hard-coded server addresses, or environment-specific configuration that should be externalized.
2. Update deprecated APIs: If you are jumping multiple Commerce versions (e.g., from 6.7 to 2211), you will encounter deprecated and removed APIs. SAP provides release notes for each version documenting breaking changes.
3. Externalize configuration: Properties that differ between environments should be in your manifest or properties files, not hard-coded.
4. Review ImpEx scripts: Essential data imports need to be reviewed for cloud compatibility. Pay special attention to file references and paths.

Custom Build Steps

If your build includes custom steps (code generation, asset compilation, report generation), these need to be integrated into the standard build pipeline or handled differently. CCv2 has specific hooks for custom build phases, but they operate within constraints.

Data migration is often the workstream that derails timelines. It is not glamorous work, but it is essential and always more complex than initially estimated.

What to Migrate

At minimum, you need to migrate:

• Product catalog: Products, variants, categories, classifications, prices, stock levels
• Customer data: Accounts, addresses, consent records, saved carts, wishlists
• Order history: Past orders, returns, and related data (for customer self-service and reporting)
• Content: CMS pages, components, media assets
• Configuration: Promotions, pricing rules, delivery modes, payment configurations

Migration Approach

Two common approaches:

ImpEx-based migration: Export data from the source system as ImpEx files, transform as needed, and import into CCv2. This is the most common approach for SAP Commerce-to-Commerce migrations because both sides speak ImpEx natively. For large datasets, consider using batch imports and carefully sequencing your imports to respect data dependencies.

API-based migration: For cleaner data or when transformations are complex, writing a migration tool that reads from the source database and writes through the Commerce APIs can be more flexible. This approach is slower but gives you more control over data validation and transformation.

Data Cleanup

Migration is an excellent opportunity to clean up data that has accumulated over years of operation. Orphaned records, test data in production, duplicate customer accounts, obsolete products – cleaning this up before migration simplifies the process and improves the quality of your new environment.

Rehearsal

Run your data migration at least three times before the real cutover. The first rehearsal will expose issues you did not anticipate. The second will validate your fixes. The third should be a dress rehearsal at production scale with timing measured.

Every integration in your map from Step 1 needs to be evaluated and reconnected.

What Changes

• Endpoints and URLs: Your CCv2 environments have different URLs than your on-premise servers. Every integration that calls into your commerce platform needs the new endpoints.
• Network topology: On-premise, your Hybris server might have been on the same network as your ERP. In CCv2, it is on Azure. Network connectivity (VPN, peering, public endpoints with IP whitelisting) needs to be established.
• Authentication: Review how each integration authenticates. Some on-premise setups rely on network-level trust that will not exist in the cloud.
• Webhooks and callbacks: If external systems call back into your commerce platform (payment notifications, shipping updates), those callback URLs need to change.

Integration Testing

Test every integration independently before attempting end-to-end testing. Order the testing by business criticality: ERP integration and payment processing first, marketing analytics last.

In our work with multi-country platforms, we have found that integration re-wiring consistently takes 30-50% longer than initially estimated. Build that buffer into your plan.

A migration is only successful if the migrated platform works correctly. Your testing strategy should cover multiple dimensions.

Functional Regression Testing

Every business process that worked on the old platform must work on the new one. Automated test suites are invaluable here. If you do not have them, invest in creating them before the migration, while you still have a known-good reference system to validate against.

Key flows to test exhaustively:

• Product browsing, search, and filtering
• Cart operations (add, remove, quantity changes, promotions)
• Checkout (every payment method, every delivery option)
• Account management (registration, login, password reset, address management)
• Order management (status updates, cancellations, returns)
• Backoffice operations (product management, order processing, customer service)

Performance Testing

CCv2 has different performance characteristics than your on-premise setup. Run load tests early and often:

• Baseline: Establish performance benchmarks on the new platform
• Load testing: Simulate realistic traffic patterns and peak loads
• Stress testing: Find the breaking point so you know your headroom
• Soak testing: Run sustained load for 24-48 hours to catch memory leaks and resource exhaustion

SAP provides Dynatrace for monitoring on CCv2. Learn to use it before go-live so you can diagnose issues quickly in production.

User Acceptance Testing (UAT)

Business stakeholders need to validate that the migrated platform meets their requirements. Allocate 2-4 weeks for UAT and have a clear process for logging, triaging, and resolving issues.

The cutover itself is a carefully orchestrated sequence of events. Plan it in detail, rehearse it, and have rollback procedures ready.

Cutover Sequence (Typical)

1. Announce maintenance window to customers
2. Redirect traffic to a maintenance page
3. Take a final data export from the old platform (orders placed since last migration rehearsal)
4. Run the delta data migration
5. Switch DNS to point to the CCv2 environment
6. Validate critical flows on the live platform
7. Monitor for the first 24-48 hours with enhanced alerting

Rollback Plan

Have a documented, tested rollback plan. If the new platform has critical issues within the first hours, you need the ability to switch back to the old platform. This means keeping the old infrastructure running for a defined period after go-live (typically 1-2 weeks).

Hypercare Period

Plan for 2-4 weeks of dedicated post-go-live support. Have your full team available, with clear escalation paths and defined response times. Issues will surface that did not appear in testing, and you need to resolve them quickly.

These estimates include planning, implementation, testing, and stabilization. They assume a competent team that has done this before. Add 30-50% if this is your team’s first CCv2 migration.

Migrating from on-premise Hybris to SAP Commerce Cloud is a substantial project, but it is also a well-trodden path. The platform is mature, the tooling is established, and there is a growing body of knowledge from organizations that have completed this journey.

The key to success is treating it as a proper project from the start: realistic timelines, honest scope assessment, experienced people, and executive sponsorship that understands both the investment and the value.

If you are evaluating this migration and want an independent architectural assessment, our SAP Commerce consulting services are designed for exactly this situation. We have been working with SAP Commerce platforms for over 12 years, and we can help you navigate this transition with clarity and confidence. You can see examples of the types of projects we have delivered in our portfolio.