The conversion to SAP S/4HANA is carried out by the Software Update Manager (SUM). SUM is a tool that performs software maintenance for your SAP systems.
The tool is used for the following activities:
In addition, it offers the following options and features:
SAP recommends that you download the latest support package for SUM as it contains the latest corrections and is updated regularly. The tool is delivered independent from SAP application product shipments via the Software Logistics Toolset (SL Toolset). Visit the SAP Support Portal at http://support.sap.com/sltoolset to find the latest version of the tool, the documentation, and corresponding SAP Notes.
Always Use SUM Version 2.0: All system conversions and transitions from SAP ERP to SAP S/4HANA have to be handled via SUM version 2.0.
SUM contains the following technologies to reduce the downtime to convert to SAP S/4HANA: system switch upgrade, DMO, and system move. We will discuss each of these options in the following sections.
As of SAP Web Application Server 6.10, SAP introduced the system switch upgrade. With this method, the majority of upgrade work, including custom development, modifications, activation, and distribution, is done in a protected area of the database during uptime. During the upgrade, a second “shadow” instance is installed in the same database as the source system to be upgraded (see figure below).
The shadow instance uses the same kernel as the target release but only offers functions needed by the upgrade mechanism. No access to application data is possible. The shadow instance is used to adjust the delivered target release according to the company’s requirements and to integrate support packages, add-ons, and modifications into the target release while the system is still being used productively. In the production database, the new repository is created in shadow tables under an alternative name. The shadow system enables you to access these tables.
If you choose the standard upgrade strategy, you can perform upgrade actions that have to be performed during downtime before downtime starts. Several phases may run during uptime, such as activation and distribution. As a consequence of the modification adjustment, activation, and distribution during uptime, the new table layout is already known in an early stage of the upgrade. This increases the number of tables in which data can be loaded in the shadow import.
All Data Dictionary (DDIC) objects are adjusted and activated in the shadow instance. Then a distribution program calculates how to achieve the transition from an object in the source to the target release. This phase can take up to several hours. Because both DDIC modification and activation run during uptime, downtime is no longer dependent on the number of support packages or add-ons included in the upgrade. During the downtime phases, the switch is made to the new system and any remaining data is imported. Any parts of the source release system that are no longer needed are deleted.
The system switch upgrade has the following consequences on the methodology of the technical upgrade:
Operating the shadow instance in parallel with the production instance increases demands on system resources. The shadow instance can be installed on a separate server if the available system resources for the productive instance are too limited.
The installation module in SUM is used to install the shadow instance. The module first creates profiles, directories, and an extra database user, then copies programs and files needed by the shadow instance. All tables needed for the shadow system are imported into the database. Additional table contents are copied into the shadow system to enable adjustment, activation, and distribution functions in the shadow system.
The shadow system is used to perform the modification adjustment of the ABAP Dictionary objects and to activate and distribute the requests included in the upgrade. After the modification adjustment, there is a consistent inactive repository with the descriptions of the table structures of the target release, including support packages and add-ons.
The total runtime of the upgrade increases with the number of support packages integrated into it, especially the import phase into the shadow tables and the activation phase, which expand enormously. Fortunately, these run in the shadow instance while the system is still being used productively.
SUM can be configured to adapt its behavior and to reduce downtime. To make it easier, SAP has grouped parameter settings into the following preconfiguration modes:
The single system preconfiguration mode has the following features and characteristics:
Note: As of SUM 2.0 SP 07, the single system mode can only be used for support packages or Support Package Stack upgrades. It can no longer be used for release upgrades and system conversions.
The standard mode is applicable to most scenarios, as follows:
Because these processes occur during production operation, downtime is reduced considerably, and some phases of downtime are much shorter. Downtime is independent of the number of languages, support and Enhancement Packages, and add-ons included in the upgrade.
This advanced strategy is an extension to the standard strategy discussed earlier. Downtime can be further optimized by increasing the number of parallel processes. You can use this mode to get maximum optimizations and downtime reduction. The advanced mode is much more complex than the single system or standard option and requires detailed knowledge of the capabilities of SUM. Based on the source database, this option can be combined with the downtime-optimized DMO or with nZDM.
SAP S/4HANA is only supported on SAP HANA. If you are still running on another database, your system can still be converted to SAP S/4HANA by using the DMO of the SUM tool. This one-step procedure combines the system conversion with a database migration.
The benefits of the one-step procedure are that the conversion and migration can be combined, which gives the following benefits:
DMO is fully integrated into SUM. Its sequence is integrated in the system switch upgrade functionality of SUM (see figure below), as follows:
You need to take the following points into account when using DMO:
SUM verifies the database of the source system in an early stage of the conversion. If it’s a non-SAP HANA database, SUM enables the DMO feature automatically because the migration to SAP HANA is mandatory.
DMO in SUM offers the possibility to redesign the SAP system landscape during the conversion to SAP S/4HANA.
The following features are available:
SUM offers the option to move ASCS during the conversion to SAP S/4HANA. This is necessary if your operating system release is no longer supported with SAP S/4HANA. This feature enables you to start the conversion on an unsupported operating system. If SUM detects that the ASCS instance is running on a remote server, it will ask you if you want to keep the current instance setup or if you want to move the ASCS instance during the conversion. If you select the latter, the ASCS instance is moved to another host during the downtime phases of the conversion.
Changes are high that if the ASCS is running on an unsupported operating system, so is the PAS. The performing DMO with system move option includes the option to move the PAS to another system during the downtime phases of the migration.
The target SAP systems need to be preinstalled for DMO with system move to work. The installation and configuration need to be completed before the start of the conversion, as follows:
DMO with system move works as follows (see below):
When it comes time to make the move to SAP S/4HANA, you have some options. This blog post laid out the ways the Software Update Manager can help you make your migration a success. Learn more about SAP S/4HANA conversion here.
Editor’s note: This post has been adapted from a section of the book SAP S/4HANA System Conversion Guide by Mark Mergaerts and Bert Vanstechelman.