SAP System Upgrade and SAP S/4HANA Conversion

The central tool used is the Software Update Manager (SUM). The SUM can be used - besides others - for one of the following:

• Import customer transport requests
• Import SAP Support Packages
• Install and upgrade add-ons
• Perform an SAP system upgrade
• Migrate the database via DMO (Database Migration Option) to:
  • SAP HANA DB
  • SAP ASE
  • MS SQL Server
  • IBM DB2
  • SAP MaxDB
• Perform an SAP S/4HANA Conversion:
  • Without DMO
  • Including DMO

The first thing that happens is that the need for an upgrade is recognized. This recognition of the need to upgrade could be at a number of different levels of upgrade recognition triggers; some are very operational in nature, while others are much more strategic. On the operational side, you may realize that you have a serious technical SAP system limitation within your current environment.

At some time, an SAP release reaches its end of maintenance. This means that SAP no longer delivers SAP Support Packages that adapt your processes for legal requirements and correct errors. See Quick Link /pam (Product Availability Matrix) in the SAP Support Portal.

The new release can contain many new functions that your company requires. New features can be added on the basis side (new administration tools) or on the application side (new and enhanced business functionality).

The following factors are also important when deciding whether to upgrade:

• Costs: what will the upgrade cost me in total?
• Payback/ROI: will the upgrade have financial advantages for me?
• Benefits: what advantages will the upgrade have?
• Risks: are there risks involved in the upgrade?

Change and improvements are integral parts of today’s business environment. SAP supports and embraces the process of continuous change as:

• New SAP functions becomes available.
• Market technology changes.
• New business requirements are defined.

Review each component of new release functions. Determine how these enhancements can add value to your company’s operations.

When planning an SAP system upgrade or an SAP S/4HANA Conversion, consider the following topics:

• Release customizing
• Modification adjustment and migration of modifications into SAP standard
• Adaptation and testing of customer development and enhancements
• Adaptation and testing of interfaces
• End-user training
• Validation and testing of the new release

The biggest part of the upgrade project represents the adaptation of the current business processes to the new features of the new SAP system. There are not only changes to the Customizing and the repository. There are also changes for the end users how to work with the new applications. When the development system has been upgraded to the new release, it can still be necessary to develop bug fixes for the productive system which is still working with the start release.

Some additional technical upgrade process related issues are:

• Hardware requirement on new release: server, front-end, network
• Sizing forecast and SAP system configuration for new release
• Planning of OS, DB, and SAP system upgrade
• Testing and validating a backup strategy for the upgrade and on the new release
• Performing technical update/upgrade on the whole SAP system landscape (transport landscape)
• Post-upgrade activities including performance monitoring

Since the requirements of the new release are changing, this requires changes to the configuration which in turn may need a sizing forecast to run. Finally, the whole environment is concerned, for example, the server hardware, the client hardware, the network, the operating system, and the database. Especially when upgrading the operating system, other software on this computer has to be tested. For example, the backup software has to be tested.

Because of the new requirements, performance monitoring is more important after the upgrade.

When deciding which SAP release you want to upgrade to, consider:

• The SAP release strategy
• IT costs for upgrade and maintenance
• Costs for adapting business processes
• Business requirements versus SAP functions
• Costs versus Payback/ROI

An SAP system upgrade is more than just a technical upgrade. The upgrade of an SAP system landscape should be executed as a project. As it is a procedure for exchanging the older repository of an SAP system with a newer repository; this includes changing table structures at SAP system and database level, converting application data, exchanging the kernel executables. A significant amount of planning and lots of steps are required in order to perform a release change for the SAP system landscape. Customer upgrade projects last several months. Update projects last about half as long. Don't forget to consider:

• Budgeting and resource planning
• Upgrade project in relation to other implementation/roll out activities
• Availability of resources
• End of maintenance of the current release

A technical upgrade of one SAP system involves the following steps (see the following figure):

1. When planning the upgrade, you should make decisions about the upgrade strategy. An exact upgrade schedule should be drawn up.
   Caution

   It is important to read the SAP Notes about the upgrade. If you don't, your SAP system upgrade likely will fail.

2. Certain requirements (software, hardware, operating system, database) must be met before you can upgrade the SAP system. Careful preparation of the upgrade is the best guarantee that it will run without errors.
3. After you have performed the preparations, you can start.
4. The prepare part of the upgrade automatically checks if your SAP system is properly configured for performing the upgrade. However, you must perform many tests and actions manually before starting the upgrade.
5. Perform the upgrade.
6. Follow-up activities include all actions necessary for completing the upgrade. SAP recommends completing the actions in the order given in the upgrade guides.

Several tools help to perform the upgrade or conversion. They are part of the technical upgrade process.

• The prepare part of SUM has to run before the SAP system upgrade. You have to repeat it until it is error-free. The error messages are written to the log file CHECKS.LOG.

  Checks are performed on the source release. For example, it checks whether the source release of the SAP system, the database, and the operating system is sufficient for this upgrade, whether there is enough space in the database available, and whether modified SAP objects are still in unreleased transport requests.

  SAP Support Packages and add-ons are collected for binding them to the upgrade or conversion process. This is very important. If, for example, you don't bind enough SAP Support Packages to the upgrade or conversion, this will result in a loss of data during the procedure. If you don't maintain your add-ons, the whole SAP system can become unstable and inconsistent.

  Note

  This is done with the help of the Maintenance Planner and by adding extra Support Packages.

  Tools are imported in the source SAP system that are needed for the procedure.

• With the SUM UI, the procedure runs independently from a dedicated front end server, so you can control and monitor the progress of the procedure from a number of different places (see the figure above).

  This provides optimal support for a remote procedure. The SUM provides an alert mechanism that lets you start an external program (for example: sending an SMS to your mobile) if it breaks down.

• With the new release, ABAP programs of the new software components are exchanged. They are delivered in their source code, but not with their load. This is not possible, because the load depends on the local environment (kernel, operating system, and hardware). When you call a program the first time, its load will automatically be generated if it does not already exist. This may, however, reduce production system performance for some time after the update/upgrade. To avoid this, you can use transaction SGEN to generate the loads at the end of the technical downtime, during the downtime – or let SUM do the generation before the begin of the downtime, during productive operation.

The latest SUM archive can be downloaded from SAP Support Portal, Quick Link /sltoolset (https://support.sap.com/sltoolset) in the System Maintenance area.

Perform the following steps to start SUM (actually, start SAPup):

1. Copy the SUM archive to the host, the PAS of the SAP system runs on, for example, to directory usr/sap/<SID>, or any other directory. This directory should have about 50 to 200 GB of free space.
2. Unpack the SUM archive. This results in around 15.000 files and several directories.
3. Update the SAP Host Agent, if necessary. It is used to connect the SUM UI to SAPup. SAP Host Agent should be up to date.
4. Configure the SAP Host Agent from within the SUM/abap directory: execute the command SUMSTART confighostagent <SID>. On a Windows operating system, you have to perform this step as user <sid>adm, on a Linux/Unix operating system as user root.
5. Connect a UI5 enabled Web browser via https://<hostname>:1129/lmsl/sumabap/<SID>/slui. This connects the SUM UI (the Web browser) to the SUM tool SAPup.
6. Log on to SUM with user <sid>adm.

When using SUM. just as SPAM or SAINT, these steps are performed first on the development system, then on the quality assurance system, then on the productive system.

The figure above shows the main phases of the SUM procedure.

• Manual preparation activities have to be performed.
• RUN_RSDBSCPY clones tables from the original to the shadow repository (update only).
• EU_IMPORT_ALL creates the shadow repository from so called upgrade DVDs (upgrade and conversion only).
• EU_CLONE_MIG_SOT_* creates the shadow data for the shadow system (DMO only).
• DIFF... copies customer-specific objects from the original to the shadow repository (upgrade and conversion only).
• DDIC_UPG imports dictionary objects from the download directory to the shadow repository.
• SPDD modification adjustment takes place (in development system, only)
• ACT_UPG activates all ABAP dictionary objects that are not delivered activated.
• PARDIST_ORIG starts the distribution.
• TABIM_SHADOW_... imports non-dictionary objects from the download directory to the shadow repository, also copies upgrade and language data from the download directory, only if it is inserted into new tables.
• RUN_SGEN_GENER8 runs SGEN, if selected.
• EU_CLONE_MIG_* preparations for downtime migration (DMO only).
• DOWNCONF_DTTRANS begin of downtime, ramp down is performed.
• EU_CLONE_MIG_DT_RUN performs the downtime migration (DMO only).
• KX_SWITCH switches to new kernel.
• EU_SWITCH switches to new repository.
• PARCONV_UPG converts application tables.
• PARMVNT_APPL_VIEWS moves the nametab of application tables.
• TABIM_UPG imports upgrade and language data from the download directory.
• XPRAS_AIMMRG executes XPRAs and After Import Methods (AIMs) (both are ABAP programs executed to adopt data to the new release).
• SPAU modification adjustment takes place (in development system, only)
• In case of an upgrade of an SAP S/4HANA server system or an SAP S/4HANA conversion: silent data migration was initialized by SUM and is started now.
• In case of an SAP S/4HANA conversion: the FIN data conversion has to be performed.
• Manual follow-on activities have to be performed.

The start of the update process involves the transfer of new data to the SAP system. SAP repository objects are imported into the SAP system. All repository objects that have been modified by customers must be compared to the new SAP standard during the update process.

In order to avoid loss of data and table fields that customers may have created, conflicting table structures must be merged before the activation of dictionary objects in the update process.

If objects need to be adjusted, use the transactions SPDD and SPAU. All modifications made by customers are then merged with the new SAP object versions to retain data; otherwise, the new SAP version will be activated and data may be lost.

When choosing the Standard mode, the SAP system is available during the activation phase. The activation takes place via the shadow instance via the shadow system in the shadow repository.

When the update is completed, the SAP system is successfully running at the new release level. Customer-developed objects and modifications have been preserved.

The ABAP Dictionary objects (tables, data elements, domains, and so on) are adjusted during productive operation, before the activation of the ABAP Dictionary. The adjusted objects are collected in a transport request. You don't release this transport request; instead it must be flagged for export in transaction SPDD. Towards the end of the upgrade, SUM exports this transport request into the transport directory, and then registers it for transport in the file <transport directory>/bin/umodauto.lst.

Non-dictionary repository objects (reports, screens, and so on) are adjusted towards the end of the upgrade during downtime. At this stage, the import of SAP objects has already been completed. However, the old, modified version is still available in the version database. As with ABAP Dictionary objects, all adjustments are released to a transport request that is flagged and then exported and registered by SUM.

For further information, see the upgrade manual and online application help for SPDD/SPAU.

You can activate new business functions by using the Switch Framework. Without activation of the business functions, the system would behave as in the source release of the upgrade. Only required business functions should be activated. This significantly reduces the effort of testing, adjusting customizing, adjusting own development, training end users, and others.

Because most business functions can't be de-activated once they are activated, the activation and first testing should be done in a sandbox system (if the wrong business function is activated, the sandbox system can be reset). The required business functions can then be activated in the development system using transaction SFW5. Now, in transaction SFW5, a transport request should be created which contains the activated switches. This transport request is then transported to the quality assurance system. Here, testing takes place. After adjusting customizing and adjusting development via the development system, the transport request containing the switch settings can be imported together with the adjustment transport requests into the production system.

The transactions used for handling the Switch Framework are:

• SFW5 – activate/deactivate business functions
• SFW_BROWSER – investigate, which enhancements are related to the business function in question
• SFW1 – create switches (only customer enhancements)
• SFW2 – create business functions (only customer enhancements)
• SFW3 – create business function sets for industry solutions (only customer enhancements)

The Switch Framework enables optional activation of business functions. With the Switch Framework, you can control the activation of repository objects. Activating a business function triggers switches, which then control the execution of the code enhancements. These switches ensure that you only work with the new functions if you have activated them. All functional changes and the impact of an activated business function are made transparent in advance by the documentation. Note that, once a business function is activated you usually can't reverse it. The activation process starts a batch job in your SAP system that automatically performs all changes in the SAP system.