There are too many factors in play to be able to make general statements about how long a release update to SAP R/3 Enterprise takes. Database size is not a decisive factor for time planning. The number of clients, what languages are installed, customer’s in-house developments, support packages bundled with the upgrade, and not least the performance level of the hardware involved are much more crucial factors. As an illustration of this, upgrading one installation with a relatively small database of 22 GB, but having seven clients and 8 languages installed, led to 19 hours of downtime once all the available support packages and add-ons were integrated. The graph opposite, based on data from a number of completed release update projects, shows how little relation there is between database size and actual downtime.
Minimize downtime or hardware resources
The perception that live systems have to be taken down during an upgrade is only partly correct. The “System Switch Upgrade” procedure and “Downtime Minimized” upgrade strategy, introduced with SAP R/3 Enterprise, provide access to what’s known as a shadow instance which contains the target system’s complete SAP R/3 environment prior to the system being taken down. This can be used to create repository objects and make customer-specific modifications. This procedure shortens system downtime considerably, but does require substantial storage space in the database.
No upgrade is possible without a detailed project plan incorporating strategies for dealing with emergency scenarios such as a rollback to the original release if an upgrade is not possible. As long as there is a project plan, the release update is technically feasible. It is also essential that the latest information on the release update from the SAP Service Marketplace, where appropriate information for every platform can be found, is considered at an early stage. Before the project starts, certain areas of the existing system must be brought up to date. This includes applying the latest SPAM/SAINT update to the source system. Depending on which release you are upgrading from, certain support package / LCP levels have to be attained. Plug-in versions (PI, PI-A, ST-PI and so on) must be checked. Upgrading a system with a plug-in is only possible if the source release’s plug-in version corresponds to that of the target release. For example, SAP R/3 release 4.5B first has to be upgraded to a higher plug-in version for which there is an equivalent in SAP/R3 Enterprise, with version 2003_1_45B corresponding to version 2003_1_470.
Cleaning up the source system in preparation for the release update is a major task, and it is critical that the schedule takes this into account. Tasks include removing superfluous clients, archiving old data and releasing all transports. Another vital task, which experience has shown to involve the lion’s share of the work, is that of checking through all the Notes implemented in the database. A cleanup is necessary since in practice test and development systems in particular often contain incidental, only partially implemented Notes and transports that have been generated but not explicitly released.
To perform a successful upgrade, there must be sufficient free space in the file system and in the database. Depending on the database this should be between 25 and 30 GB. Remember to reserve a hard disk sector for copies of the complete CDs. Prepare also requires approximately 300 MB in the database. Prepare is a program that is installed on the system from the SAP-Kernel-CD the first time it is started. Support packages and add-ons to be included in the upgrade must also be considered.
It is vital that system changes carried out in the preparation phase are carefully documented. This is necessary because the same changes must also be made on downstream systems, the quality assurance and live systems, before the release update. The preparation should also include a thorough investigation of whether the hardware used can be optimized. The main areas of focus here are CPU, storage and backup medium. The type of backup medium is often overlooked, even though the upgrade procedure involves two complete backups of the database, once before it is isolated and once before it is returned into production. Often the frontend is also disregarded. SAP R/3 Enterprise requires SAP GUI version 6.20 or later, but this is in turn backwards compatible all the way to SAP R/3 3.1. Therefore one of the first steps must be a rollout of the newest SAP GUI, long before upgrading to SAP R/3 Enterprise.
Prepare is a major area of focus in the preparation stage. This upgrade tool runs through various modules, which in turn include various phases described in detail in the upgrade documentation. Most require no user interaction. In the parameter input module you can, among other things, configure how many parallel processes, that is batch and activation processes, should be used for Prepare. Since Prepare is usually run during production uptime, up to three parallel import processes is a sensible choice on powerful systems, or on today’s multiprocessors a maximum of four.
Add-ons and support packages that have been prepared in the central transport directory can be loaded in the UPLOAD_REQUEST phase. They are then available as selections for installation in the BIND_PATCH phase. It is strongly recommended that all available support packages are applied in conjunction with the upgrade. If no support packages are included, the minimum level of support packages required is displayed in the BIND_PATCH phase. This phase also includes information on the latest SPAM / SAINT update if this has already been made available in the transport directory. When Prepare has run, the checks.log file in the upgrade directory must be viewed. This file contains messages that are important for the rest of the release update procedure. In order to leave enough time for the measures that need to be implemented, you should if possible plan to run Prepare two to three weeks before the upgrade.
Performing the upgrade
Once the preparation steps including Prepare are completed, the upgrade can begin. As was mentioned above, beginning the upgrade doesn’t have to mean taking down live systems. If the “Downtime Minimized” upgrade is selected, it is possible to continue live operation until the MODPROF_TRANS phase of the upgrade. The “Downtime Minimized” upgrade reduces system downtime, but considerably lengthens the overall duration of the upgrade. In “Downtime Minimized” upgrades it is vital that the database’s archiving mode (log-mode) is not turned off until the point when the instance is isolated (this does not apply for OS400). This occurs before the MODPROF_TRANS phase. At the beginning of the upgrade, the upgrade program requires you to choose when database archiving should be terminated. In “Resource Minimized” upgrades archiving can be discontinued before the EU_IMPORT1 phase.
If no errors occur, the upgrade for the most part runs without user interaction after the INITPUT phase. However, user intervention is often required after some time has elapsed, for example for modification adjustment, or when backups need to be taken. The upgrade tool includes a function to send messages after long periods of inactivity so that personnel do not constantly have to check that the upgrade is still running. For monitoring and analysis of the procedure, every action is logged to the ‘r3up.log’ file in the usrsapputlog directory. If an error occurs in one of the phases, the upgrade program notifies you of it. Detailed error messages are written to a file with the naming syntax <phasename>.elg in the log directory.
On the upgrade program’s successful completion, the post-upgrade tasks can begin. Individual steps relating to SAP R/3 Enterprise are explained in the upgrade documentation. In addition all interfaces to external programs must be tested. Once these tasks are completed, the key users should test all of the system’s business management procedures. Only when this has been satisfactorily completed can the release update to SAP R/3 Enterprise be concluded and the release update performed on remaining systems.