Managing SAP ERP 6.0 Upgrade
Chapter 5: Executing an Upgrade Project
How do organizations managing an SAP ERP 6.0 upgrade project do so with the fewest disruptions possible? What can be done to ensure that SAP ERP upgrades run smoothly after completion? In this chapter, Martin Reidel, Senior Vice President of SAP's Global Upgrade Office, discusses the best system landscapes for upgrade projects, as well as why downtime is one of the biggest challenges during an SAP upgrade, and what can be done to minimize downtime during projects.
This section lists the factors that you should look at when considering an SAP ERP 6.0 upgrade in a typical three-system (development, QA/consolidation and production) landscape,
as well as lessons learned from failed upgrade projects.
Managing SAP ERP 6.0 Upgrade Projects, Ch. 5
Table of contents:
Managing system landscapes during SAP ERP 6.0 upgrades
How to minimize upgrade downtime during an SAP upgrade project
How should the system landscape be set up during an upgrade project? How can downtime be minimized, and what support tools and methods exist? What about training the project team and end users? Chapter 5 answers these questions and provides recommendations based on lessons learned from numerous upgrade projects.
Chapter 5: Executing an Upgrade Project
This chapter looks at the execution phase of an upgrade. Based on two main upgrade challenges perceived by customers, its focus is on downtime minimization and training. In addition, we will look at system landscape strategies that can help you successfully complete your upgrade project.
You can follow several different paths to tackle downtime. We will show you how careful analysis of your situation can help you manage this issue successfully. We will also describe the options offered by SAP to keep downtime to a minimum.
The section on a recommended system landscape outlines a recommendation for how to set up and manage your system landscape in an upgrade project. It is not feasible within the scope of this book to show all possible system landscapes, as each is customer-specific. However, it is instructive to examine and understand a basic setup that shows how the system landscape evolves throughout the project. From this, you can begin to analyze your own system landscape and take the necessary measures to build the appropriate environment specific to your requirements.
When planning to tackle an upgrade, it will most likely become apparent a knowledge gap exists for many of your staff, either on the technical side or in terms of the functionality that will be implemented. In the section on training, you will find numerous recommendations for determining the training your organization will need as well as suggestions for relevant SAP courses.
Finally, we will look at some of the lessons learned from upgrade projects. These will give you insight into what makes a successful project, based on real experience from SAP's involvement in numerous upgrade projects.
5.1 Managing the System Landscape During an Upgrade Project
The goal of this section is to provide guidance and recommendations for a standard three-system SAP customer landscape; however, it cannot fully explore all of the potential additional systems and interdependencies you might have in your specific landscape.
- The code freeze strategy.
- The technical availability of hardware for setting up temporary systems during the project (sandbox and training systems).
- The operational ease of setting up sandbox systems, shadow systems, and so on in your IT environment or with your hosting service provider.
Depending on the scope of the upgrade, your upgrade project can last several months. During this time, it is often inevitable that you will need to make at least some changes to the production system. For many customers, it is not possible to expect the business to suspend all changes to the system during that time. Therefore, you must define an appropriate change management strategy that will restrict and regulate changes to the production system within the context of the system landscape you are using for upgrade testing and project refinement.
The code freeze period will usually start after the development system has been established. From that point in time, double maintenance of coding and other system configuration changes is necessary. At a point close to the cutover weekend (usually after the final integration testing at the latest), you will also have to define a "hard" code freeze strategy which restricts transports even more and allows only the most urgent of changes to be implemented. Section 4.4, "Best Practices," in Chapter 4, provides a recommendation for a code freeze strategy.
You should also consider the need to set up separate systems for training purposes, interface testing, modification adjustments, and custom developments. Most customers, however, will use a three-tier system landscape with an additional sandbox as the "playground" for the upgrade project.
5.1.1 Recommended System Landscape
This section provides you with recommendations on how to set up your system to minimize upgrade risks and minimize the duration of the code-freeze period. The examples show a typical three system landscape, consisting of a development system, a quality assurance/consolidation system, and a production system. The recommendations show how additional copies of these systems are used to perform required activities during the upgrade project such as adjusting custom developments and testing. We will look at how the systems evolve during the different phases of the upgrade project:
- Project preparation
- Upgrade blueprint
- Upgrade realization
- Final preparation for cutover
- Production cutover (go-live) and support
The scenarios are based on a suggested timeline, which runs over four months. For each phase, each scenario gives a suggested duration, in weeks. The recommendations assume that you have the appropriate hardware available for creating additional systems. We describe actual project work, how each system is upgraded to the new release from the old release, and the transport routes required.
Recommended project activities are suggested for each team involved at each phase, as follows:
- Project management
The team in charge of the upgrade project that manages all activities that are part of the project.
The IT team that manages the system technology such as hardware, the operating system, and database software.
The software development team responsible for custom developments and modifications to the core SAP software.
- Business experts
Experts from the organization's business units who understand the business processes and how SAP functionality is used within each process.
Although the system landscape shown in Figure 5.1 assumes an upgrade from SAP R/3 4.6C to SAP ERP 6.0, the source release is not a relevant factor in these examples, except for very old SAP R/3-releases. The main objective is to show how the system evolves with systems running either the source or the target release, culminating in an upgraded production system.
5.1.2 Project Preparation
Project preparation is the first phase of the project, where initial work is done on an upgraded copy of the production system.
The project management team must first arrange for an upgrade project system to be available. The next step is to prepare the upgrade project system (the sandbox system) as a copy of the production system (see Figure 5.1). Ideally, you should include as much realistic production data as possible in the upgrade project system.
The following activities should be carried out in the project preparation phase:
- The project management team creates a detailed project plan, nominates the project team, and orders temporary hardware.
- The technical team prepares the sandbox system (SBX), also known as the upgrade project system.
- The development team reviews custom developments and modifications.
- The business experts study material on the new release (for example release notes and the contents of the Solution Browser tool for SAP ERP). They start preparing test scenarios and planning test execution.
You have now established an upgrade project system (the sandbox system). The first version of the project plan is available, along with comprehensive understanding of the scope of the project in terms of technical, process, and functional changes that will be included.
5.1.3 Upgrade Blueprint
In the upgrade blueprint phase, the focus is on experimenting with the sandbox system through familiarization and testing of the new software (see Figure 5.2).
Using this system, the technical, development, and business teams can begin the process of "discovering" the new software.
The following activities should be carried out in the upgrade blueprint phase:
- The technical team executes a technical upgrade on the upgrade project system. A key activity is running and measuring the upgrade regarding downtime, and testing downtime minimization approaches.
- Developers perform SPDD/SPAU adjustment and test custom developments and modifications. SPDD/SPAU adjustment is not a necessary step and can be skipped to reduce project effort.
- Business experts carry out upgrade Customizing and testing of business processes (test cycle I: takes two weeks)
At the end of this phase, business processes should be running properly in the sandbox system and there should be detailed documentation of the adjustment activities carried out by the development team.
These activities will help you refine the project plan and better understand the scope of the project.
5.1.4 Upgrade Realization
The upgrade realization phase marks the beginning of the dual maintenance period (of the DEV' and DEV systems). Figure 5.3 shows the system landscape during the upgrade realization phase.
In this phase, you create a copy of the development system (DEV') and perform a technical upgrade on the main development system (DEV). Alternatively, you can create the 6.0 DEV system as an upgrade from a copy of the production system (if size and security considerations allow it). This has the following advantages:
- Consistency of DEV and PRD concerning development objects is easily enforced.
- The upgrade of the production copy can yield a good assessment for the production upgrade (discarding factors such as machine size).
A disadvantage of copying the production system and upgrading it for the creation of the DEV system is the loss of versioning information, especially for ABAP developments.
Development activities concerning the upgrade project take place primarily in the main development system. However, the copy of DEV (DEV') is used to provide continuous support to the production system.
During dual maintenance, any changes you make to the contingency system because of production support requirements must also be made in the upgraded development system. It is important to consider a code freeze during this period. For suggestions on managing a code freeze during the dual maintenance period, see Section 4.4.2, "Technical Best Practices," in Chapter 4. Changes you make to the development copy (not yet upgraded) are transported to the quality assurance system (QAS) and from there to the production system (PRD).
Although the upgrade project should take priority, it is possible to continue working on concurrent projects. For example, you could work on a project that introduces custom development in the upgraded development system but for which the changes are not transported to the production system until after final the production cutover.
The following activities are carried out in the realization phase:
- The technical team sets up a temporary development system for maintenance (DEV') and upgrades the development system (DEV).
- Developers manually redo the SPDD and SPAU adjustment, manually redo the adjustment for custom developments, and perform short unit testing in the development system (DEV).
- The business experts redo Customizing adjustments and perform unit testing in the development system (DEV).
By the end of this phase, you should have completed the unit testing for custom developments in the development system (DEV).
5.1.5 Final Preparation for Cutover
In the final preparation for cutover phase, you create a copy of the quality assurance system (QAS') and upgrade the original quality assurance system (QAS). Figure 5.4 shows the system landscape during this phase.
During this phase, you continue dual maintenance of the development systems. You also transfer changes that you make in DEV' to DEV, and transport changes to both quality assurance systems.
The following activities are carried out during this phase:
- The technical team sets up the temporary quality assurance system (QAS'), upgrades the QAS system, transports project work to the QAS system, and continues to refine the cutover plan based on the work done so far.
- Developers correct errors in custom developments.
- Business experts perform final integration tests in the QA system (test cycle II: takes one week) and regression testing in the upgraded QA system.
During this phase, the testing of business processes is completed, the downtime estimate is refined, and the cutover plan is finalized and approved. You should now be in a position to embark on the final phase: the cutover weekend where you upgrade the production system.
5.1.6 Production Cutover and Support
The production cutover and support phase is the final phase that marks the completion of the upgrade project and culminates with the go-live of the production system. Figure 5.5 shows the system landscape for this project phase.
The following activities are carried out during this project phase:
- The technical team upgrades the production system (PRD) (including downtime). When finished, it performs post-upgrade activities.
- Business experts sign off on the upgraded production system.
- Depending on the archiving strategy, DEV' and CON' may be archived.
- It might also be advisable to keep DEV' available for some time after the upgrade to check the former functionality in case of unexpected errors.
At the end of this phase, the SAP ERP 6.0 system is released for productive operations and the temporary system landscape is removed. This is the final milestone: formal project closure. However, there is still a need for ongoing support of the upgraded system. Appropriate support activities must be adjusted and established.
You'll find more downloadable excerpts from books by SAP experts in our SAP chapter download library.
This was first published in April 2009