This section provides an overview and key facts on the Zero Downtime Option (ZDO) of Software Update Manager (SUM).
Zero Downtime Option at a Glance
Planned downtimes for system maintenance events like release upgrades and feature or support package stack updates can be expensive. The ideal solution would be to run an upgrade or update without having a technical downtime. This can be achieved by using the Zero Downtime Option of SUM.
- Zero Downtime Option is an option of Software Update Manager to reduce the technical downtime.
- With ZDO, all phases are executed during uptime processing.
- SUM phases that are typically causing long technical downtimes:i. Table conversion and DDL execution - phase:
PARCONV_UPG
ii. Main import - phase:TABIM_UPG
iii. XPRAs, XCLAs, and AIM execution - phase:XPRAS_AIMMRG
- In addition, the business downtime can be significantly reduced by using ZDO.
- The approach requires higher effort in terms of functional validation as well as project planning.
- Like for standard updates and upgrades of SAP S/4HANA, SUM 2.0 is used.

The ultimate goal of ZDO is to provide a solution to apply release upgrades, feature or support package stack updates for SAP S/4HANA without technical downtime. The basic steps of the ZDO procedure are as follows:
- Business users work on the original system on release 1 that represents the source release.
- Meanwhile, the uptime processing of SUM has been started.
- At the end of uptime processing, SUM will rollover the business users to the so-called bridge subsystem.
- The bridge subsystem still represents the source release as the target release is yet to be finalized by SUM.
- Transitioning the users to the bridge subsystem happens in a controlled manner by the administrator.
- The business users can continue with their work since the transition to bridge happens seamless.
- While the business continuous to work, the target release is finalized in parallel by SUM.
- During the maintenance procedure, transactional consistency is ensured.
- Both releases, source and target, are stored in the same database but the access happens using different database schemas.
- Separating the releases into different database schemas ensures the encapsulation and isolation of both releases.
- At the end of the maintenance event, the target release needs to be activated.
- The cut-over and activation of the target release includes the following steps:i. Ramp-down release 1 which typically includes tasks like log off users, lock users, de-schedule batch jobs, cleanup queues, and clean erroneous update processes.ii. Parallelized restart of all application servers by SUM. The database is not restarted.iii. Ramp-up of release 2 that typically includes tasks like import of transports, functional validation, unlock users, re-scheduled batch jobs.
- After the restart and ramp-up of the system, users will work on release 2 that represents the target release.
Key Facts About Zero Downtime Option
Naming Conventions and Glossary
This section describes terms and phrases used in this training.