SAP S/4HANA Conversion: What Is the Software Update Manager?

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:

• Release upgrades
• Installing enhancement packages and add-ons
• Applying support packages
• Upgrading single components
• Performing the system conversion to SAP S/4HANA

In addition, it offers the following options and features:

• The Database Migration Option (DMO) or system update combined with a database migration to SAP HANA, SAP ASE, Microsoft SQL Server, SAP MaxDB, or IBM DB2 for Linux, Unix, and Windows.
• The Zero Downtime Option (ZDO) and near-Zero Downtime Maintenance (nZDM). These options allow you to upgrade your system with a minimum technical downtime and a minimized business downtime.
• The benchmarking tool and the table comparison. Both tools are to be used in combination with DMO. The benchmarking tool helps you to estimate the duration of the migration. The table comparison can be used to compare the number of rows between the source and target system.
• The prerequisite check tool can be used to verify the source system before you start the conversion. The tool verifies if the source operating system and database version meet the requirements for the conversion to SAP S/4HANA.

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.

System Switch Upgrade

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:

Increased Resource and Space Requirements

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.

Shadow Instance Installation

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.

Operating 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.

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:

Single System

The single system preconfiguration mode has the following features and characteristics:

• Longer downtime. Operation of the production and shadow system are only possible independently of each other. Therefore, no additional resources are needed.
• No shadow instance runs in uptime. Production operation stops before the import of the substitution set into the shadow tables, or at least before the shadow instance is started for the first time.
• The single system option is only available for the standard update or upgrade scenario. It cannot be used in combination with DMO.

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.

Standard

The standard mode is applicable to most scenarios, as follows:

• Standard downtime optimization. The shadow system and imports run while the SAP system is still being used productively.
• Higher demand on system resources. The shadow system runs next to the production system. If needed, the shadow instance can be installed on a separate server.
• The modification adjustment of the ABAP Dictionary objects is performed before downtime. This is possible because complete version management is available in the shadow system.
• Activation and distribution of all ABAP Dictionary objects that are included in the SAP upgrade, support and Enhancement Packages, and objects that are modified or created by your company. Where many included support packages or add-ons are involved or where systems have been modified greatly, this procedure may take several hours. Fortunately, the duration of the activation is not an issue in standard mode because it runs in the shadow system while the system is still being used in production.
• The shadow system is used to calculate the target release state of a table before downtime starts. Because the shadow tables are created in their final structure during production operation, the number of tables into which data can be imported in advance can be increased.

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.

Downtime-optimized

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.

Database Migration Option

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:

• Reduced project effort: both projects can be combined into one.
• Reduced business impact: there is only one downtime.
• Easy fall back scenario: the source database remains consistent during the procedure and can be reactivated when needed.

DMO is fully integrated into SUM. Its sequence is integrated in the system switch upgrade functionality of SUM (see figure below), as follows:

1. As of SAP S/4HANA 1909, the shadow repository is created on the target database. Creating the repository on the target database reduces the downtime as it does not need to be migrated in the downtime phases. For system conversions to lower SAP S/4HANA releases, the shadow repository is created on the source database and remains there until the downtime phases. At the same time, the target SAP HANA database is being configured.
2. For versions below 1909, after modification adjustment, the shadow repository is copied to the target SAP HANA database. When done, you reach the downtime phases.
3. At the start of the downtime phases, the SAP system switches to the SAP HANA database. The source database is no longer modified.
4. Next is the migration, and conversion of the application data is performed.
5. The update is finalized, and the SAP system runs on the target database.
6. The conversion is completed, and the system is available for the end users.

You need to take the following points into account when using DMO:

• Know the operating system and database prerequisites. The source and target operating system and database need to be supported. All database versions listed in the PAM for the source release and all operating system versions listed in the PAM for the target release are supported.
• In the maintenance planner, do not forget to select the required SAP kernel files. Select the kernel files of the target software release for both the source database and the target database. Don’t forget to include the SAP HANA client.
• The DMO feature includes easy reset functionality. The source database is no longer changed in the downtime phases of the conversion, making it easy to switch back to the original system if the conversion fails.

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.

Performing the DMO with System Move

DMO in SUM offers the possibility to redesign the SAP system landscape during the conversion to SAP S/4HANA.

The following features are available:

Move the ABAP Central Service (ASCS) During the Conversion

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.

Move the Primary Application Server (PAS) Instance During 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:

• The target SAP HANA database needs to be installed and configured. This is always the case, even without performing DMO with system move.
• The target ASCS instance and PAS need to be preinstalled and correctly configured. The installation has to be done using the installation media of SAP S/4HANA.

DMO with system move works as follows (see below):

1. You start SUM on the original PAS as you would for a normal system conversion and database migration. The export files containing the contents of the source database are created in a compressed form in the SUM directory. Because the entire database is exported, you should make sure that there is enough space available.
2. SUM will display a dialog in which you can enable the system move option.
3. Later, SUM will ask how the SUM directory content should be moved from the source to the target PAS. The data transfer can be done either in serial or in parallel mode, as follows:
   1. In the serial data transfer mode, SUM will export the files to a local file system on the source system. When done, you are prompted to transfer the SUM directory including the export files to the target host. After the transfer, you can continue the DMO procedure on the target host.
   2. – In the parallel date transfer mode, you are prompted to transfer the SUM directory to the target host. When done, you start SUM on the target host in parallel with SUM on the source system. SUM on the source system will create the export files that you copy to the target host. SUM on the target system will start to import the copied files as soon as the copy is completed. This means that the two SUM instances work in parallel. You have to continue to synchronize the directories that are listed in the DMO dialog between the systems manually until the last files are copied over and are ready to be imported.
4. The remaining part of SUM with DMO is executed on the target PAS.
5. When the procedure completes, the SAP instance is available on the target system.

Conclusion

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.