Our goal is to reduce the maintenance windows significantly. According to our roadmap, we are providing the first step of Downtime-optimized Upgrades and Hotfix Collection Imports with the upgrade to release 2502.

Although the contractual SLA remains unchanged for this first step, you will benefit from a reduced technical downtime of upgrades and patches in case of non-development systems (test and productive systems).

This blog post gives you more insights about the scope and the characteristics of the new approach.

How Does It Work?

The new downtime-optimized upgrade procedure splits the upgrade process into three phases:

PreparationTakeoverPost processing

During the preparation phase, the new release of the software stack gets installed into a shadow layer of the SAP BTP ABAP Environment system. This installation happens in the background, while the system is up and running. The new software release is not visible to the running applications yet, and business users can keep using the system as usual. However, certain lifecycle activities would interfere with the installation process and will be blocked while the background installation is running. This includes the import of new transports, the lifecycle of customer-managed software, and the lifecycle of tenants.

Once the background installation has finished, the system is ready for the takeover phase. In this phase, the system switches to the new software release. The takeover induces a system downtime in the area of currently 20 to 80 minutes. For upgrades, the required downtime depends mostly on the amount of the custom development. Running ABAP applications will be shut down, including active ABAP sessions. After the takeover, the system will come back online and all applications will be running on the new software release. Business users can start working on the system again.

The finalization of the upgrade and required clean up steps happen in the post processing phase. These steps will run in background, while the system is fully available for business users. Afterwards, all transport and lifecycle event restrictions are lifted.

For hotfix collection imports, the process is quite similar with the difference that the takeover duration is much shorter: About 10 minutes in 2502. A reduction to 2 minutes is expected in later releases.

Scope

The SAP BTP ABAP environment systems are automatically selected for the downtime-optimized release upgrade and hotfix import procedures based on certain system criteria. There is no manual nomination possible and also no service request required like a customer ticket. Two criteria need to be met that a system is chosen for the downtime-optimized release upgrade and hotfix import procedures:

The system is configured as a non-development system.The system has at least 4 HANA Compute Units (HCUs).

First Usage in Release 2502

Upgrade

The upgrade schedule (see figure Upgrade 2502) will remain the same as with the standard upgrade procedure that is still used for development systems: The upgrade starts up to 5 hours, latest 2 hours before the given maintenance window. With the new downtime-optimized procedure the majority of the upgrade work is done in background during system uptime before the maintenance window begins. This is an improvement compared to the standard procedure, where the majority of the upgrade work is done within the maintenance window. In this first rollout phase the system downtime is not guaranteed to match the start time of the announced maintenance window and might happen later. The reason is, that the lead time of 2 to 5 hours across all systems is not yet aligned with the runtimes needed to reach the announced maintenance window. The announced maintenance windows can be found here.

Figure: Upgrade 2502

Hotfix Collection Imports

The update schedule (see figure Update 2502) for the downtime-optimized update differs from the standard update procedure that is still used for development systems. The standard procedure update starts in background up to 120 minutes, latest 40 minutes before the given maintenance window. The downtime-optimized update procedure is started several hours earlier to account for the longer total runtime. Similar to the new upgrade procedure, the new downtime-optimized procedure does the majority of the update work during system uptime and before the maintenance window starts. This is an improvement compared to the standard procedure, where the majority of the update work is done within the maintenance window. The exact takeover time is not guaranteed to match the announced maintenance window start time and might begin later depending on the system individual runtime.

Figure: Update 2502

SAP BTP ABAP Environment (aka “Steampunk”) provides an “always up-to-date” environment. Currently, these updates do require planned technical downtimes. The downtimes are covered by contractual SLAs and the schedule is announced in advanced for the whole calendar year, for example, for 2025 in this blog post Maintenance Windows and Major Upgrade Windows. Our goal is to reduce the maintenance windows significantly. According to our roadmap, we are providing the first step of Downtime-optimized Upgrades and Hotfix Collection Imports with the upgrade to release 2502.Although the contractual SLA remains unchanged for this first step, you will benefit from a reduced technical downtime of upgrades and patches in case of non-development systems (test and productive systems).This blog post gives you more insights about the scope and the characteristics of the new approach. How Does It Work?The new downtime-optimized upgrade procedure splits the upgrade process into three phases:PreparationTakeoverPost processingDuring the preparation phase, the new release of the software stack gets installed into a shadow layer of the SAP BTP ABAP Environment system. This installation happens in the background, while the system is up and running. The new software release is not visible to the running applications yet, and business users can keep using the system as usual. However, certain lifecycle activities would interfere with the installation process and will be blocked while the background installation is running. This includes the import of new transports, the lifecycle of customer-managed software, and the lifecycle of tenants.Once the background installation has finished, the system is ready for the takeover phase. In this phase, the system switches to the new software release. The takeover induces a system downtime in the area of currently 20 to 80 minutes. For upgrades, the required downtime depends mostly on the amount of the custom development. Running ABAP applications will be shut down, including active ABAP sessions. After the takeover, the system will come back online and all applications will be running on the new software release. Business users can start working on the system again.The finalization of the upgrade and required clean up steps happen in the post processing phase. These steps will run in background, while the system is fully available for business users. Afterwards, all transport and lifecycle event restrictions are lifted.For hotfix collection imports, the process is quite similar with the difference that the takeover duration is much shorter: About 10 minutes in 2502. A reduction to 2 minutes is expected in later releases. ScopeThe SAP BTP ABAP environment systems are automatically selected for the downtime-optimized release upgrade and hotfix import procedures based on certain system criteria. There is no manual nomination possible and also no service request required like a customer ticket. Two criteria need to be met that a system is chosen for the downtime-optimized release upgrade and hotfix import procedures:The system is configured as a non-development system.The system has at least 4 HANA Compute Units (HCUs). First Usage in Release 2502UpgradeThe upgrade schedule (see figure Upgrade 2502) will remain the same as with the standard upgrade procedure that is still used for development systems: The upgrade starts up to 5 hours, latest 2 hours before the given maintenance window. With the new downtime-optimized procedure the majority of the upgrade work is done in background during system uptime before the maintenance window begins. This is an improvement compared to the standard procedure, where the majority of the upgrade work is done within the maintenance window. In this first rollout phase the system downtime is not guaranteed to match the start time of the announced maintenance window and might happen later. The reason is, that the lead time of 2 to 5 hours across all systems is not yet aligned with the runtimes needed to reach the announced maintenance window. The announced maintenance windows can be found here.Figure: Upgrade 2502 Hotfix Collection ImportsThe update schedule (see figure Update 2502) for the downtime-optimized update differs from the standard update procedure that is still used for development systems. The standard procedure update starts in background up to 120 minutes, latest 40 minutes before the given maintenance window. The downtime-optimized update procedure is started several hours earlier to account for the longer total runtime. Similar to the new upgrade procedure, the new downtime-optimized procedure does the majority of the update work during system uptime and before the maintenance window starts. This is an improvement compared to the standard procedure, where the majority of the update work is done within the maintenance window. The exact takeover time is not guaranteed to match the announced maintenance window start time and might begin later depending on the system individual runtime. Figure: Update 2502 Read More Technology Blogs by SAP articles

#SAP

#SAPTechnologyblog