CX Works

A single portal for curated, field-tested and SAP-verified expertise for your SAP C/4HANA suite. Whether it's a new implementation, adding new features, or getting additional value from an existing deployment, get it here, at CX Works.

Migrate to SAP Commerce Cloud: Code Freeze Options for Upgrade and Migration

Migrate to SAP Commerce Cloud: Code Freeze Option for Upgrade and Migration

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 customization's 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 acting on 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 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 Master branch containing all code changes required to migrate from the existing landscape to something that is compatible with SAP Commerce Cloud.


Of the options outlined below, we recommend options 1 and 2. Options 3 and 4 should only be considered if you are unable to accept the first two options. With option 2, we have found a good compromise between flexibility (while minimizing feature and code freezes) and by allowing for defined “merge parties”. This is where developers meet together to figure out any merge conflicts. With options 3 and 4, you will have more flexibility but a greater risk that you will be slowed down due to complexity.

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:


Code Freeze No Code Freeze Between Upgrade and Migration

No Code Freeze, Release Freeze

Continuous Delivery of Features


Option 1 Option 2 Option 3 Option 4
Feature Development

(tick) During the upgrade technical phase

(tick) During the migration technical phase

(error) Not allowed during the migration and testing phases

(tick) During the upgrade technical phase

(tick) Between the upgrade go-live and the start of the migration

(tick) During the migration technical phase

(error) Not allowed during the migration and testing phases

(tick) Continuous (tick) Continuous
Feature Type: Frontend Changes

(tick) Allowed during both the upgrade and migration technical phases

(error) Not allowed during the migration and testing phases

(tick) Allowed during both the upgrade and migration technical phases

(error) Not allowed during the migration and testing phases

(tick) Allowed during the upgrade technical phase

(error) Not allowed during the upgrade testing phase. Not allowed during the migration project

(tick) Always allowed
Feature Type: Logic Changes

(tick) Allowed during the upgrade technical phase

(tick) Allowed during the migration technical phase (previous analysis)

(error) Not allowed during the migration and testing phases

(tick) Allowed during the upgrade technical phase

(tick) Allowed during the migration technical phase (previous analysis)

(error) Not allowed during the migration and testing phases

(tick) Allowed during the upgrade technical phase

(error) Not allowed during the upgrade testing phase and not allowed during the migration project

(tick) Always allowed
Feature Type: Database Change

(tick) Allowed during the upgrade technical phase

(error) Never allowed during the migration project

(tick) Allowed during the upgrade technical phase

(error) Never allowed during the migration project

(tick) Allowed during the upgrade technical phase

(error) Never allowed during the migration project

(tick) Allowed during the upgrade project, any phase

(error) Never allowed during the migration project

Merge Complexity (tick) Lower (tick) Lower (error) Higher (error) Higher
Risks at Merge (tick) Lower (tick) Lower (error) Higher (error) Higher
Responsibility of the Code (tick) Clearly defined at each phase (tick) Clearly defined at each phase (tick) Clearly defined at each phase (error) Unclear. Will have to be defined depending on the nature of the error

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 Engagement Executive or reach out to sapcx-services@sap.com.