Overview

An upgrade and migration project for SAP Commerce Cloud, whether from on-premise or SAP Commerce Cloud on SAP infrastructure, could take several months. This depends on how far your current version is from the target version, and how many customizations you have. During this time, there is the expectation that code can be deployed to the existing site while the upgrade and migration process is ongoing. At some point, no more changes will be allowed in order to align the code. However, when and how you freeze the code can have varying levels of impact on both business-as-usual operations and the ability to deliver an upgrade and migration. In this article, we cover the pros and cons of a variety of code freeze options. 

Table of Contents

Upgrade and Migration Project

For most customers with an existing site, moving to SAP Commerce Cloud will require both an upgrade and migration project (U&MP). The upgrade occurs first and is thoroughly tested before the migration to SAP Commerce Cloud can start. Once the migration is complete, another round of thorough testing is needed to consider the code stable for release. The two parts of the U&MP are impacting the Commerce implementation in very different ways:

• The upgrade aims at upgrading the Commerce Platform to a supported target Commerce version while ensuring all customizations are working properly on the upgraded Platform as it can significantly change the code. This article focuses on the code freeze, so we will only focus on the Upgrade Engineering and Testing portions of the Upgrade Project Framework in this article.
• The migration aims to shift from existing hosting to SAP Commerce Cloud with the focus being on ensuring compatibility with the SAP Commerce Cloud database solution, data, media, as well as changes in operations. In this phase, it is critical that the data structure and its meaning are not changed in order to reduce errors during data migration. A migration project can be split into three main parts: the technical phase (in which the code base is adapted to the new hosting strategy), the migration phase (in which the data copy happens), and the testing phase. 

The above is very important to know since the type of code changes applicable during and U&MP depends strictly on the part and phase in which the project is in. Specifically:

• During the technical phase, it is less risky to introduce new features since the testing phase will spot potential issues.
• During the migration phase, it is absolutely crucial not to impact the operations occurring at the database level. Therefore, having a code freeze during this phase is very important.
• During the testing phase, while some changes might be acceptable, they will impact the coverage and results of the planned tests. Therefore, it is important to keep them to a minimum.
  
  

Code Freeze Options

It is also relevant to note that code merging is a powerful task that can pull together different branches of your code base. However, it often introduces delays due to the complexity of the task and the necessary testing of the merged code. 

In order to execute a U&MP, the use of code versioning and branching is critical. In the options below, we use each branch name as follows:

• Master: The mainline branch for code currently deployed to production. Any bugs found in production will have hot fixes created and tested against this branch.
• Upgrade: A branch from the Master branch that will contain all code changes required to upgrade to a target version.
• Develop: A branch from the Master branch that developers work off of to create new individual features. Once a new feature is complete, it can be tested and merged into the Develop branch.
• Migration: A branch from the Master branch containing all code changes required to migrate from the existing landscape to something that is compatible with SAP Commerce Cloud.

Option 1: Code Freeze

The recommended and easiest approach is to stop any new features from being delivered while the upgrade and/or migration projects are ongoing. This approach minimizes code changes and merge conflicts. It is suitable for U&MP's that are short (for example, when a minimal upgrade or no upgrade is necessary) and it ensures no delays are introduced because of incompatibility of the delivered features.  

Option 2: No Code Freeze Between Upgrade and Migration

This approach implies you need to plan your project in such a way as to deliver features after the upgrade part is done and before the migration part starts. Between these two phases, the code is in a stable version. It has been tested thoroughly after the upgrade and can then be enriched with the developed features. This method ensures that the responsibilities are clearly assigned at every step of the process and also reduces the complexity of code merging.

Option 3: No Code Freeze, Release Freeze

With this approach, the feature development could continue on a separate branch of the master taken before the upgrade and/or migration project began. However, the features are then merged with the project only after successful go-live. This approach introduces no risks on the upgrade and/or migration project. However, since the code merge is occurring at the end of the upgrade and/or migration project, it potentially introduces the most complexity.

Option 4: Continuous Delivery of Features

This approach is the least recommended as it introduces the highest variance of risk and potential delays. This option can be adopted when the release of new features is absolutely necessary, and it is acceptable to introduce more risk in the upgrade and/or migration project. It is important to know that, even if this approach allows for feature releases during the project, the features have to respect the following criteria in order to be compatible with this approach:

• During the upgrade phase:
  • The feature can release frontend, logic, and database changes.
• During the migration phase:
  • The feature can release frontend changes.
  • The feature can release minor logic changes, but requires analysis with the implementation team beforehand for confirmation.
  • The feature can absolutely NOT release database changes, as it would jeopardize the crucial part of data migration in the project.

Comparison of Options

In the following table, various aspects of the described options are considered:

Conclusion

This article provided you with the resources to understand how you can harmonize your project developments while embarking on a migration to the new SAP Commerce Cloud. Although the article tries to answer many of the questions asked by customers, there will always be specific scenarios that may need more clarification. If this is the case or you are interested in starting a migration, please consult with your Account Executive, Customer Success Partner, or reach out to sapcx-services@sap.com.