SAP solutions are well known for their long lives. Experienced IT managers generally assume the solutions will have a useful life of well over ten years. Yet a release update after several years can be beneficial since SAP solutions are constantly being improved. Since this is not a routine event, it’s naturally wise to ask how much professional support is necessary.
Some companies perform SAP R/3 release updates themselves. However, they run the risk of causing capacity bottlenecks, overloading systems, making response times unbearably long and blocking work processes. Luckily the SAP release strategy offers professional solution management using experienced external advisors. It includes various forms of assistance – technical implementation, comprehensive project management, project coaching, efficient customization services and user training.
Checking performance and settings
The SAP release strategy begins two months before the planned system upgrade with the GoingLive Functional Upgrade Check service offered by SAP as standard. The GoingLive service comprises a stocktaking exercise both before and after the release update. The goal of the first phase is to prepare customers in advance for the update. As part of an analysis, the service checks and documents whether performance will remain the same using the existing hardware and user data when the release and possibly the requirements change. The focus here is on the system’s capacity utilization and response times. A plausibility check is performed on the hardware, the operating system, the databases and the workload, i.e. the system-related functions and workloads of the affected employees.
The results of the tests lead to recommendations for the basic settings of the database, operating system and SAP solution. The sequence of the measures to be performed is detailed step by step in an upgrade timetable which also defines the updates to the operating system or database.
Testing the new release and training users
The next phase concerns the technical upgrade. First the test system is set up taking account of the new release. This is tailored to the customer’s requirements, modifications and in-house developments. It is a delicate and iterative process requiring a series of test runs until the customer-specific modifications and the necessary interfaces are implemented to meet the customer’s wishes. Sufficient buffer time should be factored in the actual release upgrade so as to avoid possible downtimes. Once the system is set up and running securely, the first users are able to commence training and therefore become familiar with the solution as early as possible.
If the test system has met the specifications, this new configuration is transferred to the live system. The preparation stage is finished and the actual release upgrade can begin. There are basically two strategies to choose from here – namely to minimize the downtime or to minimize the system resources. The customers/users decide which they prefer. The shortest possible downtimes can be achieved by duplicating or mirroring the live system, which obviously means greater demand is placed on system resources. In this case, operation of the legacy system remains undisturbed while upgrading is performed in parallel. The new system goes live after a relatively short transfer time. Step-by-step upgrading of the live system with the new components on the other hand conserves resources but inevitably results in longer downtimes. The entire duration of a SAP R/3 upgrade is also dependent on factors like the hardware used, the “business language” installed, the number of clients, the scope of in-house developments and modifications to SAP standard tables, add-on software and the integration of support packages.
If a release update for a customer involves exchanging the hardware platform, e.g. from UNIX to Windows, it is not recommended to perform both operations at the same time. A step-by-step procedure is the safest way forward in this situation. The software release update should be carried out after changing the hardware platform to enable the origins of any problems to be localized more easily.
Implementing your own requirements
The release update is tested as part of further verification by the GoingLive service four weeks after the release update. Performance following the upgrade is measured and compared to performance levels before the update. The SAP R/3 basic settings are checked. The customer receives a report with recommendations on how to further optimize his SAP solution so as to achieve the best possible performance with the resources available.
It would be wrong to assume that each release inevitably involves an exorbitant increase in hardware resources. On the contrary, fewer additional resources are required from one release to the next. For SAP Release 4.0B (in comparison to Release 3.1I) 30 percent additional CPU and RAM was required on the application servers and 5 percent for the database server. However, the release update from SAP R/3 4.6c to SAP R/3 Enterprise generally only requires around 5 percent more for CPU, RAM (application servers) and database server.