CX Works

CX Works brings the most relevant leading practices to you.
It is a single portal of curated, field-tested and SAP-verified expertise for SAP Customer Experience solutions

Upgrading your SAP Commerce Solution

16 min read

Upgrading your SAP Commerce Solution

New versions of SAP Commerce are released periodically, either through patches or feature and large-scale releases. The recommended practice is to be on the latest version in order to take advantage of all new features, bug fixes, and improvements. Granted, it can be difficult to remain up to date depending how far behind you are from the latest release or how much customization your solution has. This article will outline practices to upgrade your current source version to a target version.

This article focuses on upgrades (e.g. SAP Commerce version 1808 to 1811). If you're looking to move from an on-premise version to SAP Commerce Cloud these are covered in our "Migrate to SAP Commerce Cloud" article.

Table of Contents


There are two main drivers for you to perform an upgrade project:

  • Supportability,
  • Enabling new features that were released in the target version of the product.

The best way to look at completing an upgrade of SAP Commerce is to treat it like a normal Project Delivery, but with some small–yet significant–differences. The differences are best outlined in the diagram below and are covered in our article on Upgrade Project Framework for SAP Commerce Cloud.

This section will focus on how you can implement each phase and the activities within each phase. Additionally, it will cover:

  • Why you should upgrade
  • Roadmaps
  • Versioning and deprecation process
  • Types of upgrades ("like for like" and "extended") 
  • High-Level effort to upgrade between versions

This video provides an overview on how CX Works can help with upgrades.

Importance of Upgrades

Before you learn how to upgrade you need to understand why you should upgrade, by watching Five Reasons to Upgrade Your SAP Hybris Commerce Platform.

You should know that each new release of SAP Commerce includes the following:

  • Functionality - Transform your business with new or enhanced features. You will also be receiving bug/security fixes and performance improvements
  • Innovation - Use the new and enhanced features to bring innovation to your customers.
  • Simplification - Replace custom code with out-of-the-box feature
  • Integration - Integrate easily with key systems
  • Support - Run on a fully supported version (product support generally ends 2 years after a version's release)
  • Deprecation - Code/features you may be relying on are part of deprecated code and you may want to move to the feature that replaces it, so you are no longer relying on deprecated code

Not sure what's included with each new version? Go to and select the What's New section for any version you can find the Release Notes which include the documentation and media outlining new features. It also include Documentation Release Notes, which detail any major changes to the code and tips for upgrading your current version. Further it includes codes marked as deprecated and follows its deprecation process. Here's an example from the latest version

If you're interested in the feature changes in a specific module that have been introduced across multiple versions you can review the Feature List by Release page in the product documentation.

If you're considering an upgrade take a look at the SAP CX Upgrade Services page because it includes a self-assessment tool to learn more about your upgrade journey.


"When is feature X going to be ready?" – a question that is asked a lot. Through wiki you can access the Roadmap page, which outlines (at a high level) potential new features and functionality that are planned for future releases. Before upgrading, you might want to know what is planned for upcoming releases and think about how it could affect your application. Although the information on that page is subject to change, it could provide insight into the general direction that SAP Commerce is taking and decide when to upgrade. It can also help you determine investments for projects not related to upgrades; if you can afford to wait for a feature that may be integrated into SAP Commerce Cloud, you may not have to invest the time and effort to create your own custom version.

Versioning, Deprecation and 3rd Party Compatibility


If you're not running an upgrade make sure you are on the latest patch for your version of SAP Commerce (see option #1 on this page). If you're on a version of SAP Commerce <=6.7 this is the 4th number in the version number (e.g. For versions starting with 1808 the patch is the first digit after the decimal (e.g. 1808.3). Patches are released monthly and contain critical security and performance improvements.

What's the difference between 4.7 and

Prior to the release of  SAP Commerce 1808--which use the format YYMM–SAP Commerce used a versioning system to explain whether a particular release is a major, a feature, a minor, or a patch release. Understanding the process by reviewing Supported Releases can help you determine how behind your version is from the latest release and the potential effort required to upgrade. For example, a patch release would not typically require any code change outside of switching out the platform binaries. This should also mean a quicker regression test. In comparison, a major upgrade would most likely require more requirements to cover new features, refactoring of your customizations, and an extensive set of regression and performance tests to make sure nothing is broken in your application. The upgrade projects process covers in this section is focused mostly on major and feature upgrades.


It is also important to understand the deprecation process. Each major or feature release could include the deprecation of a particular feature within SAP Commerce. It's best to look at what's been deprecated and evaluate how the removal of the feature will affect your requirements. An example of deprecation status can be found in Deprecation Status. For example, if you know the Hybris Management Console (HMC) has been deprecated and will be removed from releases in Q2 2018 (version 6.7), you should probably not create a new functionality that resides in HMC. In addition, you should consider how you will transition off of using the functionality that exists within the feature being deprecated. When you see something deprecated you should ask:

  • Do we use this feature in our current implementation?
  • Is there a known migration plan that we can use to transition to something else?
  • Are there any other alternatives available that can fulfill current business needs?
  • Do we need to alter the way we work to take advantage of new features that may be replacing the deprecated feature? 
  • Should we plan to continue using the deprecated feature even after the support period expires (typically 24 months after it is removed from the release)? Do we want to take on this level of risk?

Let's discuss the Hybris Management Console further as an example. It was announced as end of life in v6.6 and was planned to be removed from the suite in the v6.7 release. This meant if you wanted to use and receive support for the HMC you wouldn't be able to upgrade the Q2 2018 release, because it is not part of the suite. Only code that is part of the suite, for a particular version, will be supported for 24 months. You would have to remain on the Q1 2018 release that has 24 months of support for the HMC, which is basically bug fixes. No new features will be added. There are cases where you can pay to get extended support, but this is the general rule and what you should expect.

Assuming you upgrade to Q2 2018 release and try to add the HMC into it, it is extremely unlikely you will get product support (they have every right to refuse it). HMC is not a self-contained extension and it is likely that a lot of the code it depends on would be removed at the same time. This means you would need an extensive customization to get it working again. Even if it is just putting back all the old code that is supported with Q1 2018 from the the support's team perspective it is not something they are responsible for.


With each new release, the supported compatibility with 3rd parties may change. This might mean the version number changed, or it is possible that something previously supported may no longer be supported. When evaluating an upgrade it is important to review the Third-Party Compatibility page for the version you are upgrading to, as it may require you to upgrade things like your database or Java version. Depending on your internal policies or other applications running on the same servers, a change in version could require additional steps and approvals. This should be factored into your timeline. It is also possible that a particular browser, application server, or database is no longer supported. If your requirements need one of these items that are no longer supported, it is up to you to decide between the following options:

  1. Should the requirements be changed, so we are using a supported item? In the case of browsers, how would this affect our customers that use the unsupported browser?
  2. Should we continue using an unsupported version of the 3rd party item and take on the risk of some part of the SAP Commerce not working?
  3. If there is no option to change the requirements and running unsupported is deemed too risky, should avoid upgrading? What new risks does that bring from a security and support standpoint?

Roles and Responsibilities

In order to have a successful Upgrade Project, it's important to have specific roles within the team to support the process, the activities, and the corresponding deliverables. Given that an upgrade will typically use a Partner or SAP CX Expert Services, it is critical that each of these roles have clear defined responsibilities that support these activities and deliverables.

The following diagram outlines the roles and responsibilities associated with an Upgrade Project:

SAP CX Expert Services/Implementation Partner

(all * are optional roles):

Role Responsibilities
Lead Manager/Solution Delivery Manager
  • Part of the steering committee; oversees and reports on the direction of the project
  • Works with Customer Lead Manager to act upon any escalations from Project Managers
Project Manager
  • Manages project revenue and costs
  • Prepares project work orders and invoicing
  • Project resourcing
  • Planning of project life cycle phases and activities
  • Monitoring progress against project plans
  • Reports progress to the steering committee
  • Coordinates meetings with the customer and other external teams
  • Coordinates handover to application support team
  • Manages dependencies on external teams
  • Risk management
  • Issue escalation management
  • Ensuring appropriate packaging and delivery of deliverables for each project phase
  • Managing work environment
  • Ensuring excellent communication and collaboration between all internal and external teams
  • Motivating teams to meet their objectives
Upgrade Lead
  • Very experienced Upgrade Engineer with skills in project management
  • Complete technical responsibility of the SAP Commerce solution:
    • Defines the necessary tasks (installation, development, tests, documentation, etc.) to upgrade the application;
    • Maintains the build plan
    • Assigns the tasks to the available Upgrade Engineers;
    • Is responsible for the quality of the upgrade;
Upgrade Engineer
  • Java developer with experience developing Hybris Commerce, with skills for databases and web applications.
  • Supports the Upgrade Lead by executing upon the upgrade plan
QA Manager
  • Responsible for the tests of the upgrade application in the test environment prior to delivery to the customer
  • Assists the QA Manager in executing and reporting on tests


Role Responsibilities
Lead Manager
  • Part of the steering committee; oversees the direction of the project and adjusts as needed
  • Receives and acts upon any escalations from Project Managers
Project Manager
  • Responsible for the project organization on customer side;
  • The customer Project Manager has the permission to provide approval for the upgraded application upon its completion
Deployment Manager
  • Is responsible for the deployments to customer's test and production environments
  • Assists with troubleshooting any issues in customer's environments
QA Manager
  • Responsible for executing all tests of the upgrade application in the customer's test environment
  • Assists the QA Manager in executing and reporting on tests
Lead Business Analyst
  • Support the Migration Upgrade Lead if any business-oriented questions about the application are raised.
  • Represents the business and is the authority on how the application functions pre and post upgrade
Business Analyst*
  • Helps provide additional research/analysis for any business-oriented questions
Technical Architect
  • Support the Upgrade Lead if any technical-oriented questions about the application are raised.

Types of Upgrades

When performing an upgrade there are three options, which we will refer to throughout this section. The process outlined in the diagram in the "Introduction" section remains the same for all options, however, the level of effort varies. Regardless of your method, we recommend you review the documentation to know what needs to be changed for each version between your source and target versions.

For example, if you're on 5.7 and want to upgrade to 6.2, then you should review the notes for 5.7->6.0, 6.0->6.1 and 6.1->6.2 to make sure you understand all the changes and potential work involved.

Like for Like Upgrade

With a "like for like" upgrade the focus is on upgrading to the target version with the following considerations:

  • all custom features that work in the source will work the same in the target version
  • enable features that are available out of the box, or with minimal configuration

With a "like for like" upgrade the focus is on maintaining existing features, but on the newer target version. This is best illustrated below.

In this case, you can see all features from the source version were upgraded, including custom features, but with the upgrade, you could also take advantage of a new feature that was available out of the box and only requires minimal configuration.

This method is mostly used when the upgrade is driven by security and support reasons. At the conclusion of this upgrade type, the application should function as it did when it was running the previous version.

Extended Upgrade

An extended upgrade is a super-set of a "like for like" upgrade, in that it upgrades all desired features from the source version and then includes all desired features that are available in the target version. This type of upgrade can result in a target version that can be substantially different from the source version, depending on which features are added or removed during the process. This is best illustrated below where you can see "Feature B" has been removed and "Feature Z" was enabled via a code customization. Typically, Both of these scenarios would not occur with a "like for like" upgrade unless there is a reason (e.g. compatibility) that would warrant it on a per-feature basis.

This type of upgrade is usually used when the upgrade is driven by a desire to take advantage of one or more large features that are made available in the target version. It could involve significant code refactoring to make sure that all desired features work in the target version.

Functional Upgrade

Full Lifecycle Project

A fourth option is a full lifecycle project (FLP). This option is considered an edge-case of a functional upgrade, where there is little or no software reuse resulting in a new implementation. Since this option is considered an edge-case it is noted here, but not explored further as a bona fide option for an upgrade project.

A functional upgrade, in contrast to the other two kinds of upgrades, uses a template approach. The latest accelerator templates are used first to generate the custom extensions for the project. Afterwards, the custom business logic is carried over from the legacy code base into the new code base.

This type of upgrade is typically used when the upgrade is driven by a desire to take advantage of one or more large features that are made available in the target version and begin with the latest accelerator templates as a starting point. This type of upgrade it is strongly recommended when the source version of SAP Commerce is below version 5.7. The basis for this recommendation is that the technical approach is most appropriate for upgrading from SAP Commerce 6.0 or higher to the latest release due to the upgrade effort involved. But when upgrading from SAP Commerce 5.6 or earlier to the latest release, the functional upgrade is most appropriate because of the upgrade effort involved. This is a rule of thumb, not a hard and fast recommendation. 

You should now have a good idea of why you should upgrade and a high level understanding of how to upgrade. If you're looking to complete an upgrade project framework you should look at the Upgrade Project Framework for SAP Commerce Cloud article. If you're looking for general tips and practices for upgrades take a look at the Recommended Practices for Upgrading SAP Commerce Cloud section.