RIG SAP S/4HANA 2020 Upgrade Document and key considerations
Relevant for SAP S/4HANA 2020
Disclaimer: The following upgrade plan and description is based on the landscape availability, infrastructure, database size and business requirements for our SAP RIG testing system. It is NOT intended to be a reference or recommendation for all systems.
SAP furthermore reserves the right to change any tooling or advice given in this blog without further notice.
Although we still have some customers on their journey to adopt SAP S/4HANA, there are lots of customers running different SAP S/4HANA on premise versions productively and have been already executing their SAP S/4HANA maintenance procedures like SAP S/4HANA release upgrades to leverage not only the latest improvements, but also the availability of further functionalities for their businesses. Also, for those who adopted the early innovations available by the very first SAP S/4HANA release (1511) the year of 2020 was also relevant for upgrades since this version was out of standard maintenance after December 31st, 2020.
Alongside with this blog we will share some important information collected from our experience during a release upgrade for our SAP RIG testing system from SAP S/4HANA 1909 FPS02 to SAP S/4HANA 2020 FPS00 with an embedded SAP Fiori front-end server.
At the bottom you will find our RIG upgrade document download link including:
- Planning steps for Maintenance Planner for stack.xml file generation and target solution version definition
- Screenshots from SUM during all upgrade phases including additional steps or SAP Notes used to solve some situations encountered during the procedure
For this SAP testing system it was time to move to a different hardware infrastructure. The SAP S/4HANA 1909 instance and SAP HANA database were installed on the same server. Furthermore, the OS version was not supported anymore for SAP S/4HANA 2020. Therefore the following approach was followed:
- A new server with an SAP S/4HANA 2020 supported OS version was set up on the new hardware infrastructure
- New SAP HANA 2.0 SP 05 (Rev 52 at that moment) was installed
- The source SAP S/4HANA 1909 application server was copied over to the new server using the homogenous system copy procedure
- SAP S/4HANA 1909 on the new hardware was upgraded to S/4HANA 2020 using SUM 2.0 SP09 SP1 (version available at that moment)
SAP S/4HANA 2020 UPGRADE CONSIDERATIONS
Here are some important considerations related to the S/4HANA 2020 upgrade procedure:
- Supported OS versions for SAP ABAP Platform
Please check SAP Product Availability Matrix (PAM) in advance before your upgrade procedure start since some optimizations were introduced with SAP S/4HANA 2020 and especially some Linux distributions like SUSE Linux Enterprise Server 12 (SLES12) and Red Hat Enterprise Linux 7 (RHEL7) were discontinued, so an OS upgrade may also have to be considered in your upgrade plan.
- SAP HANA Revision
Although SAP HANA 2.0 SP05 is a requirement (minimum revision 50) for SAP S/4HANA 2020, you should always check SAP Note 2655761 – “SAP S/4HANA – restrictions and recommendations regarding specific revisions of SAP HANA database for use in SAP S/4HANA” for specific recommendations to take into consideration for use of a given SAP HANA revision with SAP S/4HANA.
It is also important to notice that SAP HANA 2.0 SP04 is supported until June, 2021 and that SAP is providing long-term support for 5 years for SAP HANA 2.0 SP05 (please check SAP Note 2378962 – “SAP HANA 2.0 Revision and Maintenance Strategy”). Depending on your upgrade schedule and your customer´s maintenance windows an update to SAP HANA 2.0 SP05 should be evaluated and planned even before the actual upgrade to S/4HANA 2020.
- Maintenance Planner
Throughout 2020 SAP Maintenance Planner was updated, received some new functionalities and new look and feel (please check this video for a quick overview of new features) but the overall SAP S/4HANA upgrade plan procedure is still similar.
Although not specifically related only to the SAP S/4HANA 2020 version we encountered some situations where SUM would ask for specific “missing archives” which were not really necessary. The error message and further details can be checked in SAP Note 2443114 – “Missing archives in download directory for Product ERP/S4HANA in phase PREP_INPUT_CHECK/READDATA_EXP”. The solution would require resetting the SUM upgrade procedure, updating your source system details in SAP Maintenance Planner, executing a new planning transaction and starting the SUM upgrade from scratch.
To avoid such a situation, please make sure that your source system details have been recently updated in SAP Maintenance Planner (you may even trigger a manual SLD synch and update), click on “Verify” (in the SAP Maintenance Planner check screen) and perform the verification process even if the status is green right before executing the MP transaction plan.
- Simplification Item Check
There is a trend for number of Simplification Items (especially big, disruptive ones) to decrease from SAP S/4HANA release to release. Indeed, there are only very few new Simplification Items with SAP S/4HANA 2020. Consequently, upgrades get easier from release to release as there would be less impact through new Simplification Items when old SAP ERP functionality still had to be used in the previous SAP S/4HANA release.
In our test system we manually reviewed the relevancy for 12 items only (some of them were not applicable for our scenario) and basically had no actual tasks to be executed at that moment. The items were much more informative like obsolete transactions and changes in some authorization objects that should be considered after the upgrade.
Here is an example (not a reference for all systems) from the Simplification Items reported for our test system:
PS: please check and implement SAP Note 2965544 – Check LSO activation status in S4 landscape to update this Simplification Item check according to latest news about Learning Solution availability in SAP S/4HANA.
- SDMI (Silent Data Migration Infrastructure)
Silent Data Migration is a data conversion technology used in S/4HANA upgrades and conversions as of target release S/4HANA 1909 that allows migrating application data (required due to changes in data structures) during uptime, therefore duration of the downtime can be reduced.
This infrastructure is already being used by our nZDM (near-Zero Downtime Maintenance) approach and is also one of the main features used by ZDO (Zero Downtime Maintenance).
We highly recommend you getting familiar with this feature since it will become more and more relevant for future SAP S/4HANA maintenances. Here you will find a good starting point:
- SAP Help Portal
- SAP Note 2907976– Silent Data Migration (SDMI) – FAQ
- SAP Note 2916801– Silent Data Migration (SDMI) Configuration Options
- SAP Community blogs:
One important consideration is that SDMs must be executed and successfully completed before the next upgrade is started. The SUM tool will also perform this check and may request you to process unfinished SDMs, if any. You may review the SDMs with further details in transaction SDM_MON. It is also relevant to understand that the SDM runs are client-specific and should be run for ALL available clients. For test/demo systems, that might be the case where you have a client to store template user data (i.e. a client that had previously been created with an SAP_USER client copy profile and has no data other than the user data). For such clients, SJOBREPO may not see the job SAP_SDM_EXECUTOR_ONLINE_MIGR as relevant and will probably not schedule it. That said, it may be necessary to run the online report R_SDM_ONLINE_EXEC for the specific/relevant migration classes in order to “process” then (no data to actually process). Thus, the SDMs status for that specific client will be set as finished and SUM will be able to continue.
RIG SAP S/4HANA 2020 UPGRADE DOCUMENT:
Once again, this guide is an additional reference from our specific RIG internal system but should not replace the SAP S/4HANA 2020 upgrade guide. Please check that guide considering your own solution landscape (OS versions, hardware availability and so on).
PS: a special thanks to my RIG colleague Thiago Zanguetin for his availability and collaboration during this system upgrade execution and the upgrade document creation.
The SAP S/4HANA 2020 Upgrade RIG document is available for download here:
FUTURE DIRECTION FOR S/4HANA UPGRADES
Wouldn´t it be nice to reduce the technical downtime for S/4HANA upgrades/updates to a single application server restart? This is technically already possible with the Zero Downtime Option of SUM (ZDO). Zero Downtime Option of SUM for SAP S/4HANA is currently available for service-based pilot projects only, so it is mandatory that SAP is involved in the project.
UPDATE: On November, 2021 it was announced the General Availability of ZDO approach for source systems SAP S/4HANA 2020 or higher.
Please check SAP Note 2707731 “Prerequisites and restrictions of Zero Downtime Option of SUM for SAP S/4HANA” for more information on the ZDO requirements, supported system versions and restrictions.
For understanding the initial concepts behind the ZDO approach and getting further information we recommend checking the blog Leveraging Zero Downtime Option of SUM for SAP S/4HANA release upgrades and updates written by Jens Fieger.
The technical task for an upgrade from SAP S/4HANA 1909 release to SAP S/4HANA 2020 was a straightforward process. Even for the very first version of SAP S/4HANA 2020 (FPS00) the few issues encountered were already known and documented in SAP Notes and have been easily overcome.
- For some best practices about upgrading an SAP S/4HANA Any premise solution please check the following blog written by Jocelyn Dart and the related document:
- For a complete overview about an SAP S/4HANA 2020 upgrade process including requirements, execution and post-activities please check the following blog written by Roland Kramer:
- For updated information about SAP Fiori deployment options and a server strategy update, please check the following blog written by Carola Steinmaier:
Brought to you by the SAP S/4HANA Regional Implementation Group