- 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.
- Technical
The IT team that manages the system technology such as hardware, the operating system, and database software.
- Development
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.
Project Activities
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.
Deliverables/Output
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.
Project Activities
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)
Deliverables/Output
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.
Project Activities
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).
Deliverables/Output
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.
Project Activities
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.
Deliverables/Output
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.
Project Activities
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.
Deliverables/Output
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 can download a pdf of this chapter. You can also visit SAP Press to purchase a copy of Managing SAP ERP 6.0 Upgrade Projects.
You'll find more downloadable excerpts from books by SAP experts in our SAP chapter download library.
Managing system landscapes during SAP ERP 6.0 upgrades
