What happens to the Change Projects between the 14 days during Quarterly Upgrades for SAP S/4HANA Cloud, Essentials Edition
- Ever wondered what happens to the existing Change Projects during the Quarterly Upgrades of S/4HANA Cloud, Essentials Edition?
- Ever wondered if you can create new change projects between the 14 days of Q and P release upgrades?
- Ever wondered what happens in case you mistakenly release the change project in between the 14 days of Q and P release upgrades?
These are some frequent questions related to Change Projects and Quarterly Upgrades which arise to customers/partners/related stakeholders during their Implementation and Operational phases of S/4HANA Cloud (ES).
- Lets first understand about the Maintenance & Upgrade Schedule Calendar
Now before we start, it is utmost important to understand the Quarterly Upgrade schedule for S/4HANA Cloud Essentials as mentioned here in the hyperlink -> Maintenance and Upgrade Schedule
- S/4HANA Cloud (ES) Upgrade Release Strategy
SAP upgrades the release version of the S/4HANA Cloud (ES) systems every quarter (once in 3 months) in the months – February (2nd month), May (5th month), August (8th month) and November (11th month) in a year which brings in new features, enhancements and fixes for the solution to run their business seamlessly in the age of digital transformation and high competition. These versions are termed with four digits <XXXX>, the first two digits for the year and the last two digits for the month in which upgrade is executed. (Example: Year 2019 and the upgrade in the month of August which is the 8th month will be named as S/4HANA Cloud (ES) 1908 release version). As of now the S/4HANA Cloud (ES)release 4 upgrade cycles in a year and till further notice about any changes in the upgrade release strategy from SAP, S/4HANA Cloud Essentials will continue to deploy 4 upgrade cycles with no choice for customers to change the Upgrade schedule and its corresponding downtime related dates/time. All Customers/Partners will undergo the upgrade cycles equally in upgrade waves for which the Service Center will communicate the dates before the 6 weeks of the Q system Upgrade via emails. These mails are sent to two contacts from the Customer/Partner – First the IT Contact and secondly the Customer Communication Contacts who are registered with SAP Service Center.
- S/4HANA Cloud (ES) Upgrade Cycles/Waves
Now that being said about the Upgrade Cycles, the next thing to understand is about how the upgrades are positioned in the S/4HANA Cloud (ES) Landscape. Customers can essentially have Starter, Quality(Q) and Production(P) Systems at a time. One thing to note about the Starter systems is that the Starter system will be decommissioned after 30 days from the delivery of the Production system. The service center executes the upgrades across all the systems in so called Upgrade Waves -> 1st Upgrade Wave which is designated only for Quality systems on the first weekend of the Upgrade Month and the 2nd Upgrade Wave which is designated for Production, Starter and Partner Demo Systems. The two waves are placed 2 weeks (14 days) apart from each other. To get more specific information like dates and timings, please go through the above Maintenance and Update Schedule. For example, for the year 2002 the below calendar shows the wave cycles and their respective timelines:
- Change Projects in S/4HANA Cloud (ES) during Upgrades
Coming back to the original question about the Change Projects, which are the transportable bundles of configurations, originated from Q systems and ultimately imported into the P systems holds the highest position during scoping/configuration of the systems. In the S/4HANA Cloud Essentials, only a limited amount of configurations activities are directly allowed to be done in the P systems, whereas the remaining and a major amount of configuration is done in the Q system >> captured into a change project >> transferred into P system after finalizing. The transports are inclusive of not just business configurations but also scope activation & country/region addition. Naturally this being a transfer process, totally relies on transport import mechanism which has an inherent requirement of having the same release base version between the Sender (Q System) and the Receiver (P System). So, any configurations captured at the Q systems in the Change Project cannot be transferred into the P system unless both the systems are on the same release version.
SAP highly recommends having a configuration freeze between the Q and P upgrades as mentioned in the above Activate Roadmap section – Execute Transport Sprints. New functionalities deployed via the upgrades might require thorough testing (technically & functionally) in the Q system before it is decided to be moved on into the P system and hence the recommendation of holding the release of the change projects for 2 weeks at minimum.
Customers/Partners can still release and open new change projects during the Q – P upgrade window depending on the criticality and impact, but as a best practice it is suggested that customer leverage this time for utilizing for getting support over the regression & post-upgrade testing issues and get dedicated support over it. Certain cases like Chart of Account Maintenance , resolving regression issues in alignment with Service Center and Development support or crucial configuration might require the opening of the change project in these times and can be considered for new business change project opening.
It is also strongly proposed that Customers/Partner transfers all the existing change projects from Q to P system prior to the Wednesday before the Q system is upgraded. Additionally, moving extensibility objects (custom fields, custom logic, email templates, form templates, or queries), bank definitions etc. using the Export Software Collection & Import Software Collection process is also supposed to be considered before the Wednesday of the Q Upgrade. Also it is a good practice to clear out the ATO queue before upgrade preparation so that it poses no issues during the upgrade execution. The recommendations hold true for all types of Collections which are required to be moved into P system. Regression testing in the Q systems should be a key activity for customers before creating new change projects in case P system is not yet Gone Live.
Though the customer can release and create new change projects during the 14 days window between Q and P upgrade, the transfer of the Change projects will only be executed after both the systems are on the same version. So, the configurations will not be transferred and reflected in the P system till P is upgraded after 2 weeks from Q upgrade. The above dated image shows the timelines and the intended activities during the 23 days duration of the upgrade month.
For ease of understanding, please see the below table which explains in a bit more comprehensive way about the change projects and its general recommendations:
|Action during the 14 days between Q and P Upgrades||Possibility||Recommendation||Comments|
|P system live||P system not live||P system live||P system not live||P system Live||P system not live|
|To open new Business Change Project (BCP)||Possible||Possible||Not recommended||BCP’s can be opened||It is not recommended to open change projects when the P system is live, as the customer is expected to perform Regression testing during this period. The upgrade period should be reserved for testing of new functionalities and request support for regression issues. CoA maintenance and fix for regression/testing issues can be considered for releasing & opening new change projects during this times as exceptions||For Customers who have no P system live, BCPs may be opened for configuration, but it is recommended for possible regression testing during this period. Also leveraging this period to learn about the new functionalities should be considered to gain the best benefits of the innovations from quarterly release upgrades.|
|To create new Software Collection in Q||Possible||Possible||Not recommended||Software Collections can be opened||It is not recommended to create software collections when the P system is live, as the customer is expected to perform Regression testing during this period. The upgrade period should be reserved for testing of new functionalities and request support for regression issues||For Customers who have no P system live can create new software collections but it is beneficial to perform regression testing during this period and focus on getting any issue identified fixed via support|
|To release old Business Change Project (BCP – existing business configuration)||Possible||Possible||Not recommended||Not recommended||It is not recommended to release old change projects for either live or non-live P systems during upgrade timelines, as it is highly advocated to release/close the change projects before upgrade preparations (Wednesday prior to Q upgrade date). Also even if the project is released during the 14 days, the transport will not be imported into the P system until P system has been upgraded to the same release as Q system. The transports generated during the creation of change projects gets queued up in the P import buffer and gets automatically imported all at once after the P is upgraded|
|To release new Business Change Projects (BCP)||Possible||Possible||Not recommended||Not recommended||It is not recommended to release old change projects for either live or non-live P systems, as it is highly advocated to release/close the change projects before upgrade preparations (Wednesday prior to Q upgrade date). Also even if the project is released during the 14 days, the transport will not be imported into the P system until P system has been upgraded to the same release as Q system. The transports generated during the creation of change projects get queued up in the P import buffer and gets automatically imported all at once after the P is upgraded. CoA maintenance and fix for regression/testing issues can be considered for releasing & opening new change projects during this times|
|To release old Software Collection in Q (existing objects)||Not Possible||Not Possible||NA||NA||The software collection apps does not allow any software collection to be transported from Q to P unless both the systems are in the same release|
|To release new Software Collection in Q||Not Possible||Not Possible||NA||NA||The software collection apps does not allow any software collection to be transported from Q to P unless both the systems are in the same release|
For more details and understandings, please follow the below bullet points :
- The details about the Q to P transport process is available in the link -> https://help.sap.com/viewer/b17ac6f2e3e34629a5b205a5b2c8ea11/2002.500/en-US/f2032855a2014d6f98d5faeef5bdc151.html
- Prepare for Quarterly Upgrade, Service Center Cut Off dates for requesting Q, P systems and key recommendations for other service requests are mentioned in the link -> https://go.support.sap.com/roadmapviewer/#/group/BE47098A-617A-43EF-A27E-DFD801D70483/roadmap/IMPS4HANACLDENMGMT:t16/node/901B0E6D3F441ED99B884D0C8EE44803:t16/901B0E6D3F501ED99892FFE517CCBD0A:t16
- Frequently Asked Questions about Q to P transport process -> https://help.sap.com/viewer/b17ac6f2e3e34629a5b205a5b2c8ea11/2002.500/en-US/1a3be267a86b401d8b608f2e77009847.html
SAP S/4HANA Cloud Expertise Services
Thanks for this info, it definitely helps layout what goes on during releases. As a related question, is there a timeline for us getting visibility into what changes are part of each change project? That would certainly aid us in managing change heading into and after releases.
Hi Ryan Muller : Thanks a lot for your feedback.
Regarding timelines, it is expected that the customers keep an eye on the maintenance and upgrade schedule as it is published well in advance. This should give ample amount of time for preparations and configurations to be finalized and confirmed to be moved into the P system.
In order to prepare aptly for an upgrade please go through this task in Activate Roadmap - https://go.support.sap.com/roadmapviewer/#/group/BE47098A-617A-43EF-A27E-DFD801D70483/roadmap/IMPS4HANACLDENMGMT:001999B7BD851ED68D97F853D2C742CE,901B0E6D3F501EE6ABB4713604755B4A/node/901B0E6D3F501EE79BAA53C96ED45EA0
You can also check into the current open change project about all the configurations which are being worked on or confirmed.
If you wish to see the previous changes you can check it via the option - "View Change History" in the "Manage Your Solution" app.
Hi Saumitra Deshmukh ,
I've looked in View Change History and it doesn't show what config is actually in the change project, it only has space for text which is only as good as the person entering it and really isn't acceptable from an audit standpoint. I know we are not alone in asking for that functionality (and have been asking for it for a while).
Thanks Ryan Muller for the feedback. Surely we will investigate further on this requirement with our development. Also having CBC in the pipeline for configurations, we shall also see if it can potentially address this point.
Thanks again for the feedback.
This is great information! Thank you for sharing Saumitra Deshmukh ! I have passed along to additional colleauges 🙂
Thanks for sharing !