Introduction

George_Yu

Introduction

For the SAP S/4HANA Cloud Public Edition solution, the upgrade happens every six months and patches are applied every other week. To the customers and consultants new to this solution, I’d like to explain this process in an easy-to-understand way in this blog. Separately, I have written three other upgrade related blogs to give you a full picture of the topic (see reference section).

Notes:

All times shown in this blog are for North America for the convenience of our discussion.
No discussion on the upgrade of Partner Demo System, Starter System, and Test System, as they usually are not critical or impactful to the customer users from the upgrade perspective.
Our discussion will focus on CBC based 2 System Landscape and 3 System Landscape, Dev and Production Systems in particular.

Terminologies for High Level Schedule of Upgrade and Patches

When we talk about upgrades and patches, understanding some terminologies is critical. Let me list them here:

Major Upgrades or Release Upgrades or Upgrades – They are major software upgrades happening every February and August. They are applied to different systems in different weekends in a period of several weeks. A numeric software release version is assigned, for example, 2402 is for February 2024 release.
Updates or Patches – They are conducted every other weekend. Two weeks after the Major Upgrade, a Hotfix Collection (HFC) with corrections is applied. Two weeks later, another HFC with both corrections and new innovations (called Continuous Delivery Service, CDS) is applied. The cycle continues until next Major Upgrade. The HFC deployments are performed on the same dates to all systems. The Hotfix is labeled like HFC03, standing for the third hotfix collection.
HANA Database Upgrades – About four weeks before the Major Upgrade, a mandatory HANA Database Upgrade is applied, so that the Major Upgrade of the S/4HANA Cloud Public Edition solution can be performed.
Global Infrastructure Maintenance – They are conducted in the maintenance windows no other activities are present to change the hardware, router, operating systems, network, etc.

With above definitions in mind, we can easily navigate the Upgrade and Patch Schedule published by SAP in the SAP S/4HANA Cloud - Software Lifecycle Management for Customers (9/18/2023). Let’s take the 3-System Landscape (3SL) systems as an example in Figure 1.

Figure 1. High Level Schedule of Upgrades and Patches for 3SL Systems

On January 26-28, Release 2402 and HFC02 was applied to Test Systems. This marks the beginning of the 2402 Upgrade cycle.
On February 2-4, Release 2402 and HFC02 was applied to Starter Systems, Partner Demo System, etc.
On February 16-18, Release 2402 and HFC03 was applied to both Development and Production Systems. In the same weekend, HFC03 was applied to previously upgraded Test Systems and Starter Systems. This marks the end of the 2402 Upgrade cycle, and all the systems are at the same level: 2402 HFC03.
On March 1-3, two weeks after D/P System Upgrade, HFC04 (green box) was applied to all systems. This HFC04 is for corrections (bug fixes) only.
On March 15-17, another two weeks later, HFC05 (brown box) was applied to all systems. This HFC05 is for corrections (bug fixes) as well as new innovations (features).
This HFC Patch application cycle repeats every two weeks until Release 2408 Upgrade cycle starting on July 26-28 to the Test Systems.
Every month there is one weekend reserved for Global Infrastructure Maintenance (blue boxes).

Blue Green Deployment Method

To shorten the downtime of an upgrade process, SAP S/4HANA Cloud Public Edition takes the advantage of available virtual machines to do the software upgrade (ABAP code in particular). This model reduces productive system downtime drastically. In average, the downtime for production systems is reduced from 2-3 hours to 1 hour.

As Figure 2 illustrated, Blue Version 1 schema is the old set of ABAP codes. Persistency is the customer business data stored in the SAP HANA Database. While old version of the software is running, we create a Green Version 1 schema by copying from the Blue Version 1 schema. While users are still using the Blue Version 1 schema, the Green Version 1 schema is upgraded to the Green Version 2. After all the procedures are done on the Green Version 2 schema, we now connect the Green Version 2 schema to the Persistency and switch the user connections to the Green Version 2 schema. Now the system is running on the latest release. Finally, we drop the Blue Version 1 schema. The blue-green term is from the color of the illustration.

To avoid ABAP code and data structure changes to Version 1 schema (both blue and green schema) during copying and upgrading period, no transports and configurations are allowed. This includes the data migration, as it could alter the table structure. The transports are allowed only after the upgrade, and to the Green Version 2 schema directly. This is the root cause of all the restrictions applied during the upgrade.

Figure 2. High-level Walkthrough of the Blue-Green Deployment

Roughly speaking, above Steps 1- 4 are in uptime phase (business users can still run transactions), and Steps 5 - 6 are in downtime phase (no users are allowed in the system).

From Release 2105 HFC04, we introduced the Blue Green Software Deployment model for all 3-System Landscape system types and 2-System Landscape production systems, in applying patches/HFCs.

From Release 2202, we introduced the Blue Green Software Deployment model for the Major Upgrades.

The concept of the Blue Green Deployment Model was used in on-premises solution in the past (called near zero downtime maintenance, or NZDM) to a limited number of customers, due to the high cost of using the 2nd production scale server ($$$) for a short period of time. With widely available virtual machines for a short period of time in the cloud data center, this approach has been accepted as a normal process in upgrade operations.

The Blue Green Deployment Method applies to ABAP code upgrade, not Business Content activation. It works well in the Central Business Configuration (CBC) based 3SL systems, as Business Content is decoupled from the ABAP code.

Why the Blue Green Deployment Method applies to all system types (D, T and P systems) in 3-System Landscape, and only the production systems in 2-System Landscape?

The Blue Green Deployment Method applies to ABAP code upgrade, not Business Content activation. In 3SL Dev System, the CBC Business Content and the ABAP Code are decoupled. So, we upgrade ABAP code using the Blue Green Method first, then the CBC Business Content subsequently (upgrading and activation).
For 3SL Test and Production Systems and 2SL Production system, there is no involvement of the CBC Business Content upgrade, so we use the Blue Green Method for ABAP code upgrade. The activated CBC Business Content are imported to them via transports.
For the Quality and non-productive systems in 2-System Landscape, since majority of them are Solution Builder based, they are coupled with the ABAP codes. The Business Content activation is the main driver of the downtime. We use the standard SPAM deployment model (see SAP Note 3042314 - Hotfix Collection deployment for RISE with SAP S/4HANA Cloud). The consequence is a longer downtime. This is not obvious in Production System upgrade, but during patch/HFC application for the Quality system, it becomes obvious:

For the Quality and Starter systems in 2SL: 12 hours - from 02:00 to 14:00 UTC on Saturday
For the Development systems in 3SL: 2 hours - from 04:00 to 08:00 UTC on Sunday

Upgrade a CBC Based System

Figure 3 illustrates the timeline of upgrading a development or a production system based on the CBC. The entire upgrade process is divided into two primary phases: the Uptime Phase and the Downtime Phase. During the Uptime Phase, the business users are still using the system for business transactions. It is about 34 hours (2+18+14). Only during the Downtime Phase, no business users are allowed on the system. The Downtime Phase is also called the Major Upgrade Window (MUW). It is about 24 hours.

Figure 3. Detailed Upgrade Timeline for SAP S/4HANA Cloud Development and Production Systems

Let’s focus on the line Milestones. The milestone Start of upgrade preparation marks the beginning of the Uptime Phase. It starts at 0:00 UTC on Friday, or 19:00 EST on Thursday. Thirty-four hours later, it reaches the milestone Start of SAP S/4HANA Cloud downtime processing which marks the end of the Uptime Phase and the beginning of the Downtime Phase. After system switch, we start CBC Business Content upgrade at the milestone End of S/4HANA Cloud downtime processing & start of content upgrade. This process lasts about three hours until next milestone End of content upgrade. The entire upgrade wraps up at the milestone End of Major Upgrade Window, or 10:00 UTC, or 5:00 EST on Sunday.

Let me do a one-to-one match with the Green Blue Deployment Method I just discussed, as in Figure 4.

Figure 4. One-to-One Match between Upgrade Timeline and Blue Green Deployment Method

At the milestone Start of upgrade preparation, the system is still running in the Blue Version 1 schema. Two hours later, we are entering Green Version 1 copying phase for about 18 hours. This is also called Uptime Phase 1. According to SAP Note 3097708 - Release upgrade for RISE with SAP S/4HANA Cloud 2-System and 3-System Landscape and SAP Note 3042314 - Hotfix Collection deployment for RISE with SAP S/4HANA Cloud, there are limitations during this uptime phase. We want Blue Version 1 schema to be stable in terms of ABAP codes and database table structure; otherwise, Blue Version 1 and Green Version 1 schemas are inconsistent.

For 2SL Quality, Starter and Partner Demo Systems, and 3SL Test, Starter, Partner Demo and Dev Systems
- No release of Transports Requests
- No In-App Extensibility (Extensibility Explorer)
- No Data migration ("Migrate your data" app is in read-only mode)
- Or activities such as Scope Extension, Add New Country, Expert Configuration
For 2SL and 3SL Production Systems
- No Imports
- No Data Migration (“Migrate your data" app is in read-only mode)

The next 14 hours are reserved for upgrading the Green Version 1 to the Green Version 2 to the new release. It is called Uptime Phase 2. All restrictions in Uptime Phase 1 still apply.

At the milestone Start of SAP S/4HANA cloud downtime phase, we are officially entering the downtime phase. The first task (about 2 hours) is to switch user connections and Persistency from the Blue Version 1 to the Green Version 2 schema. This will enable users to use the upgraded ABAP codes to conduct business transactions. It is the sole purpose of an upgrade.

For a CBC based system, we not only upgrade the ABAP codes, but also upgrade and activate the Business Content. This task takes about three hours. It is not part of the Blue Green Deployment Method.

The entire MUW reserves 24 hours, but we only used 5 hours so far, because we built-in 19 hours reserve to deal with possible issues. Good news is that our past upgrade experiences show that this MUW can be further reduced. You will see an official announcement on reduced Downtime Phase starting from 2408 upgrade. This is a win-win case for both customers and SAP.

Impact to the CBC/SB System Usage during an Upgrade

Now let me change our perspective: how the Central Business Configuration (CBC) or Solution Builder (SB) system usage is impacted during an upgrade? I put CBC/SB related restrictions into the upgrade timeline for the ease of discussion (Figure 5).

Figure 5. Impact to the CBC/SB System during an Upgrade

The SAP Central Business Configuration (CBC) System allows users to configure business processes. The configuration conducted on the CBC system is deployed to the Development System, and subsequently a relevant transport is created to deliver the same configuration to the Test and Production Systems.

With the introduction of the CBC system, we decoupled the business content from ABAP codes. That is one step forward from the Solution Builder based system. However, we still need to pay attention to the possible impact to the CBC system or the S/4HANA ABAP system during an upgrade.

As illustrated in Figure 5, up until 02:00 UTC on Friday, there is no limitation on the CBC System usage. It is a solid green except we advise our customers don’t run large CBC deployments. The reason is that it is hard to estimate how long it would take for a large deployment, for example deploying 50 scopes from 20 countries. We cannot stop a deployment if it slips into the light green zone (after 02:00 UTC on Friday).

From 02:00 UTC on Friday, we are entering Uptime Phase 1 (copying the Blue Version 1 schema to the Green Version 1 schema). A stable Blue Version 1 schema is a must. Therefore, we don’t want any deployments from the CBC system to the Development System, as the configuration could change the table structure in the Blue Version 1 schema.

For the Solution Builder based system, locking starts earlier than the CBC based system, at 20:00 UTC on Friday. The reason is that Business Content and ABAP codes are coupled together. The importing and activating are executed along with ABAP code upgrade.

For CBC based system, before complete locking at 12:00 UTC on Saturday, you can still work on org structure enhancement, new scope or country addition. This gives users more time to work on the CBC system.

Impact to the ABAP System Usage during an Upgrade

Figure 6 illustrates the impact to the ABAP Systems, namely the Development System and the Production System, during an upgrade.

Figure 6. Impact to the ABAP Systems during an Upgrade

Before Uptime Phase 1 at 02:00 UTC on Friday, although it is solid green, we need to limit the imports from large Git-Enabled Change and Transport System (gCTS). The reason is similar as CBC content deployments as we don’t know how long it could last.

From 02:00 UTC on Friday, to safeguarding the consistency between the Blue Version 1 schema and the Green Version 1 schema, we put the following limitations:

For Production System
- No importing transports
- No data migration
For Non-Production System, like Development System
- No release of transports
- No in-app extensibility
- No data migration
- No customization

From 10:00 UTC on Saturday and on, the system is completely locked up for business users to execute following tasks:

Switch user connections from the Blue Version 1 schema to the Green Version 2 schema and connect the persistency to the Green Version 2 schema.
For the Development System, we import and activate Business Content, and create activated business content transports. This takes about 3 hours.
For the Production System, we only import the activated Business Content. It only takes about one hour.

As discussed above, there might be potential issues need to deal with. We have a 19-hour window built-in for that. Users are not advised to logon to the system until an official email from SAP operations team arrives. At that time, the upgrade is officially completed.

General Process of a Major Upgrade Cycle

Based on the above discussions, I hope it becomes easy for you to understand the overall process of a major upgrade cycle for the SAP S/4HANA Cloud Public Edition. We take the 3-System Landscape as an example (Figure 7), and you can adapt it to the 2-System Landscape systems accordingly.

Figure 7. General Process of a Major Upgrade in a 3-System Landscape

If we take the Test System upgrade as time Week 0, we need to start upgrade preparation work four weeks before Week 0.

Review new innovations/features, new/deprecated Apps, new/deprecated Business Roles in the Preliminary What’s New Doc
Release transports
Initiate an upgrade project

During the Test System upgrade, customers don’t get involved too much most of the time. The job is after the upgrade:

Review the final What’s New Doc
Conduct Regression Tests
Report issues and resolve them before Production System Upgrade
No transports from D to T possible until D/P upgrade is done

The Development and Production Systems upgrade is the heavyweight of the upgrade cycle. You need to plan carefully, especially when you have activities overlapping with the upgrade week as we discussed above, not just the weekend activities.

Watch the restrictions during Uptime and Downtime Phases
If a go-live is scheduled around a major upgrade period, plan the overlap activities carefully

There are still a few more tasks after the Dev/Prod system upgrade:

Sync transports in all 3 systems
Revise Business Roles and Business Catalogs
Deploy updated Business Content to T and P systems

Conclusion

This blog explained the overall process of a major upgrade in the SAP S/4HANA Cloud Public Edition, especially the constraints you might experience due to the upgrade method we use in the ABAP system and the Business Content upgrade in parallel. The overall system downtime has been reduced due to the adoption of the Green Blue Deployment Method. We can see further reduction of the Major Upgrade Window due to the process optimization by the SAP cloud operations team in the coming upgrades.

Understand Upgrading and Patching Processes of SAP S/4HANA Cloud Public Edition

Introduction

Terminologies for High Level Schedule of Upgrade and Patches

Blue Green Deployment Method

Upgrade a CBC Based System

Impact to the CBC/SB System Usage during an Upgrade

Impact to the ABAP System Usage during an Upgrade

General Process of a Major Upgrade Cycle

Conclusion

References

Useful documents on SCN

Evolution of ABAP

Analytics in S/4HANA - real shape of embedded analytics and beyond embedded analytics