Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

FAQ on Upgrading SAP S/4HANA Cloud Public Edition

George_Yu
Product and Topic Expert
Product and Topic Expert
‎2024 Apr 12 4:41 PM
12,921

Introduction

With the continuous increase of new customers to SAP S/4HANA Cloud Public Edition, we have received more questions regarding upgrading which occurs every six months, in February and August every year. Although we have several official documents covering this topic, to help our customers and consultants get a quick answer for their questions, I intend to use the Questions and Answers format within this blog. The content will be updated as soon as new information (including questions) becomes available.

If you are interested in learning the overall processes of upgrading and patching the SAP S/4HANA Cloud Public Edition, please read my companion blog Understand Upgrading and Patching Processes of SAP S/4HANA Cloud Public Edition. 

 

List of Frequently Asked Questions and Answers

In the parenthesis after each question, I mark the relevance of the question to 2-System Landscape or 3-System Landscape, or both.

  1. How often do you upgrade SAP S/4HANA Cloud Public Edition (2SL, 3SL)? 
  2. How long does the upgrade last for a 3-System Landscape (3SL)?
  3. What are the differences among Major Upgrades, Updates/Patches, HANA Database Upgrades and Global Infrastructure Maintenance (2SL, 3SL)? 
  4. Why do I see a system error during the upgrade week before Saturday (uptime phase), while I am doing a data migration project in the Production System (2SL, 3SL)? 
  5. What is the Cloud Availability Center (2SL, 3SL)? 
  6. What is the Blue Green Deployment Model for the Upgrades and Updates (2SL, 3SL)? 
  7. What is the Impact to the CBC System during a Major Upgrade (3SL)?
  8. What is the Impact to the ABAP System (Development and Production) during a Major Upgrade (2SL, 3SL)? 
  9. What should I do with Business Roles during a major upgrade (2SL, 3SL)? 
  10. How long does the upgrade last for a 2-System Landscape (2SL)? 
  11. What routine maintenance does SAP conduct to the SAP S/4HANA Cloud Public Edition systems (2SL, 3SL)?
  12. How do I find the new innovations and deprecations relevant to my system in RASD (2SL, 3SL)? 
  13. What are restriction notes (2SL, 3SL)? 
  14. What is the N+1 Transport Dependencies (3SL)? 
  15. Why does SAP include a regression period (2-4 weeks) during a major upgrade (2SL, 3SL)? 
  16. Does SAP inform me about a forthcoming major upgrade (2SL, 3SL)? 
  17. Why transport requests need to be moved to the T and P systems before the upgrade (2SL, 3SL)? 
  18. Is there anything I must do before a major upgrade? (2SL, 3SL)? 
  19. Is there anything I must do and execute after SAP completes the upgrade? (2SL, 3SL)? 
  20. How do I report issues during regression test on Test System (2SL, 3SL)? 
  21. What are the changes of upgrade for 2408 (3SL)?

 

1. How often do you upgrade SAP S/4HANA Cloud Public Edition (2SL, 3SL)?

Currently, there are two major upgrades for the solution, in February and August each year.  They are named as year + month.  For example, Release 2402 is for February of 2024.

Between two major upgrades, there are patches or so called Hot Fix Collections (HFC). Patches are performed every two weeks.  HFCs are applied over the weekend during scheduled system maintenance window.  One weekend contains corrections only.  Another weekend contains corrections as well as new innovations (Continuous Feature Delivery, or CFD).  Details are provided in answers to Question 11.

References:

 

2. How long does the upgrade last for a 3-System Landscape (3SL)?

The entire upgrade lasts four weeks to cover all three systems: Development, Test and Production.

Up to 2408 Upgrade, four weeks are distributed as following:

  • 1st Weekend, Test System Upgrade
  • 2nd Weekend, Starter System, Partner Demo System, Sandbox System, etc. Upgrade
  • 4th Weekend, Development System, Production System Upgrade

For each system's upgrade, it is conducted during the weekend. For US customers, it starts from 10:00 UTC or 5:00 am ET on Saturday and ends at 10:00 UTC or 5:00 am ET on Sunday.  For other regions, please refer to below reference.

Customers will be notified about the upcoming upgrade six weeks before the Test System upgrade.

Reference:

 

3. What are the differences among Major Upgrades, Updates/Patches, HANA Database Upgrades, and Global Infrastructure Maintenance (2SL, 3SL)?

In the world of SAP S/4HANA Cloud Public Edition, we define the following system maintenance activities and their application frequencies:

  • Major Upgrades or Upgrades – They are major software upgrades happening every February and August. They are applied to different systems in different weekends.  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.

References:

 

4. Why do I see a system error during the upgrade week before Saturday (uptime phase), while I am doing a data migration project in the Production System (2SL, 3SL)?

On Friday of the system upgrade week, a customer is preparing to do the data migration on the Production System but got the below system error message.

Picture1.png

The reason is that the system is in the uptime phase and no data migration is allowed.

To minimize the impact to customers, we divide the system upgrade time into two sections: the uptime and the downtime (without logon).  This customer was in the upgrade uptime phase; he can logon to the system but cannot do everything. According to below two SAP Notes, during this uptime phase, there are limitations including no data migration:

  • 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)

If the customer has going-live in the same period of a major upgrade, you need to plan accordingly and don't assume you can get everything done before Saturday.

References:

 

5. What is the Cloud Availability Center (2SL, 3SL)?

In the SAP Help it states: “SAP for Me offers a customizable dashboard view of the status of your SAP Cloud services. The dashboard provides real-time information on incidents (service disruptions, degradations) and scheduled maintenance and upgrade events occurring with your products. Based on your preferences and the possibility to choose and edit the home page to meet your needs, you have quick access to relevant information. Automatically adjusted to your time zone, the Cloud Service Availability features are designed to assist you with your systems”.

However, when you access SAP for Me directly, or follow the path: SAP for Me -> Systems & Provisioning -> Availability, there is no wording like “Cloud Availability Center”. But you are at the right place.

In the below figure, after you apply two filter values, Event Type == Major Upgrade, Cloud Service == SAP S/4HANA Cloud, you get the event notifications about 2402 Upgrade starting from February 17, 2024, at 05:00 local time.

Picture2.png

 

At the time of this writing (April 9, 2024), the upgrade has occurred, so you can see an End Date and Time. When you click on the event notice EV28223884, you can see more info:

  • December 20, 2023, 07:11, event was created to notify the customer a major upgrade will occur on February 17.
  • February 17, 2024, 04:34, another reminder about the upcoming upgrade.
  • February 17, 2024, 05:53, a notification on the successful upgrade to 2402 HFC03.

References:

 

6. What is the Blue Green Deployment Model for the Upgrades and Updates (2SL, 3SL)?

To shorten the downtime of an upgrade process, the 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 the production systems is reduced from 2-3 hours to 1 hour.

Let's digest the below picture together:

  • Step 1 - The system is running on the ABAP codes stored in one schema called blue Version 1. Persistency is the business data stored in a data schema.
  • Step 2 - While old version of the software is running, we create a green Version 1 schema by copying from the blue Version 1 schema. The business transactions are going on without impact.
  • Steps 3 & 4 - While users are still using the blue Version 1 schema, the ABAP codes in the green Version 1 schema is upgraded to the green Version 2. 
  • Step 5 - After all the procedures are done on green Version 2 schema, we now connect the Version 2 schema to the Persistency and switch the end-user connections to the green Version 2 schema.
  • Step 6 - We remove the obsolete blue Version 1 schema, and the upgrade is completed.

The blue green term is from the color of the illustration.

To avoid ABAP code changes to Version 1 (both blue and green schema) during copying and upgrading period, no transports are allowed. The transports are allowed only after the upgrade, and to the green Version 2 schema directly.

Picture4.png

 

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

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.

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 (upgrading and activation).
  • For 3SL T and P Systems and 2SL P 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

Note: There are two flavors of the Blue Green Deployment Method:  the SUM VZDO for the Major Upgrades, and the SOI for the patches/updates/HFCs. I won't elaborate further here or keep everybody's head spinning 😀.

References:

 

7. What is the Impact to the CBC System during a Major Upgrade (3SL)?

Please refer to below figure from SAP S/4HANA Cloud​ - Software Lifecycle Management for Customers​ (9/18/2023). Since the figure is quite complex, let me explain it for your easy consumption.

Picture3.png

 

During the Test and Production System upgrades, there is no impact to the CBC System.  The impact to the CBC system only occurs during the Dev System upgrade.

The entire upgrade process is conducted in several sections (using US as an example):

  • Uptime Phase or Lock Phase (~32 hours):
    • From 0:00 UTC on Friday to 10:00 UTC on Saturday
    • Mainly does ABAP software upgrade using blue-green deployment method. No ABAP code transports. But users can logon and do business transactions.
  • Downtime Phase (~24 hours):
    • From 10:00 UTC on Saturday to 10:00 UTC on Sunday
    • The system is down to all users. It is called Major Upgrade Window (MUW) and has further sub-phases:
      • Continuing ABAP software upgrades
      • Upgrading and activating the CBC Business Content
      • Resolving possible issues

The impacts to the CBC System during the Development System Upgrade are:

  • Avoid large deployments from CBC from Tuesday or Wednesday and on (assume upgrade occurs on Saturday). Because we don’t want long running deployments (you cannot pause it in the middle) still running on CBC system and Dev system when Major Upgrade Window (MUW) starts.
  • Although you can work on CBC during the uptime phase until CBC Content Upgrade starts within the MUW on Saturday morning, deployments from CBC is disabled about 2 hours after Uptime Phase starts, i.e., 02:00 UTC on Friday (SAP Notes 3133118 and 321593), for the same reason as above.  
  • Business Configuration is possible until 8 hours before downtime (SAP Note 3215993).
  • Organizational structure enhancements, new scope or country addition are possible until the CBC Business Content upgrade starts and the CBC Project is locked (SAP Note 3215993).
  • While the CBC Business Content is upgrade and activated, the CBC projects are locked.
  • As part of the CBC Business Content Upgrade, relevant content transports are created in the Dev System, and subsequently moved to the T and P Systems according to the existing transport schedule.
  • The CBC System is reopened after the end of the MUW.

During Starter/Partner Demo System Upgrade, the impact is the same as the Dev System Upgrade.

Reference:

 

8. What is the Impact to the ABAP System (Development and Production) during a Major Upgrade (2SL, 3SL)?

Please refer to below figure from SAP S/4HANA Cloud​ - Software Lifecycle Management for Customers​ (9/18/2023). Since the figure is quite complex, let me explain it for your easy consumption.

Picture5.png

 

From Release 2202, SAP has been using the Blue-Green Software Deployment Method (see above question) for upgrades and patches. This helps to keep the downtime as short as possible.

As shown in the above figure, 3SL D and P systems are being upgraded in the same weekend. So, we treat them the same unless noticed differently.

The entire upgrade process is conducted in several sections (using US as an example):

  • Uptime Phase or Lock Phase (~32 hours):
    • From 0:00 UTC on Friday to 10:00 UTC on Saturday
    • Mainly does ABAP software upgrade using blue-green deployment method. No ABAP code transports. But users can logon and do business transactions.
  • Downtime Phase (~24 hours):
    • From 10:00 UTC on Saturday to 10:00 UTC on Sunday
    • The system is down to all users. It is called Major Upgrade Window (MUW) and has further sub-phases:
      • Continuing ABAP software upgrades
      • Upgrading and activating the CBC Business Content
      • Resolving possible issues

The impact to the ABAP system during the upgrades are:

  • Right before the upgrade starts, try to avoid running large Git-Enabled Change and Transport System (gCTS) imports, because we want to have a stable system when Lock Phase starts, and no left-over imports are still running.
  • At the Uptime Phase (light blue, about 32 hours) or Lock Phase, the systems are still open for users. Due to the copy of Version 1 ABAP code is occurring (see above blue-green deployment question), we want to keep ABAP code stable.  That’s why no transports are allowed, including import from gCTS.
  • From 14 hours before downtime phase, customizing work on the Dev system is locked as well. Because we are copying all the existing configurations to the new green system.
  • At the downtime phase (dark blue), systems are not available for end-users. The switch from the blue Version 1 to the green Version 2 is happening. This wraps up the ABAP system upgrade process.  After that, the CBC Business Content upgrade and activation happen.  
  • Even when the software upgrade downtime phase is over, we are still in the Major Upgrade Window, and need to wait until the CBC business content upgrade is finished. This usually does not take long. That’s why we don't logon to the system until a handover email arrives.   

Reference:

 

9. What should I do with Business Roles during a major upgrade (2SL, 3SL)?

As a cloud solution, the SAP S/4HANA Cloud Public Edition undergoes major upgrades every six months, in February and August each year.  Besides introduction of new innovations, there are many changes in the Identity and Access Management (IAM) area as well.  After going-live and implementation consultants leaving the project, most customers overlooked the IAM area due to lack of resources and expertise. I have two relevant blogs filling this gap.

The first blog Review Business Role Changes before a Major Upgrade in the SAP S/4HANA Cloud Public Edition intends to explain what you need to do before a major upgrade. Besides replacing deprecated Business Catalogs with their successors, the primary effort lies in understanding what is to be changed around Business Roles, especially those roles already used in the Production Tenant. Some decisions are to be made together with business users from the line of business.

The second blog is Review and Adapt Business Roles after a Major Upgrade in the SAP S/4HANA Cloud Public Edition.  It explains the adaptation work of Business Roles after a major upgrade with examples. You need to roll up the sleeves to get the job done in the system.

References:

 

10. How long does the upgrade last for a 2-System Landscape (2SL)?

All upgrades are conducted during the weekend. For US customers, it starts from 10:00 UTC or 5:00 am ET on Saturday and ends at 10:00 UTC or 5:00 am ET on Sunday.

Customers will be notified about the upgrade six weeks before the Quality System upgrade.

Up to 2408 Upgrade

  • 1st Weekend, Quality System, Starter System, Sandbox System Upgrade
  • 3rd Weekend, Production System Upgrade

Reference:

 

11. What routine maintenance does SAP conduct to the SAP S/4HANA Cloud Public Edition systems (2SL, 3SL)?

There are three types of maintenance conducted to the SAP S/4HANA Cloud Public Edition systems:

  1. Upgrades – Also called Release Upgrades and Major Upgrades.  Upgrades deliver the major innovations to customer systems.  It is conducted twice a year, in February and August. For 2SL systems, it lasts 2 weeks; for 3SL systems, it lasts 3 weeks. For each system, the upgrade is performed in one day over the weekend. For example, in US, it starts from 10:00 UTC on Saturday to 10:00 UTC on Sunday.
  2. Patches or Hotfix Collections (HFC) – Patches are performed every two weeks.  One weekend contains corrections only.  Another weekend contains corrections as well as new innovations (Continuous Feature Delivery, or CFD). 
    1. 2SL: Patches are applied to quality systems and production systems separately.  For example, in US, the Quality Systems starts from 2:00 UTC to 14:00 UTC on Saturday; the Production systems starts from 4:00 UTC to 8:00 UTC on Sunday.

Note: The longer patch window for non-productive systems in the 2-System Landscape is due to the usage of a standard deployment model, instead of the Blue Green Deployment Model.

b. 3SL: Patches are applied to all systems over one weekend.  For example, in US, it starts from 4:00 UTC to 8:00 UTC on Sunday.

3. Infrastructure Maintenance – this maintenance covers hardware, network, etc. activities.  It has a four-hour window.  For example, in US, it is 4:00 – 8:00 UTC on Sunday.

References:

 

12. How do I find the new innovations and deprecations relevant to my system in RASD (2SL, 3SL)?

With each major upgrade, SAP releases many new innovations as well as retires some old business objects.  How to minimize or be prepared for the “Day One Impact”? One way is to check the What’s New Viewer. There are more than 800 items listed for Release 2402 alone. You must be overwhelmed by this number!

There is a nice tool comes to your rescue: the Release Assessment and Scope Dependency (RASD) Version 2.0. This tool highlights the changes in Apps, APIs, CDS Views, and Business Catalogs relevant to your own systems ONLY. This immediately narrows down your work scope.

There are two ways to access the RASD:

Here is an example of the RASD output. We usually pay more attention to the production system; therefore you should use the filter to set Tenants = Production to further narrow down the scope.

Picture6.png

 

There are many blogs discussing how to deal with the new, deleted/deprecated business objects. I list some of them for your convenience in the References.

References:

 

13. What are Restriction Notes (2SL, 3SL)?

For each new major release, we have limitations regarding various features and functions, for example, key user imports, configurations, data migrations, product master creation, etc. You encounter errors like "Function locked, software update running in parallel". We advise customers to closely review these documents.  Below are some of 2402 related Restriction Notes:

 

14. What is the N+1 Transport Dependencies (3SL)?

As our major upgrade process starts from the Test System, and then move to the Development and Production Systems after three weeks, it creates a release version inconsistency among them for three weeks. After the Test System is upgraded, it is at the Release N+1, while the other two systems are still at the Release N.

In this situation, the Transport Management System allows you to transport certain requests differently:

  • Key User Extensibility: Can move from D to the T and P systems, but some requests might be blocked to the T system.
  • Developer Extensibility: Can move from the D to the T and P systems.
  • Customizing: Can move from the D to the T and P systems.

As you can see, the Key User Extensibility might run into a trouble. The details are explained in the below SAP Help.

Important: You can't import a transport created on Release N into Release N+2 and higher, which means you must recreate a new transport request in the development system.

Reference:

 

15. Why does SAP include a regression period (2-4 weeks) during a major upgrade (2SL, 3SL)?

As answered in Questions 2 and 10, it takes 2-4 weeks to conduct a major upgrade in your system landscape, from Quality System to Production System (2 SL) or from the Test System to Development System and Production System (3SL).  The reason is to give our customers sufficient time to prepare and react.  This duration could be even longer based on the feedbacks we received from customers.  For example, after the Test System is upgraded, we expect a thorough regression test is conducted, and any issues are raised and resolved either internally or with SAP.  With that approach, we can keep the “Day One Impact” to a minimum, because after the Production System upgrade is done over the weekend, users are going to use the system on Monday immediately.  You have no more opportunity to do one round of testing in the Production System.

References:

 

16. Does SAP inform me about a forthcoming major upgrade (2SL, 3SL)?

Yes. About six weeks before the Major Upgrade, SAP email the IT Contact person of your organization as well post an event notice in the SAP4Me.

In the following screenshot, you can see three notifications for 2402 Major Upgrade, and another three for 2408 (I use the Event Type filter here). 

Picture7.png

 

By clicking on EV23403387, we can see the clear information about the notice.  It is a Major Upgrade for a Test System on July 28, 2024.

Picture8.png

 

When you scroll down further, a copy of email sent to your IT Contact is displayed here as well:

Picture9.png

 

17. Why transport requests need to be moved to the T and P systems before the upgrade (2SL, 3SL)?

As a Best Practice, we want our customers moving existing transport requests from the Development System to the Test and Production Systems (3SL), or from the Quality System to the Production System (2SL). The reason behind that is the software version compatibility.  In the SAP S/4HANA Cloud Public Edition, before a transport request can be imported, there is a compatibility check. You cannot move the content from Release N to Release N+2.  Only from N to N or N to N+1 is allowed.  This rule is strictly followed.

If your existing transport request within the Development System is older (for example at Release N, but Test System is at Release N+3), you need to recreate a transport request on the Development System which is at Release N+2 or N+3.  Then the newly created transport request can be imported to the Test System, and subsequently to the Production System. When this happens, we advise you to move the newly created transport request right away to avoid facing the same situation again down the road.

Reference: 

 

18. Is there anything I must do before a major upgrade? (2SL, 3SL)?

There are many things to do before the upgrade. Luckily, SAP Activate has a clear list for us already:

  • Upgrade Preparation
    • Initiate the Upgrade Project
    • Align Ongoing Project Timeline
    • Prepare Transport Before Upgrade
  • Regression Test for SAP S/4HANA Cloud Upgrade
    • Prepare for Post Upgrade Testing
    • Maintain Test Process and Test Plan for Customer Test

A good source of information is the What’s New Viewer. Four weeks before the Test Tenant upgrade, SAP publishes Preliminary What’s New documentation for the upcoming release. The formal What's New documentation is released after the system is upgraded.  For a major upgrade like 2402, it has over 800 entries. By using the filter of “Valid as of”, “Line of Business”, “Solution Area”, etc., a user can find out the New or Changed information in his/her interest. We need to pay special attention to new functionalities, and new/deprecated apps.  About business role changes, refer to my blog Review Business Role Changes before a Major Upgrade in the SAP S/4HANA Cloud Public Edition.

References:

 

19. Is there anything I must do and execute after SAP completes the upgrade? (2SL, 3SL)?

There are many things to be done after SAP completes the upgrade. Luckily, SAP Activate has a clear list for us already:

  • Regression Test Execution
    • Execute Regression Testing
    • Analyze Post Upgrade Test Result
    • Analyze Customer Test Results
  • Manage Upgrade
    • Manage Transport During Upgrade
    • Revise Business Roles and Business Catalogs
    • Deploy Upgraded Business Content

A good source of information is the What’s New Viewer. The final version of the What's New documentation is released after the system is upgraded.  For a major upgrade like 2402, it has over 800 entries. By using the filter of “Valid as of”, “Line of Business”, “Solution Area”, etc., a user can find out the New or Changed information in his/her interest. We need to pay special attention to new functionalities, and new/deprecated apps.  A thorough regression test on the Test/Quality System is a must.  About business role changes, refer to my blog Review and Adapt Business Roles after a Major Upgrade in the SAP S/4HANA Cloud Public Edition.

References:

 

20. How do I report issues during regression test on the Test System (2SL, 3SL)?

Right after your Test System is upgraded (3SL), or your Quality System is upgraded (2SL), we strongly advise our customers to conduct a regression test. This test can be conducted with the Automatic Test Tool or by human testers.  The intention is to discover potential issues so that you don’t have a Day One Impact on your production system.

In case an issue is discovered, and you need to report to SAP, please use the [R] prefix at the beginning of the ticket subject line to get sufficient attention from our support colleagues.  We usually set aside support resources to address issues surfaced from the regression tests. There is only a 2–3-week window to get these issues resolved before production system upgrade.  It is a joint effort between the customer and SAP to avoid any potential Day One Impact after the production system upgrade.

21. What are the changes of upgrade for 2408 (3SL)?

As the upgrade techniques get more matured, SAP operations team can shorten the upgrade time by 22 hours (!) from 2408 Upgrade. Here are the breaking downs:

  • Reducing MUW from 24 hours to 8 hours
  • Reducing Uptime Phase from 34 hours to 28 hours (shift transport lock time to weekend)
  • Separating D and P Upgrade Starting Time (D starts 8 hours ahead of P)

For details, see my companion blog Understand Upgrading and Patching Processes of SAP S/4HANA Cloud Public Edition. 

 

Update History:

  • First Edition: April 12, 2024
  • Added shortened upgrade time from 2408: June 28, 2024
1 Comment
Popular Blog Posts