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: 

What happens to the Change Projects between the 14 days during Quarterly Upgrades for SAP S/4HANA Cloud, Essentials Edition

Saumitra
Product and Topic Expert
Product and Topic Expert
‎04-23-2020 8:03 AM

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


 

Best Regards,

Saumitra

SAP S/4HANA Cloud Expertise Services
Labels:
6 Comments
Popular Blog Posts