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

Recommended Practices for Upgrading SAP Commerce Cloud

10 min read

Recommended Practices for Upgrading SAP Commerce Cloud

This article summarizes some of the recommended practices to follow if you are looking to upgrade your SAP Commerce Cloud solution. These recommendations are divided in two sections organizational and technical recommendations.

The recommendations below are in addition to the Upgrade Project Framework for SAP Commerce Cloud.

Table of Contents


The ultimate practice for upgrades is to get in the habit of upgrading within the quarter of a particular new release. By minimizing the gap between source and target versions you're going to have fewer changes to deal with. Also, your team will get in the habit of upgrading and it can lead to better customization practices to help ease upgrades. The further your source version gets from the latest version, the more work is be required to fix any differences.

This can be difficult to get in the habit of doing, so if you're not going to upgrade frequently make sure you're always on the latest patch for your version of SAP Commerce. If you're on a version <=6.7 then it is the 4th number in the version number (for example, For versions that use YYMM, the patch is after the decimal (for example, 1808.2). Patches are typically released monthly and contain critical security and performance improvements. See this page for more on version numbering and support timelines.


  • Before the migration starts, the Upgrade Team should have an introduction of the functional scope and the features to ensure they all understand the meaning and the usage of the application.
  • Establish a connection for the Upgrade Team to work with the Customer.
  • Team meetings should occur frequently to exchange information/problems/status.
  • Create a group chat (Skype, Slack, and so on) for the entire team (including partner and customer teams) to ensure an open line of communication throughout the project. Giving everyone the opportunity to ask/answer questions in a transparent manner, prevents miscommunication or false assumptions.


  • If you do not have access to existing test environments, assume it will take time to set up test environments.
  • If there are multiple parties involved (partners, 3rd party systems, and so on.), the time required to deploy and support the upgrade will be longer.
  • Regardless of which bug tracking system you use, it is important to determine a way that will allow you to divide your bugs into pre-upgrade bugs and new bugs from the upgrade. Only new bugs found that can be traced to the upgrade should be fixed prior to deploying the upgrade code to production. The upgrade project is not the right time to try to fix old bugs.
  • Data migration should be processed separately from the code upgrade to enable the splitting of the resources. Both tasks can be completed in parallel.
  • Ensure you have allocated enough time to migrate/merge the completed source code into the customer's source control system with plenty of time to test prior to deployment.
  • Use the development and test environment deployments as dry-runs for your upgrade procedure, ensuring you note down the time it takes to complete each step.
  • Tailor your requirements to the features available in the t target version of vanilla SAP Commerce as close as possible. This will make your upgrade easier and safer, while making it easy to. maintain. For example, if your source version created a customized web service layer because it did not exist but it does exist as part of the target version's platform code, it would be best to try to modify business practices to utilize the platform code as much as possible and remove the source version customizations.



  • Ensure you have received the configurations for both production and testing environments.

Data Migration

  • Review how the type system has changed between source and target versions to understand at a high level how much data migration might be required.
  • When migrating data during an upgrade it is important to understand how large your data set is and test how long the update of the data will take.
  • In some cases, such as modifying a single column of 5 million orders, it may be faster to execute a script directly against the database, instead of using the System Update or IMPEX to change the data.

System Architecture

  • The system architecture, network environment, workflows should be created/documented/presented for better understanding to the Upgrade team.
  • The configuration and testing of 3rd party systems should already be documented in detail and shared with the Upgrade team.
  • Depending on your source and target versions there might be differences between synchronization in different versions of platform that need to be accounted for.
  • If system update takes a long time during the creation of objects, check if any SQL query on props table is running.
  • A move from mobile storefront to responsive storefront will require a full template approach to upgrading.

System Configuration

  • If you are still using MD5 for password encoding you should review whether or not you can change to a more secure password encoding option.
  • Deployment to the customer's environments should always be done using the original source control repository.
  • If possible, try to develop a plan that allows for initializing the DB of the migrated system and then restore all necessary order/customer data. It may result in a longer deployment depending on how much data needs to be restored, but it will simplify the actual deployment.
  • If using Celum:
    • the Celum Server has to be migrated before mam tests, because in the case when Celum is not reachable, the tests take much more time (timeouts).
    • During deployment, a DBA with full access to the customer DB server should be available in order to help avoid problems during the creation of DB schemes.
    • In the customer's test environments the upgraded Celum server should use a different port installation/configuration of the customer test system to prevent someone accidentally connecting to the upgraded system.
    • Use URL with the hostname (no localhost) if you want to connect to Celum.


  • Ensure you have reviewed and are familiar with any documentation related to upgrading SAP Commerce that exists for any version between your source and target versions. For example, if you are going from 6.0 -> 6.2 make sure you've reviewed the documentation for upgrading from 6.0->6.1 and 6.1->6.2.
  • Run a baseline Sonar test (see Measuring Code Quality with Sonar) to understand the state of the code. This provides a good overview of how the code is structured and where potential problem areas are. The same test should be run throughout the Execution phase to ensure code quality is not getting worse than baseline. Any new issues found should be fixed with high priority.
  • Spring Security: How much have you customized your Spring security code and configurations? If you are doing a large upgrade it is best to plan for a lot of time to upgrade Spring security, refactor your customizations and retest to ensure your application still passes your security requirements. Compare the spring-security-config.xml in the new version with your old version and look at spring security release notes to determine if that library has changed between your source and target versions; some defaults may have changed. Try to adopt all new security features from the new template and make sure it does not break existing code.
  • Spring Beans: Do you have many circular dependencies in your  spring configuration between extensions? There is also a strong likelihood that  the platform has refactored a lot of beans between your source and target versions. Spring bean refactoring is the   hardest to estimate, but is typically the most time-consuming to refactor so make sure you've accounted for plenty of time for this work.
  • Does initialization build the entire system or was data migrated in manually afterward? If data loading is not done automatically as part of initialization then you need to account for the time to create the IMPEX scripts necessary to load realistic data that can be used for testing consistently across local and lower environments.
  • Customizations to cockpits may break with an upgrade and can be difficult to fix. If you have made significant customizations to your cockpits plan for additional time. Given cockpits have been marked for deprecation, it is better to focus on porting any missing features to backoffice instead.


  • Maintain an environment that is accessible to anyone on the Upgrade Team that is using the same source version currently deployed in production. Any bug discovered during the Upgrade Project should try to be reproduced in this environment to determine if it is an existing bug (that may never have been found) or whether it is directly related to some part of the upgrade.
  • The acceptance tests must be processed by the customer in order to decide if the deployment to production should move forward.
  • All test cases should be defined in the Planning phase, not during the Execution phase when work has already commenced.
  • If possible, use Spock to stub all extensions that work as a gateway to the external systems to allow for the use of these systems without a connection.
  • Start with jUnit tests as they can be run quickly and automatically to determine if a build is broken.
  • Don't test using only the admin user - use business/customer users, similar to real life scenarios.
  • Key scenarios that should always be checked:
    • Login to store with several users from the different groups (customergroup, customerservicegroup, asagentgroup, and so on),
    • Create an order in e-shop,
    • Synchronization (Backoffice, jUnit),
    • Communication to integrations (for example, Celum, Payment, and so on),
    • Execute cron jobs,
  • Any cron jobs problems should be marked with high priority.


  • Be as detailed as possible (screenshots, command line scripts) with your build and deployment guides.
  • Backup all files that were generated during migration (notes, error logs, SQL queries, Impex scripts, screenshots, and so on), as they may be useful for future upgrades.
  • Leverage overview, how-to videos and webinars that are available on to quickly get your users up to speed on how to use any new features/functionality.


Now, you should have an idea of some of the practices and resources available for completing an upgrade. You should also look at some of the child pages where we cover in more detail how to upgrade particular features of the SAP Commerce Cloud solution.