Upgrade (AS-ABAP)


This section describes SAP software upgrades for SAP NetWeaver Application Server (AS) ABAP. An upgrade updates an existing SAP system to a new release. The upgrade contains program code and data changes or introduces new areas of functionality. New SAP Releases are issued periodically and are delivered as independent units that you must apply sequentially.

SAP is continually improving the upgrade procedure to reduce downtime. For example, we reduced downtime by around 30 to 40% upgrading to 4.6C compared to upgrading to 4.6B. This was achieved by parallel execution of key processing steps. Depending on the upgrade strategy used, the new upgrade procedure for upgrades to SAP Web Application Server Release 6.10 and higher will reduce downtime considerably by moving certain execution steps from downtime to uptime.

SAP Downtime Assessment Service

To help you optimize downtime, we offer the SAP Downtime Assessment service, in which SAP experts analyze your upgrade project from the perspectives of runtime and downtime.

To help with the technical upgrade strategy for your production system upgrade, we offer you tailor-made optimization measures and recommendations. For more information on the SAP Downtime Assessment service, see SAP Service Marketplace at:


If you are upgrading to SAP R/3 4.6C or SAP R/3 Enterprise 4.70, or SAP ECC 5.0 SR1, we might recommend you to use Customer-Based Upgrade in order to meet your individual requirements for system availability. The SAP experts discuss this recommendation and its consequences with you and, if agreed, initiate all necessary follow-up steps.


SAP administrators must normally deal not only with new releases of SAP software but also with upgrades to the operating system (OS) and database management system (DBMS). However, OS and DBMS upgrades are not discussed here.

An upgrade has to take into account the data in the customer system and other dependencies on external resources. A full upgrade consists of the following sections:

·        Operating system upgrade

·        Database upgrade

·        SAP system upgrade

The interaction of these areas makes upgrading an SAP system a complex task.

We recommend you to upgrade the SAP system separately from database, operating system or application software upgrades. You can use Downward-Compatible Kernel (AS-ABAP) to achieve this.


SAP aims to reduce the downtime during an upgrade, which depends on the:

·        Hardware you are using – this is the most important factor

·        Release from which you are upgrading and the release to which you are upgrading

·        Database type and size

·        Applications used

·        Upgrade strategy

·        Productive applications

·        Number of clients

·        Installed languages

·        Modifications

·        Number of support packages included

You can now perform preparations – using the PREPARE program – and post-installation activities while the SAP system is online, so reducing downtime.


All upgrades to SAP Web AS 6.10 and higher now use the System Switch method, which greatly reduces downtime compared to previous methods.

For more information on upgrade strategies, you must read the current SAP upgrade documentation before performing an upgrade. For more information see SAP Service Marketplace at:


The following summarizes the upgrade strategies:

·        Downtime-minimized

Shadow system and production system can run in parallel. Certain actions can be performed during uptime which reduces downtime considerably.

·        Resource-minimized

Operation of production and shadow system is only possible independently of each other. Production operation stops before the import of the substitution set into the shadow tables or, at the latest, before the shadow instance is started for first time.

Comparison of Upgrade Strategies for System Switch

On DB2 UDB for OS/390 and z/OS, database actions occurring during the upgrade are saved by database mechanisms. Therefore, logging is always on regardless of the upgrade strategy. This lets you recover the database to the current status during the entire upgrade.

Therefore, for DB2 UDB for OS/390 and z/OS, the upgrade strategy influences downtime but has no effect on database logging.

Starting with the upgrade to 4.6B, the application instance can run on OS/390, so that the overhead of network transmission is reduced. For more information, see the OS/390 upgrade documentation.

Processing Sequence with Upgrade Strategies for System Switch


We recommend the following measures to reduce downtime during an upgrade:

·        Start upgrade preparations early

·        Identify modifications early (PREPARE)

·        Plan modification adjustment

·        Use the Modification Assistant

·        Choose the right upgrade strategy

·        Use the Upgrade Assistant

·        Use enhanced PREPARE

·        Use incremental table conversion (ICNV)

These measures are explained in more detail below:

Rehearse the upgrade in an appropriate test system

Whichever upgrade you are performing, the best recommendation of all is to rehearse it using a test system, that is, either a copy of your production system or a separately created and maintained development system with a representative set of application data. The test system should preferably have the same release and extent of modifications as the production system. This also gives you the advantage outlined in the next recommendation.

Automatic incorporation of customizations from test system

Customers with test systems that can be used to stage upgrades prior to upgrading the production system have the benefit that all customizations performed on the test system can be automatically imported into the production system.

Plan the upgrade carefully

Whichever upgrade you are performing, take the time to plan it carefully. This can be a laborious process but it helps to anticipate problems and avoid unplanned downtime. A full rehearsal with a system copy of the production system generates a detailed upgrade script, containing each single step as well as a timeline. This helps you to monitor your production system upgrade process and check whether it is still within the schedule.

Use the PREPAREprogram before the upgrade

From Release 4.0, you can prepare for the upgrade using the PREPARE program while the SAP system is online, so reducing downtime. If necessary, you can use some of the PREPARE modules several times.

By using all PREPARE modules, including the optional ones, you can get precise information to help you with the modification adjustment using the transactions SPDD and SPAU. Also, PREPARE provides information to help you reduce the number of conversion errors due to lack of disk space during an upgrade.

Accept automatic modification adjustment for SAP objects in your live system

When you upgrade your live or quality assurance system, you can accept modification adjustments that have been made in your development system (assuming the development system is equivalent to your live or quality assurance system) and that are available as a modification adjustment transport request. This avoids the manual effort of performing this process with transactions SPDD and SPAU.

Use downtime-minimized strategy for shortest possible downtime

This strategy offers the best way to minimize downtime if you are upgrading to SAP Web Application Server Release 6.20 and higher.

Create a database backup after upgrade

Always create a complete backup immediately after a successful upgrade if transaction logging has been turned off during the upgrade.

Otherwise – that is, if transaction logging has not been turned off – an online backup is acceptable after an upgrade.

Set import destination time

You have the option of setting an import destination time at the beginning of the upgrade if you are using the downtime-minimzed strategy. This enables you to optimize the extra system load due to the upgrade by “stretching” the import time for the new repository.

Increase number of parallel background processes for import

On multi-processor machines with sufficient main storage, you can reduce downtime by specifying up to four import processes to run in parallel.

Monitor the upgrade continuously

From Release 4.0, you can remotely (therefore, continuously) monitor the upgrade using the Upgrade Assistant. This allows you to avoid unnecessary downtime because you can react immediately if the upgrade program stops for any reason.

Consider using striped disks

Using striped disks can reduce the bottleneck problem caused by multiple importers competing for I/O resources. Note that this is a general approach to solving I/O bottleneck problems and is not specific to the SAP system.

For more information about striped disks in the context of redundant arrays of independent disks (RAID), see Disk Technology.

Consider using incremental table conversion

You can reduce downtime during the upgrade by performing table conversions incrementally, that is, during production operation and before you start the upgrade. For more information, see Incremental Table Conversion (AS-ABAP).

Choose host names correctly if you use switchover software

If you use switchover software, see SAP Note 96317, which describes problems with host names.

See also:

Upgrade with Oracle

Upgrade with Informix

Upgrade with MaxDB

Upgrade with DB2 UDB for UNIX and Windows

Upgrade with DB2 UDB for OS/390

Upgrade documentation issued by SAP