SAP Ugrade Std

2009 SAP AG Upgrade and Enhancement Management Version: 2.0

Page 1 of 67

Version: 2.0

October 2009

SAP Standard for Upgrade and Enhancement Management

Whitepaper

Active Global Support

SAP AG

SAP Standard Upgrade


Page 2 of 67

Change history:

Version Date Changes

1.0 April 2007 Original version

2.0 October 2009 Completely updated and revised version



Page 3 of 67

Table of Content

1 MANAGEMENT SUMMARY ............................................................................................. 4

2 SAP STANDARDS FOR E2E SOLUTION OPERATIONS ............................................... 5

3 UPGRADE STANDARD AT A GLANCE .......................................................................... 8

4 WHAT IS THE BASIC CONCEPT OF THE UPGRADE MANAGEMENT STANDARD? .................................................................................................................. 10

4.1 SOLUTION CHANGES ALONG THE APPLICATION LIFE CYCLE ........................................... 10 4.2 UPGRADES MANAGEMENT IN THE APPLICATION LIFE CYCLE .......................................... 11 4.3 KEY FOCUS AREAS OF UPGRADES ............................................................................... 12

4.3.1 Program Definition: Align Upgrades with Corporate Strategy ........................... 12 4.3.2 IT Infrastructure Planning: Ensure Compatibility and Capacity ......................... 16 4.3.3 Application Adaptation: Understand Adjustment Requirements ....................... 20 4.3.4 Technical Change Management: Manage parallel changes ............................. 25 4.3.5 Data Conversions: Manage Unicode and Data changes .................................. 27 4.3.6 Business Downtime: Minimize System Outage ................................................. 29 4.3.7 Business Continuity: Avoid Surprises ............................................................... 32

4.4 PROTECTION OF INVESTMENT: ENSURE SOLUTION UPGRADEABILITY ............................. 35 4.5 GET READY FOR INNOVATION: SAP ENHANCEMENT PACKAGES .................................... 36

4.5.1 How to Include Enhancement Packages in your Upgrade ................................ 38 4.5.2 Activation of Business Functions....................................................................... 39

5 HOW TO IMPLEMENT THE UPGRADE STANDARD? ................................................. 40

5.1 METHODOLOGY .......................................................................................................... 40 5.2 SEQUENCE OF UPGRADE PROJECT ACTIVITIES ............................................................. 40

5.2.1 Overview ............................................................................................................ 40 5.2.2 Planning Phase ................................................................................................. 42 5.2.3 Implementation Phase ....................................................................................... 44

5.3 ROLES AND RESPONSIBILITIES ..................................................................................... 49 5.3.1 Roles during Upgrade Planning ........................................................................ 50 5.3.2 Roles during Upgrade Implementation .............................................................. 51

5.4 RECOMMENDED UPGRADE PROJECT LANDSCAPE ......................................................... 52 5.5 UPGRADE PROJECT DURATION AND TIMELINES ............................................................ 54

5.5.1 ERP Upgrades Experience Database ............................................................... 54 5.5.2 Evaluation of Upgrade Experiences .................................................................. 54

5.6 QUALITY ASSURANCE OF UPGRADE PROJECTS ............................................................ 56 5.7 SAP UPGRADE TOOLS ................................................................................................ 58

5.7.1 Technical Upgrade Tools .................................................................................. 58 5.7.2 Upgrade Management by SAP Solution Manager ............................................ 60 5.7.3 Additional Tools ................................................................................................. 64

5.8 UPGRADE INFORMATION SOURCES .............................................................................. 65



Page 4 of 67

1 Management Summary

Managing complexity, risk, costs, skills and resources is at the heart of implementing applica-tion life-cycle management for SAP-centric solutions. Complexity is increasing with the trend to out-tasking and out-sourcing process components. SAP provides a comprehensive set of application life-cycle management standards, to help customers manage their SAP-centric solutions. This paper provides details regarding the upgrade standard.

The main focus of the standard for technical upgrade management is to provide guidance for a holistic and effective quality management of an upgrade project from its earliest stages of evaluation until after a successful cut over of the productive system: end-to-end.



Page 5 of 67

2 SAP Standards for E2E Solution Operations

Companies expect from their IT departments that mission-critical business applications run smoothly, without business disruptions, at low cost, and that they can be adapted easily to new requirements. It is the mission of Application Life-Cycle Management (ALM) to achieve this. SAPs ALM portfolio consists of processes, tools, services, and best practices, to man-age SAP and non-SAP solutions, throughout the entire application life-cycle. For details about the complete portfolio, please refer to http://service.sap.com/alm.

According to the IT infrastructure library (ITIL), the application management life cycle com-prises six phases:

Functional and non-functional requirements are collected and evaluated during the requirements phase.

In the design phase, the findings from the requirements phase are used to specify how the application or IT operation processes are to function, and which IT applica-tions should be used to map the processes.

In the build and test phase, a system landscape is set up and configured to imple-ment and test the planned scenarios and processes.

The deploy phase is the transition from a pre-production environment to production operation.

The operate phase groups tasks that are performed after system startup, to ensure the availability and stability of the solution. These tasks include activities such as sys-tem administration, system monitoring, business process monitoring, message processing (Service Desk), root cause analysis, issue management, and service de-livery.

The optimize phase collects key figures and data from the live solution, to reduce costs or improve performance.

ALM processes span the six phases, to ensure stable operation of the IT solution while enabling accelerated innovation. Optimizing these processes reduces costs and ensures the highest quality of IT operation.

Typically, multiple teams are involved in the ALM processes (see Figure 2.1). They belong to the key organizational areas Business Unit and IT. The names of the organizations differ from company to company, but their functions are equivalent. For example, a program manage-ment office communicates business requirements to the IT organization, decides on the fi-nancing of development and operations, and ensures that the requirements are implemented. On the technical side, the application management team is in direct contact with the business units. It is responsible for implementing the business requirements and providing support to end users. Business process operation covers the monitoring and support of the business applications, their integration, and the automation of jobs. And SAP technical operation is responsible for the general administration of systems and system diagnostics. Further specia-lization is possible within these organizations. For example, there may be separate experts for different applications within SAP technical operations, in larger organizations.



Page 6 of 67

Figure 2.1: Organizational model for application life-cycle management

Two things are the key to optimizing the collaboration of the groups involved: a common in-frastructure, and a clear definition of the collaboration processes, including the activities in-volved, responsibilities, and service levels. The infrastructure is provided by SAP Solution Manager as a collaboration platform. It provides role-based access to all functions required (provided either by SAP Solution Manager itself or by integrated tools), via work centers. It also provides all related information, centrally, so that all stakeholders involved have easy access to the information they require. Many customers have defined collaboration processes. SAP has leveraged the experience of these customers, and of its own application life-cycle management experts, to create best-practice descriptions of important ALM processes. These documents are published as E2E Solution Operations standards at http://service.sap.com/supportstandards in SAP Service Marketplace. Customers can refer to these standards when optimizing their own IT processes.

With Run SAP, SAP provides a methodology for the implementation of the End-to-End Solu-tion Operations standards. The road map for Run SAP guides through defining the scope of the operations to be implemented, preparing a detailed plan, doing the setup, and running SAP solutions. Moreover, it helps to find the right strategy and tools to implement ALM. The road map provides not only what needs to be implemented but also information about how it needs to be implemented, in the form of implementation methodology documents and best-practices documents.

Currently, SAP provides the following standards:

Solution Documentation and Solution Documentation for Custom Development define the documentation and reporting required for the customer solution

Incident Management describes the incident resolution process

Remote Supportability contains five basic requirements that have to be met to optim-ize the supportability of customer solutions

Root Cause Analysis defines how to perform root cause analysis, end-to-end, across support levels and technologies



Page 7 of 67

Exception Handling and Business Process and Interface Monitoring explains how to define a model and procedures to manage exceptions and error situations during dai-ly business operations, and how to monitor and supervise mission-critical business processes

Job Scheduling Management explains how to manage the planning, scheduling and monitoring of background jobs

Data Integrity and Transactional Consistency avoids data inconsistencies, and safe-guards data synchronization across applications, in distributed system landscapes

Data Volume Management defines how to manage data growth

Change Management enables efficient and punctual implementation of changes with minimal risks

Test Management describes the test management methodology and approach for functional, scenario, integration and technical system tests of SAP-centric solutions.

System Monitoring covers monitoring and reporting of the technical status of IT solu-tions

System Administration describes how to administer SAP technology to run a custom-er solution efficiently

Custom Code Management describes the basic concepts of custom code operation and optimization

Security describes basic activities to setup, maintain and evolve security measures for the operation and organization of SAP solutions.

Upgrade guides customers and technology partners through upgrade projects

Out of this list, this white paper describes the standard for upgrade.



Page 8 of 67

3 Upgrade Standard at a Glance

Changing business conditions lead to changing IT solutions, and every evolving organization needs to adapt its IT environment accordingly. This drives the need to upgrade or to enhance your SAP software on a regular basis. Only if your system landscape is up-to-date in terms of software releases and underlying technology, you can benefit from the latest available func-tionality, leverage new technologies that foster innovation, and guarantee long-term protec-tion of IT investments.

No matter what determines the specific business case, an upgrade project, like any other project, must complete "in scope", "in budget", and "in time". With the implementation of the concept outlined below, any project can effectively master the jump on-to the next generation of a SAP solution. At the same time, it is ensured that all activities related to the change are performed as efficiently as possible in order to safe resources and budget.

The main focus of the standard for SAP Upgrade Management is to provide guidance for a holistic and effective quality management of the required project from its earliest stages of evaluation until after a successful cut over of the productive system: end-to-end. This also includes best practices how to review and ensure upgradeability of a solution already in the implementation or operation phase to protect your investments in a later change project.

This document does not deal with application specific details of the upgrade execution. SAP is providing comprehensive upgrade and installation guides for all supported software life-cycle events of its products. Quick links to the respective SAP information sources are pro-vided in the appendix of this document. It is strongly recommended reading the latest version of these documents very carefully right before the execution of the upgrade and following the instructions provided with no exceptions.

Also, business and management aspects of the project execution, like business case crea-tion, budgeting, staffing, and reporting, are not discussed here in detail.

The execution of an SAP upgrade is a rather uniform sequence of activities; there are fewer variations in the general procedures than in implementations. SAP provides a number of supporting documents, tools, and services that are designed to further decrease the com-plexity and risk of such projects. So why would another paper, the definition of standards, add value to this situation? It provides focus!

First of all, the established sequence of activities needs to be clearly defined. SAP's Upgrade Roadmap, which can be found in the SAP Solution Manager, serves as starting point for this definition. For every major step, the relevance and impact is highlighted, in order to help deciding which level of attention should be spent on it in an individual project. There is no detailed description of activities to-be performed in a "how-to" manner: comprehensive documentation about this is available.

Second, there is a small number of key focus areas of an upgrade. Independently of the specific constellation, these areas decide about success or failure. Based on a few parameters, it can be decided which of those key focus areas deserve most of a projects attention throughout all phases and activities.



Page 9 of 67

Finally, SAP provides tools and services supporting the upgrade projects in all stag-es. The central platform for these tools and services is the SAP Solution Manager. Knowing these tools and services is crucial for an efficient, fast and safe transition to the new release. Therefore, we outline the most important ones in this standard as well.

Having the right focus helps directing resources and attention where they are needed most at the right time. And no relevant points will be missed.



Page 10 of 67

4 What is the Basic Concept of the Upgrade Man-agement Standard?

4.1 Solution Changes along the Application Life Cycle

The life of any IT solution, from the first implementation concept to the final phase-out, can be described as series of business configuration states connected by permitted transitions. While the business scope and scale of each configuration change can vary widely, the man-agement of these changes can be described best as a repetitive life cycle. SAP uses the Application Management life cycle described in ITIL (V3) as a commonly agreed model to guide you through this sequence of business configuration processes.

Figure 4.1 outlines the most important change events in the life cycle of your solution.

Ongoing

Change

Events

Discrete

Change

EventsCustomer

Enhancement

Upgrade

UpdateCustomer

Patch

Installation

New procesroll-out

Time

Update Update

Enhancement Enhancement

Effo

rt

Time

Figure 4.1: Change events along the application life cycle

The scale and frequency of the changes and, hence, the impact to your solution varies de-pending on the underlying business requirements. We distinguish the following main life cycle change categories:

1. Installation

An Installation also called initial implementation - is the complete new setup of a sys-tem mostly on new hardware. Migration might be necessary from former legacy systems. Beside the initial implementation of a SAP product, also the installation of additional new add-ons or other software components fall under this category.

2. Update

An Update is a set of corrections for software errors and severe performance problems in the SAP system. The media for this are Hot-Fixes, Support Packages (SPs) or SAP Notes. Support Packages are compiled periodically and made available via the SAP So-lution Manager.

This maintenance process has the aim to correct known errors in applications by mini-mizing the impact to any existing landscape elements and running processes. Regres-sion tests are needed and non-disruptiveness in user interfaces shall be assured. New functionality or different behavior of existing processes is not expected.



Page 11 of 67

3. Enhancement

An Enhancement contains a larger number of objects where the majority does not have the aim to correct errors but enhance features and functions. The media for this are En-hancement Packages (EhPs). New functionality is expected (enabled by switches in EhPs) but different behavior of existing processes clearly not. Also, migration efforts shall not occur. An enhancement changes the version of a software component but not the re-lease.

The concepts of enhancement packages and switches are also the recommended tech-nology for customer enhancements in the future.

4. Upgrade

An Upgrade contains all objects of a software release. The media for this are software re-leases. In this case, the shipment of additional functions and features and redesigned processes is the main focus. However, in most cases the same functionality of the pre-vious software is also available within the higher release, which allows a Technical Up-grade as first step. Nevertheless, different behavior of existing processes may occur as well as migration efforts.

With an Upgrade, customers switch from an older software release to a newer one. Typi-cally, both the server component of a system landscape and components on top of this are upgraded.

5. Business Improvements

During a Business Improvement, new business processes are implemented in an existing system. This may include the development or update of custom programs and customiz-ing or the activation of business functions. However, the SAP software release, software component versions or patch levels are not changed.

To properly manage the planning and realization of these changes, an upgrade and release management has to be implemented in your company as part of the overall application life-cycle management. The responsibility for this task shall be assigned to the customer center of expertise (CCoE). The CCoE is a team made up of a group of quality managers located in the companys application management unit (see figure 2.1) acting across all business units. The team sets basic rules that facilitate communication and collaboration between business and IT and it brings all stakeholders to the table to resolve challenges and issues.

4.2 Upgrades Management in the Application Life Cycle

Within the CCoE team, the quality manager for protection of investment is mainly responsible for upgrading the technology framework and application components of the companys soft-ware landscape on a regular basis. This careful maintenance results in a well-defined, har-monized software landscape that is far easier to upgrade than a software landscape made up of different product releases and unaligned support packages. Another objective of the quali-ty manager is to prevent the introduction of unnecessary modifications or custom develop-ment to the software landscape. Keeping custom code to a minimum helps reduce develop-ment costs in general and upgrade costs in particular.



Page 12 of 67

In addition, the quality manager works closely with the program management office, which oversees all ongoing projects. In the context of upgrade and release management, the quality manager must create a master release plan for the products and solutions in place and for solutions planned to be deployed. The master release plan must be aligned with the compa-nys overall strategy and constraints, especially budget constraints. It must also be aligned with general release strategy SAP has committed to for delivering its software. To come up with a reasonable plan, the quality manager should take the following factors into account:

The companys own strategic needs, for example, whether there should be stronger emphasis laid on customer management, integration of supplier systems, or com-pliance

Operational issues of the existing solutions, like functionality gaps or compatibility is-sues

End-user feedback on the existing solutions, which may include a demand for change

Improvements in terms of better usability, functionality, performance, or technological handling contained in a new release

Expiration of maintenance contracts on existing software requiring an update to a new software release

The other projects in the company portfolio and their relationship and dependency with the upgrade project. Most of the time, dependencies will exist with respect to timelines and utilization of company resources

4.3 Key Focus Areas of Upgrades

While details of the upgrade related tasks and the technical upgrade itself may vary depend-ing on product, release, platform, and interface constellation there are seven key topics that always need to have full attention to successfully accomplish them. These topics will be ex-plained in the seven sub-chapters of this section.

If all of these focus topics are properly managed, a successful upgrade should only be a mat-ter of professional execution of the task sequence outlined further below.

In practice, most upgrades for SAP applications are technical upgrades, where the existing functionality is left unchanged while a new release is applied. Therefore, we concentrate on this specific case for most of the discussion of the key focus areas. If additional functionality is being implemented in parallel to the upgrade, the relevant SAP E2E Implementation Stan-dard needs to be taken into consideration as well.

4.3.1 Program Definition: Align Upgrades with Corporate Strategy

Large corporations usually maintain a number of complex solutions that consist of SAP and non-SAP products running on several productive systems. In most cases, this makes up a heterogeneous environment in which some of the following characteristics may vary in the course of time: IT provider concept, data center concept, server architecture, operating sys-tems and databases, SAP products and versions, language support and communication structure.



Page 13 of 67

Within those environments, there are always mutual dependencies between the systems. Therefore, it is very important to update a corporate global IT program definition in the special context of upgrade before the first individual projects take off.

In order to highlight the reasons for such a step, three dimensions of an IT program are dis-cussed: Technical Infrastructure, Business Solutions, and Solution Operations. The metho-dology for this type of upgrade impact analysis is:

provide full transparency about the status quo,

collect all information about intended changes,

put all these facts into the context of upcoming upgrades and

derive the impact and required consideration for the preparation of an individual up-grade.

Technical Infrastructure

The installed hardware and software components are the basis of any IT solution. A full and transparent documentation of all these components is crucial for the planning and execution of an upgrade project. All relevant characteristics that describe each of the existing solutions are determined and stored into a central repository. The SAP Solution Manager System Landscape, accessed by transaction SMSY or via the System Landscape Management work center, provides a possible storage location.

Beside the technical solution components, there are also other important factors to be consi-dered when looking at the technical infrastructure. Among those, the provider concept, geo-graphical location, the data center concept, and server architecture are the most important characteristics.

Which changes are intended in the foreseeable future, either driven by the corporate IT pro-gram management or by local system owners? Is a change of the provider model planned: may systems get moved into a hosting scenario? Will geographical re-locations take place? Is it possible to merge servers into one data center? Will global agreements with hardware vendors regarding new architectures be negotiated (new CPU type, blade server, adaptive computing etc.)? Does the global policy regarding operating system or database product change?

Answers to all these questions are valuable context information when starting the preparation of an upgrade. Why? An SAP release upgrade triggers almost always changes at all levels of the vertical software stack and ask for at least some additional hardware resources. Thus, when planning an individual upgrade, IT has to consider such changes and may decide to make IT changes in combination with the upgrade. This would be expected to save effort and costs for the individual project.

However, it is advisable to decouple infrastructure related adjustments as much as possible from the upgrade: complete all these required changes before the upgrade project itself is kicked-off. This approach will avoid risks originating from the mixtures of infrastructure and upgrade projects.



Page 14 of 67

For each individual situation, the right balance between risks and costs can only be deter-mined if all influencing factors are known and considered. This underlines the importance of having a global IT program defined and updated well in advance of major change events like an upgrade.

Business Solutions

The business solution consists of the business processes and scenarios utilizing one or more software components of the technical infrastructure. For all systems that establish the differ-ent business solutions, a number of information has to be considered when completing an upgrade program on corporate level:

Business Context per System: What are the business areas and scenarios imple-mented and how do you rate criticality and business impact of system failures? What are business requirements that need to be considered?

Life-cycle Phase per System: Is it in an implementation, continuous improvement, upgrade or system consolidation phase?

SAP Maintenance Situation: What type of contract situation do you have: standard maintenance, extended maintenance, or customer specific maintenance?

Clusters of Dependent Systems: Can you determine which systems have to be treated as a cluster, because they exchange data or because business processes run across system borders. Which systems belong to the same set of repository tem-plate sender and receivers or take part in a customizing distribution?

Again, a complete documentation of your business solution is an important prerequisite for answering the questions above. In the end, it is possible to describe a complete set of de-pendencies that help understanding which systems and solutions have to be considered as dependent when preparing an upgrade. Dependencies may have an impact on timing and sequencing of upgrades or the determination of the target release. They will usually increase the complexity of end-to-end integration tests. Or they require specific planning and prepara-tion for the productive downtime of one of the systems in a cluster.

Beside these more software related dependencies of your business solution, it is also crucial for the success of an upgrade project to get the commitment and involvement of the business departments as early as possible when planning an upgrade. In many cases, business re-quirements are the main driver for upgrades of a SAP solution. In these cases, an early in-volvement of business is an important prerequisite for a successful upgrade project. But even in cases, in which IT or maintenance benefits justify an upgrade, business needs to be on-boarded already during the planning phase to avoid complications during project execution. Because of the required involvement of the business in the upgrade project, it is the business that has to finally sign-off the upgrade.

Therefore, it is not surprising that particularly those upgrade projects are completed success-fully in time and in budget, which created a sound business case with strong involvement of business and IT already during the initial planning phase of the project.



Page 15 of 67

Solution Operations

An upgrade project relies on well-established solution operations. Any intended change is a potential risk for the robustness of operations. On the other hand, changes come with poten-tial benefits for operations and implicitly for the upgrade. Some changes may be a pre-condition for a successful upgrade. Or an upgrade would be a perfect occasion to use an improved tool or process and return the first payback on an investment made before. There-fore, it is important performing an upgrade impact analysis to solution operations already during upgrade planning or even earlier.

Solution operations comprises the people and their assignment to roles, the solution support processes that comprise all relevant operational tasks, and a platform that facilitate the processes and provide the tools that help the people to fulfill their tasks. Regarding upgrades, the following impacts and dependencies have to be considered:

People: It needs to be clear what the actual assignment of roles looks like, how the available skill set is described, if there is potential to invest into these skill sets, if knowledge pools or centers of expertise exist or are planned, what skill changes are required to manage the new solution, and if there are bottlenecks of resources with a certain skill set.

Processes: The established processes need to be clearly defined and described. Their scalability and robustness must be proven: during upgrade projects, daily operations and exceptional project work load hit the same resources.

Particularly if you change or add business scenarios or introduce new technologies in your solution, the impact to solution operations has to be carefully analyzed. Examples that are relevant in the upgrade context are introduction of new administration concepts like Java monitoring or change of existing procedure due to changed tools or settings.

Platform: Important questions in this context are:

Which tools have been deployed?

Are there intensions or requirements to add or change some?

Are there known scenarios where investments are required?

Summary

An Upgrade Project must not only focus on the system(s) to be upgraded. Depen-dencies may exist on various technical and organizational levels and might not be visible in the first place.

Certain questions and conflicts can only be resolved on a strategic program level. (i.e. software logistic in template scenarios, allocation of limited key resources to projects ...). Therefore, these topics need to be aligned with the corporate IT strategy timely before the upgrade project starts.



Page 16 of 67

The upgrade project effort can be reduced by fully using all synergies with corporate IT Program activities.

Upgrade projects are not only IT projects. An upgrade has an impact to the whole corporation. Thus, business has to be involved already in the very early stages of upgrade and release strategy definition as well as the project planning. Experience shows that building a solid business case is a key success factor of any upgrade project.

In case of large solution landscapes requiring several upgrades of SAP software, a special pool of in-house upgrade experts should be set-up building a center of excel-lence. This will leverage the knowledge and experience in all projects.

4.3.2 IT Infrastructure Planning: Ensure Compatibility and Capacity

A proper infrastructure planning is a prerequisite for a successful upgrade realization as well as for a reliable and well performing target solution. In this section we discuss the major chal-lenges of this task, which are ensuring the compatibility of all connected software compo-nents and the correct sizing of the hardware needed for the future solution.

Component Compatibility

Every SAP system relies on a stack of technical software components to run. Frequently called the vertical or technology stack, it is mainly comprised by the operating system, the database, the SAP kernel, the SAP application and add-ons, and the user interface. Between all those elements of the stack, there are compatible combinations and restrictions. By the time a component is developed, it is developed and tested in an environment made-up of the components and its versions available at that point in time. After completion, additional com-binations may be tested on top. But the number of variants of components is limited.

SAP is publishing its Product Availability Matrix (PAM) on the SAP Service Marketplace (http://service.sap.com/pam), where the released combinations can be retrieved. For SAP add-ons, you should also check the respective release restriction and add-on release strate-gy notes. This information could be best found when entering the add-on name and search string release strategy into the SAP notes search on the SAP Service Marketplace.

It is required to also consider the compatibility between different SAP and non-SAP systems connected in the solution to run the business processes, which can be referred to as the ho-rizontal stack. In general, different SAP systems can communicate to each other indepen-dently on their respective release. But in some specific cases, rather complex restrictions apply depending on certain criteria. For example an Employee Self-Service (ESS) business package running on an SAP ERP backend and a SAP NetWeaver Portal may require dedi-cated releases on both ends depending on the used self-service scenario.

The Upgrade Dependency Analyzer (UDA) helps you with analyzing known dependencies when upgrading technical components in their landscape. Accessible from the SAP Service Marketplace at the link http://service.sap.com/uda, this tool provides dependency information to support the planning of upgrade projects.



Page 17 of 67

A special challenge arises if a Unicode conversion is necessary. Here, it has to be guaran-teed that characters are properly encoded and exchanged between all systems connected to the system that is converted. The most complex situations exist, when Unicode systems communicate with systems using SAP proprietary multi-display/multi-processing (MDMP) or blended codepages. Such communication requires special consideration and maintenance efforts and, hence, should be avoided.

Generally, the business impact of converting systems to Unicode should be taken into con-sideration during project planning. In this context, the ordering of Unicode conversions is important and some systems need to be grouped together for conversion. Also for the instal-lation of additional languages in a Unicode-converted system, the data exchange with non-Unicode systems need careful analysis. Additionally, the compatibility with non-SAP software and peripheral equipments like printers or fax machines is a critical aspect that is often forgot-ten. All of these Business impacts are solved once the whole business landscape is running on Unicode, which is the target state recommended by SAP. Information on Unicode specific topics is published on the SAP Service Marketplace (http://service.sap.com/unicode).

Finally, compatibility has to be checked for connected non-SAP products or add-ons to SAP products. Here, it is important to verify with the respective vendors if the used software is released and certified with the planned SAP target release and what adjustments or changes are required. Additionally, information is provided in SAP notes at least for some third-party add-ons.

Technical Component Sizing

Different code needs different hardware. And because there is usually a lot of different code, the additional hardware required can also be quite considerable. Clearly, the larger the re-lease leap, the bigger are the average hardware additions as shown in figure 4.2 for SAP ERP.

Determining the right size of all relevant system resources is a crucial aspect of the upgrade. Only this way you can achieve a performance on the established levels with no bottlenecks and just a reasonable portion of the upgrade to be spent on hardware.

It all starts with a clear picture of the current situation. It can easily be obtained by using the EarlyWatch Alert scenario of SAP Solution Manager. There you will find the current load of key system resources as well as available buffers for future growth. Then, look into the SAP notes providing information on the upgrade sizing to get a first estimate of additional hard-ware requirements. Your hardware partner will help to further refine the actual size of all ma-jor system components in the target scenario. If Unicode and Upgrade are combined into one project, Unicode's extra resource requirements have to be considered on top:



Page 18 of 67

SAP Note:

Source

Release:

0,0%

20,0%

40,0%

60,0%

80,0%

100,0%

4.0b 4.5b 4.6b 4.6c Enterprise 1.10 Enterprise 2.00 ECC 5.00

113795 178616 323263 517085 752532 778774 901070

Memory App CPU App Disk DB

Figure 4.2: Average total increase in hardware consumption for upgrades from the source release to SAP ERP 6.0. Note: The SAP notes provided in the figure only contain delta-sizing information from the respective source release to the next release. The shown total increase is the sum of all del-ta-sizing information from source to target release.

UTF-8 ORACLE1, DB/2 (Unix):+10%235%3

UCS-2 MaxDB, SQL Server:+4060%

UTF-16 DB2 (AS400): +10...20%

UTF-16 DB2 (zOS): - 20...10%4

Database size

UTF-8

almost no change due to efficient

compression

Network Load

+ 5% 30%

depending on existing scenario

(MDMP, double byte) and type

of CPU

CPU

+ 40% 50%

reason: application servers

are based on UTF-16

internally

RAM

1 Oracle uses UTF-8 variant called CESU-82 10% is the observed maximum for bigger systems (db size > 200 GB).3 35% is the observed maximum in growth for small systems (db size < 200 GB).4 SAP Unicode installations on z/OS always use hardware compression which overcompensates the growth due to Unicode;

without compression DB size would increase between 2060%

Figure 4.3: Average hardware requirements for Unicode Conversions. The numbers are based on parallel benchmarking of Unicode / non-Unicode test systems.



Page 19 of 67

All of the values in Figure 4.3 are average values. Also refer to SAP note 1139642. Based on the real scenario that is used in the system to be upgraded, those values may be very differ-ent from the ones displayed here. For example, measurements in customer system using UTF-8 based databases showed that more than 90% of the databases actually have shrunk about 10%. The main reason for this decrease is that with the Unicode conversion also a database re-organization is performed freeing unused space. Particularly, with large data-bases such re-organizations are carried out seldom because it impacts the availability and performance of the system.

SAP provides the SAP CQC GoingLive Functional Upgrade service as part of SAP Enterprise Support to conduct a plausibility check of the sizing of the target system. This may include upgrade as well as Unicode sizing. For details, please refer to the service description in SAP Service Marketplace (http://service.sap.com/goinglive-fu).

Are there any options to avoid this extra IT investment? Yes, if some attention is paid on the optimization of the following two main aspects of solution operations, then the gross effect on the hardware requirements can be minimized.

Data Volume Management

This discipline deals with the procedures needed to identify data in a system that could be avoided or deleted because of the redundant nature or because they are only temporarily relevant. And it is about summarizing and archiving data which is important and needed, but possibly in another granularity or on other media than the database of the SAP system. De-tails about those procedures can be studied in the Data Volume Management whitepaper, which is part of the SAP standards for E2E Solution Operations.

Based on experience, it is possible to save 25-30% of disk space without complex archiving. If archiving is also considered as an effective strategy to reduce volumes before the upgrade, the relevant archiving project needs to be kicked-off some months before the upgrade. A parallel execution of a data management or archiving project and an upgrade project is not recommended because normally there are interdependencies between the projects (e.g. shared application and IT staff or system resources) that can negatively impact the duration and smooth execution of the upgrade project. Any established archiving or housekeeping activities should be completed before the upgrade of the quality assurance system.

A proper data volume management can also help to minimize the business downtime of up-grades and Unicode conversions. Please refer to section 4.3.6 Business Downtime: Minimize System Outage for details.

Performance Optimization

Many transactions can be speed up by small adjustments to the customizing scenario, the coding, or the way the database is accessed. If there are a few transactions that dominate the total system load, having a look at their optimization options may result in a considerable reduction of the system load before the upgrade. In the end, hardware additions may even be avoided if the performance optimization was successful.



Page 20 of 67

Summary

A compatibility check of all software components and the proper sizing of the hard-ware of a solution are important tasks to ensure a successful upgrade project and a smooth solution transition. These tasks have to be addressed already early in the planning phase of an upgrade project as they may have an impact on the overall IT program definition and the creation of a business case for the upgrade.

Use the SAP Product Availability Matrix to check OS/DB compliance, platform re-quirements, availability of country versions and languages or SAP solution exten-sions by partners.

Use the SAP Upgrade Dependency Analyzer to get a high-level overview of possible conflicts between different systems.

Data volume management and performance optimization are housekeeping activities that can have a positive impact on the required additional hardware resources. These activities have to be considered and completed in advance of an upgrade project.

If a new SAP GUI version is required, start the distribution already before the up-grade project.

4.3.3 Application Adaptation: Understand Adjustment Requirements

Adjustments are always required. Even when the intention of the upgrade is that everything just works as before, customizing, coding, and interfaces have to be reviewed. Thousands of lines of SAP code are changed within the system. The SAP scenarios are updated. Screens, structures, tables and data models, and even transactions are not the same. The constella-tion regarding the releases of connected systems is changed. Some systems go Unicode, others, maybe dependent ones, do not. The reasons why a plain upgrade does have an im-pact on the currently used business scenarios are manifold. On the other hand: nobody wants to redo the whole implementation. How is this conflict resolved?

The key is to set the right focus and to invest the upgrade project resources where it really matters.

Many customers seek to accomplish this goal by looking for lists of all repository objects, customizing settings and business process steps that are touched by an upgrade. While this approach indeed leads to a better understanding of adjustment needs, it is often not sufficient to really significantly reduce the efforts. The lists can contain thousands of objects to be in-spected in detail still causing a lot of unnecessary efforts. We recommend combining this technical approach with a business related view on the importance of the identified changes.

To do so, you have to rate your business processes and steps based on a risk- impact-analysis:

The "distance to standard SAP" of an implementation of a business transaction determines the upgrade criticality, which is the risk that it won't run after the upgrade. If a transaction is used "out of the box" just in the way it was intended to be used, it will not fail after the up-grade.



Page 21 of 67

Regarding impact and criticality, just imagine the "Monday morning" after the upgrade week-end: what MUST run without any exceptions?

Figure 4.4: Upgrade risk-impact analysis approach

Figure 4.4 illustrates the procedure. With such an analysis, it is possible to identify those areas that require most attention. Subsequently, a more detailed technical upgrade change impact analysis of those most critical business areas should be performed.

In order to keep this task manageable, you will usually be analyzing and performing the ap-plication adaptation along business functionality or business processes and work on the indi-vidual technical objects as they belong to functionality. For this task, a good and complete documentation of the implemented processes is necessary as a reference. SAP recommends having this documentation readily available in SAP Solution Manager.

It is strongly recommend performing a sandbox test upgrade as early as possible, even be-fore the official project kick-off in the project preparation. What are the benefits of such an early upgrade? First, the project team can collect valuable experiences on upgrade execution very early. Then, it makes it possible generating technical lists of repository and customizing objects that need adjustment or closer inspection. Additionally, it enables key users to get an early impression of the user experience and capabilities of the new release, which can help planning training measures. Finally, first estimates of the technical downtime can be obtained if a copy of the production system is used for this test upgrade. All this information helps to better plan and prepare the project and, hence, should be the first step of any well managed upgrade project.

In the following we describe the most important scenarios that have to be considered for an upgrade change impact analysis.



Page 22 of 67

Modifications

Modifications are changes to repository objects in the SAP namespace. The import of new versions of these objects during the upgrade leads to conflicts that need to be resolved, which basically means to either keep the modification or return to SAP standard. Therefore, the handling of modifications is part of the standard upgrade procedures.

Modifications to data dictionary (DDIC) objects are analyzed by the SAP tool Modification Adjustment Dictionary (transaction SPDD). Conflicts of DDIC objects must be handled very carefully because wrong adjustments may result in data lose or inconsistencies. The SPDD has also to be processed in the very first upgrade tests, as the upgrade test results will be spurious otherwise.

Other repository objects are analyzed by the SAP Tool Modification Adjustment (transaction SPAU) or the SAP Modification Browser (transaction SE93). As a rule of thumb, the effort for adjusting SPAU is normally 10 times higher than for SPDD. Therefore, it is important to un-derstand if the modifications are really still needed or if SAP standard can be used instead. A technical usage analysis is a very good starting point for such an analysis because modifica-tions that are no longer used could be easily replaced. This will already help reducing the adjustment efforts. Such an analysis should already be started several months before the upgrade project to have a reliable usage history. A good method to log this history is extract-ing the workload and performance statistics provided by transaction ST03N to the respective BI InfoCube in SAP Solution Manager. This allows storing the ST03N history for timeframes that are longer than the normal retention period in the source system.

Additionally, it is often an advantage to check the existing modifications in the system and determine which of these can be moved towards SAP functionality in the course of the up-grade. Reducing the number of modifications in such a manner will always reduce TCO and lead to a more flexible system.

Custom Developments

Developments in the customer namespace are not directly touched by an upgrade. They are just kept as they are. Nevertheless, custom development objects working correctly in one release may not work in an upgraded release. There are a variety of reasons for this. SAP may change the syntax of the ABAP language to take advantage of improvements in tech-nology. Another source of problems is the fact that custom code usual contains static or dy-namic references to SAP objects. If those happen to be changed, the impact of this has to be reviewed. Particularly, if custom transactions of executable reports have been created as copies of SAP programs, these cloned objects present unique challenges after the upgrade (why SAP does not recommend programming this way).

Analyzing, testing and correcting custom developments normally takes even more time and efforts than modification adjustment, simply because there are normally more custom objects than modified objects. Additionally, tools like SPDD and SPAU do not look into the customer namespace. Therefore, testing and adjusting custom developments is frequently the main effort driver of upgrade projects.

To limit these efforts, an extended syntax check by the Code Inspector (transaction SCI) should be performed at least for the most important and critical custom developments as



Page 23 of 67

soon as an upgraded version of these programs exist, e.g. after a test upgrade. Additionally, SAP offers the toolset SAP Custom Development Management Cockpit (CDMC) as part of the SAP Solution Manager Enterprise Edition. One of the contained scenarios is the upgrade impact analysis. It compiles a list of custom objects that meet the following two criteria: a reference to a SAP object exists and this SAP object will be changed by the upgrade. With this list, all custom objects can be better classified regarding their upgrade impact and used for a better planning of the adjustments and testing.

Again, this impact analysis should be combined with a usage analysis as described in the previous paragraph. In addition to a ST03N statistics analysis, CDMC provides capabilities for this task as well. By pinpointing obsolete custom code, it offers a great savings potential. Custom code can be removed with no detriment to the software landscape, which reduces maintenance costs and accelerates upgrades.

If a Unicode conversion is in the scope of the project, transaction UCCHECK should be run on the upgraded system. It will complete the list of objects to be adjusted with those from the customers namespace that are not compliant to the Unicode syntax requirements. Even if a Unicode Conversion is not planned together with the upgrade, we recommended making the entire customer coding Unicode compliant already during the upgrade adjustment phase. A Unicode compliant coding can also run on non-Unicode environments. This helps reducing test efforts for a Unicode conversion in the future.

Customizing

Customizing is a major task if new functions or enhancements are activated in the course of an upgrade project (Delta Customizing). However, even in the case of pure technical up-grade, there can be changes to SAP standard processes and functions that require adjust-ments or extensions of the customizing settings (Upgrade Customizing).

Basic source for information on Delta and Upgrade Customizing are the SAP Release notes and SAP Implementation Guide (IMG). The SAP Solution Manager also offers Delta- and Upgrade Customizing features that allow compiling a list of customizing settings that should be considered for adjustments.

Application Changes

SAP always attempts to create downward compatible programs. This ensures that you can still execute the old functions and programs in the new release. However, the introduction of new business functions, legal requirements or new frontend technologies in the SAP software make it sometimes necessary to redesign the SAP standard. This may lead to a complete change or even replacement of existing transactions, reports, function modules, or data models. Therefore, also customers using SAP standard to run most of their business processes may have to deal with application changes and business process adjustments when they upgrade.

To identify application changes, carefully analyze the SAP upgrade guides and release notes, particularly the release restrictions published for every SAP product version. Addition-ally, we recommend using the Application Specific Upgrade (ASU) toolbox to analyze changes in the application areas. The ASU Toolbox enables you to recognize additional,



Page 24 of 67

application-specific steps before and after the upgrade, in addition to the actual technical upgrade. It covers the following main areas of application changes:

Checks if certain customer specific data still exists and is useable (e.g. report-variants, display variant, exits, ...)

Information on necessary customizing settings for new functionalities

Start of reports adjusting your data to the new release that are not part of XPRA's started automatically during the upgrade

The ASU toolbox can be very well integrated with the standard upgrade procedures through automatically generated task lists providing all required tasks in their optimal sequence. It also offers integration with the SAP Upgrade Roadmap via the upgrade project management in SAP Solution Manager.

Security Management

Another important topic in the context of application changes are changes of the authoriza-tion or security concept. Usually, a new SAP software release comes along with a lot of changes, extensions or new authorizations or even complete new authorization concepts. Therefore, authorizations must be defined or tailored for new and changed business processes and authorization objects in the target landscape. In SAP WebAS ABAP based systems, you should use the profile generator (transaction SU25) to perform a step-by-step comparison and correction of changed authorizations. This transaction also allows viewing changed transaction codes that have been assigned to roles.

An upgrade also requires a revision of the general security policy. In particular, take into ac-count new functions, technologies and protocols (such as access via HTTP), as well as the use of new releases of operating system and database software.

The effort and criticality of these activities are frequently underestimated. Particularly, if spe-cial legal requirements exist, like for example compliance with certain standards (FDA, GxP, SOX). Revising and testing the authorization and general security concepts are crucial for a final sign-off of the upgrade. Thus, missing these tasks could easily lead to delays and extra costs in the project.

Interfaces

Today, business solutions usually consist of many systems and applications communicating via a variety of interfaces. Ensuring the stability, consistency and performance of these inter-face communications while one of the connected software components is upgraded, is a key tasks to be accomplished by the project.

The challenges differ with the type of interfaces in use. Connections between SAP software components are normally the least critical group of interfaces, as here SAP takes care of the compatibility. If interface technologies are changed or new interfaces are added, however, the interface management concepts and handling procedures need to be inspected and adopted to keep performance and stability of the business processes.



Page 25 of 67

In case of connections of SAP systems to partner software, it has to be made sure that this software is released and certified for the usage with the new SAP release. Sometimes, this requires an update of the partner software as well. Contact your software vendor to get the information on the interoperability with the SAP software.

If interfaces have been developed in-house, in the first place all considerations apply that have been made above for custom developments in general. Good candidates for a more accurate inspection are any type of file uploads to the upgraded system using technologies like BATCH INPUT or CALL TRANSACTION because changes of the transaction (format, required inputs etc) usually lead to errors in the file upload process. Therefore, it is normally better using BAPIs to implement such interfaces. This interface technology is more stable and changes are better documented. In future, BAPIs will be replaced by Enterprise Services technology (ESR). The most important BAPIs are already available as Enterprise services (as of SAP Netweaver 7.0). Thus, you should consider using Enterprise services when changing your old interface programs.

Summary

Application adaptation is always necessary during an upgrade. In fact, adjusting business process is one of the major cost drivers of any upgrade, particularly in high-ly customized systems.

You can minimize the adjustment costs and efforts by focusing on critical business scenarios and processes. Not every repository, data or customizing object that shows conflicts in or differences to the new release, has to be corrected in the first place.

Perform a test upgrade on a copy of production (sandbox upgrade) as early as poss-ible. This enables you to analyze your system and set the right focus for your adjust-ment work.

Analyzing and correcting custom developments is the biggest block of adjustment work. Use sophisticated tools like SAP Custom Development Management Cockpit to analyze these developments in the sandbox system.

Use the Application-Specific Upgrade toolbox for a systematic, tool-based approach to execute application specific adjustments.

4.3.4 Technical Change Management: Manage parallel changes

For a system in continuous improvement phase, most organizations have a comprehensive procedure in place to manage changes: the requirements are evaluated, there is a workflow for decisions making, implementation, testing, and deployment. The reason to have such a mechanism in place is first, to perform an assessment if the final value of a realized change exceeds its implementation effort and second, to minimize the potential impact including side effects on the rest of the solution.

It is very important not to compromise any aspect of this process in the course of an upgrade. A project could be tempted to allow mass exceptions from the set of rules because there are usually many changes that have to be implemented in a short period of time and because there is often not enough time for a thorough evaluation if a change is really required.



Page 26 of 67

Three aspects can be seen as success factors not only from change management perspec-tive but also for the whole project.

Start Early

As mentioned before: an early sandbox upgrade provides all the information needed to plan ahead for a full blown technical change management process. This time should be used to determine the real need for change and the best option for its implementation. If time is lack-ing on this stage, the project will end up adjusting anything that pops-up and make it work just as it did before. With several thousand modifications and custom objects, this will cause enormous effort.

Link Change to Test and Training

Upgrade projects, especially for technical upgrade with a small release leap, do not want to test everything and do not want to re-train everybody. But even if "No-Change" is part of the project charter, some changes cannot be avoided. It is then very important to reflect every single bit of these changes in test planning and delta-training.

What about changes to the technical change management itself? In the evaluation phase or on program definition level, it may become apparent that the existing procedures deserve an investment. The change management process is one of the most comprehensive solution support procedures with many people involved in several roles and a sophisticated workflow implemented with a number of tools. The reliability of this process is the first priority. Do not re-assign roles, change the sequence or implement new tools if it is not urgently required. If this has to be done, maybe in order to facilitate the upgrade at all, try to adapt the process as early as possible upfront of the upgrade and let the new scenario be established in day-to-day business some time before the upgrade.

The SAP Solution Manager provides powerful tools to implement the change request man-agement, change impact analysis, test management, the testing itself (eCATT), and eLearn-ing. Details about standards in technical change and test management are outlined in the respective Solution Operations Standard white papers.

Manage the Code Freeze

After the development system has been upgraded, the upgrade project will start implement-ing the adjustments to repository objects of the upgraded system. To maintain the current production environment, we strongly recommend setting up a copy of the development sys-tem in parallel for implementing corrections in the old release. Therefore, as of this point in time, there are two different versions of the same object in the two development systems. Since the productive system is still on the lower release, an event like an urgent correction request or a regular change request has to be mastered. If the correction is just applied to the low-release development system and transported into production, it will get lost as soon as the upgrade of the productive system is supplied with the adjustments from the target-release development system. The only way around this is to apply the same changes twice: once in both development systems (double maintenance period). Most of these changes have to be done manually because customizing transports between different releases are not supported and repository transports are critical (e.g. SAP Note 1090842). It is clear that this procedure is costly and error prone.



Page 27 of 67

To keep this extra effort as small as possible, it is advisable introducing a code freeze for this period of time. This means that no change requests are implemented in the production sys-tem, except for urgent corrections resolving severe issues having a large business impact. In particular, this also means that there should not be any business roll-outs after the develop-ment system upgrade. Even if the respective customizing and coding is already in the devel-opment system before it is upgraded, a go-live of the functions in the double maintenance period will usually hit the upgrade project because normally the same developers are needed for corrections in the stabilization phase of the roll-out business functions, and, of course, any corrections need to be applied twice.

Additionally, also major changes to connected systems should be completely avoided, latest after the start of the integration tests. Otherwise, the results of the tests become spurious.

Frequently, the implementation of a code freeze period is hard to be negotiated and agreed with the business departments. They are normally afraid to lose flexibility for this period of time. That is why such code freeze is better manageable if it is planned and communicated early. Nevertheless, many projects cannot afford having too many weeks of code freeze due to requirements from business side. To limit this time, it is a general best practice to start with the upgrade adjustment already on the sandbox system, when double maintenance is not yet in place. This will save time later after the development system upgrade, in which the pre-pared adjustments can be simply re-applied.

Anyway, you should include representatives of the upgrade project in the change request process for the previous release during the double maintenance period. Experience shows that this is the best way to ensure that the tradeoff between the expected benefits from the requested change and the extra risk and effort for the upgrade are properly taken into ac-count.

Summary

Keep and use your established change management procedures also during your upgrade project. However, include the upgrade project team in the decision process for change requests after start of double maintenance period.

Document any change during the upgrade project. This provides the basis for effi-cient testing and training.

Create a maintenance landscape for your current production environment in parallel to the upgrade project landscape. This will ensure maximum availability for your business.

Implement a strict code freeze period latest after upgrading the development system. This will minimize project efforts for double maintenance and provides a stable land-scape for integration testing.

If possible, start adjustment work and unit testing already in the sandbox upgrade system. This helps reducing the overall duration of the code freeze period.

4.3.5 Data Conversions: Manage Unicode and Data changes

Required data conversion is an activity that can account for considerable preparation and execution effort. The most prominent is certainly the conversion from a non-Unicode to a



Page 28 of 67

Unicode system. While this activity is technically not bound to be executed with the upgrade, many upgrades to SAP Netweaver 7.0 based products (particularly, SAP ERP 6.0) see also Unicode conversion, because MDMP (more than one codepage installed) is not supported by SAP in these releases. Single codepage systems do not have to convert to Unicode in the first place, but SAP's product strategy is committed to Unicode and therefore a conversion cannot be avoided for any system over the long run.

The size and scope of Unicode have made it the default character encoding of the Internet communication, such as XML, Java, and HTML. For more information about Unicode, go to the Unicode Technology Media Center on SAP Service Marketplace http://service.sap.com/unicode@sap and also visit the Unicode Homepage in the public web: http://www.unicode.org/

SAP provides support for Unicode for all products as of Web AS Release 6.20 (see SAP note 79991). Major DB manufacturers support Unicode, and SAP offers Unicode as a system code page on the application server. SAP Note 379940 lists supported hardware configurations. All derivates of SAP GUI support Unicode in addition to all other non-Unicode encodings and languages SAP supports on non- Unicode systems (see SAP Note 73606). Thus only a sin-gle GUI is required to access both Unicode and non-Unicode systems.

The technical conversion is performed during an export of the complete database using R3load. From a business point of view, the time for the conversion is a downtime; its duration depends linear on the database size. The import of the exported data files into a Unicode database concludes the conversion. There are options to combine upgrade and Unicode activities into one project (Twin Upgrade & Unicode Conversion and Combined Upgrade & Unicode Conversion). Minimizing the downtime of both upgrade and Unicode conversion may become a challenge with large databases and small downtime windows (see chapter 4.2.6). For the Unicode part, a minimization of the database size and the parallelization of the con-version process are the main available options for downtime reductions.

In addition to the Unicode conversion, there could also be the need for other application-specific data conversions that are triggered by changes in the applications' data model. The system automatically executes some of these data conversions during the upgrade in the XPRA phase. However, to keep the upgrade runtime as short as possible, other programs have to be started manually in the new system before or after the upgrade. Examples for such conversions can be funds in Funds Management, Treasury or for certain add-ons (e.g. CEE/CIS for Russia). Depending on the volumes in the affected tables, upfront data reduc-tion and the tuning of the transfer are advised. Data consistency checks before and after the conversion help ensuring the overall data integrity in the system.

Most conversion requirements are delivered by SAP at a central location, the ASU toolbox, and it is very much recommended to use the ASU transaction. As additional application-specific conversions might be required, it is recommended to additionally check the relevant SAP documentation.

Summary

A Unicode conversion is a separate project not directly related to an upgrade in the first place. Only R/3 systems using MDMP may need to combine it with the upgrade



Page 29 of 67

when going to ERP 6.0. If possible, try to separate the projects to split business downtime and mitigate project risks.

Get familiar with application-specific data conversion requirements upfront the up-grade project. Use the ASU toolbox for this purpose.

4.3.6 Business Downtime: Minimize System Outage

For sure, downtime is one classic upgrade challenge. For a couple of hours, the productive system is not available for the business. In times of 24x7 businesses, just-in-time production, or continuous production in the process industry, the business cannot shut down. An oil field cannot be stopped because of a software update; the yard of a paper mill would be complete-ly stuffed with tons of paper within a couple of hours; etc. SAP has always strived to find ways to shorten the technical upgrade time. The system switch methodology has improved upgrade times significantly: while the productive system is still up, a second SAP instance is created "in the shadow", which contains the new repository and facilitates a number of up-grade steps, that had to be run during downtime in the past but are today executed in the shadow instance while the regular system is still running.

With transaction Incremental Conversion (ICNV), database operations, which need to be executed during the upgrade because the definition of structure, fields or indexes of a data-base table are changed by the upgrade, can be scheduled to run during uptime. This metho-dology is able to handle the conversion of a complete table while certain entries are still mod-ified, deleted or inserted.

Also, the complete preparation for a Unicode conversion can be combined with the upgrade preparation. This way, the Unicode downtime can follow directly after the upgrade downtime and does not take extra hours for preparation.

However, when looking at business downtime, it is not sufficient to consider only the down-time for the technical upgrade. Today, the average technical downtime for the upgrade is well below 10 hours for almost all WebAS ABAP based servers (independent of DB size, by the way). In comparison, the overall business downtime, measured as the time when the last user logs off until the first user enters the system again, varies between 15 and 84 hours with an average of about 48 hours (without Unicode Conversion). The difference is explained by tasks around the technical upgrade. The most important ones are as follows:

Ramp-down of system (including clearing of inbound/outbound queues)

DB backups

Customer transports (repository objects and customizing)

Language imports

Business Sign-off (including testing)

Ramp-up of system

On top of these actions, Unicode or application-specific data conversions can be necessary.



Page 30 of 67

Usually the upgrade of the productive system is the fourth or fifth upgrade during the project: three upgrades are quasi- mandatory: the development system, quality assurance system, and the productive system. A sandbox upgrade before the start of the project is recommend-ed as well as another test upgrade with a copy of production just before productive cutover. For any of those, two things are very important: write down every single step and action, no matter how insignificant they appear, and keep as many parameters constant as possible. If both rules are followed, every upgrade will run more smoothly than its predecessor. The pro-ductive cutover will be best!

If the tests uncover issues with the runtime of the whole procedure or certain steps or even single tables, an assessment of the complete upgrade phases using a drill- down approach can help identifying optimization potential. In the result file UPANA.htm, for example, always the heaviest time consumers of the technical upgrade are identified and then broken down into their respective pieces. Within a Safeguarding engagement, SAP can support you with a dedicated service that is executed in the SAP Solution Manager. This service would also consider potential optimizations of the Unicode migration.

Attention: in some cases of runtime issues, for example with Unicode conversion or customer transports, the recommended actions may not be applicable within a few days or weeks time-frame (which would be possible with most upgrade related measures). For instance, reducing the total data volume of a SAP system, which is one effective lever for DB size related issues (e.g. data conversions or backups), is usually not achieved in weeks.

For Unicode conversions, another promising way is heavy parallelization of the execution up to the limits of the I/O subsystems of the sender and receiver databases, but this may involve splitting of the largest database tables or hardware investments in application server CPU and local file system or database server CPU.

The time for the import of customer repository objects can be reduced by applying the SAP Customer Based Upgrade procedure (CBU). However, this requires the compilation of specif-ic upgrade DVDs or CDs by SAP and, hence, needs more time for planning and preparation in the project phase.

For customers with extremely high system-availability requirements, SAP offers the near-zero downtime method (see figure 4.5). This method enables you to reduce business downtime to three or four hours for a release upgrade. However, this performance increase is gained at the expense of more temporary hardware investments and project efforts. In the near-zero downtime method, the upgrade is performed on a clone of the production system. During this upgrade, all changes on the production system are logged on the database level. After the completion of the upgrade on the clone, the real downtime begins. During this downtime, data changes from the production system are transferred to the clone. Data transfer is per-formed by a tool based on the migration workbench. The tool also transforms the data struc-ture in case of changes in the data model between the old and the new release. After system validation, the clone takes over the role of the production system.



Page 31 of 67

Recording

PRD

R/3 4.6C

(reduced) uptime

cloned

PRD

Upgrade and Unicode Conversion

PRD

SAP ECC 6.0

Validation,

sign-off

downtime

clo

ne

De

lta re

pla

y

Figure 4.5: Illustration of the near-zero downtime method for ERP

The near-zero downtime method is applicable for other maintenance tasks, such as the ap-plication of SAP support pack stacks, database maintenance, or operating system mainten-ance resulting in greatly reduced system downtime. It should be possible to reduce busi-ness downtime to two or three hours. Regular use of this tool for various maintenance tasks could reduce the complexity related to the near-zero downtime method and could contribute to the general improvement of system availability during the operations. For upgrades, the method has been made available first for ABAP-based SAP ERP. For support package im-plementations, similar methods are also available for SAP NetWeaver EP and PI solutions.

Summary

The business downtime is defined as the overall time a system is not available for the business during change or maintenance events. The technical upgrade downtime is only one part of this business downtime.

Perform a sandbox test upgrade with a copy of the production systems during the preparation or blueprint phase of the upgrade project including all critical tasks like Unicode Conversion or other data conversions. This is the first opportunity to get reli-able estimates for the business downtime.

Agree and decide as early as possible with business what the downtime require-ments are. Only then it is possible to decide what measures need to be taken for downtime optimization and to have enough time to perform the optimization.

In case a Unicode Conversion is done together with the upgrade, plan for two to three test cycles for downtime optimization on separate hardware in parallel to the upgrade project. At least for the final tests take hardware that is comparable to the planned production environment.

The downtime of a technical upgrade does not depend on the overall database size, but only on the size of those tables that are subject to a data conversion (DDIC struc-ture or content). Nevertheless, general archiving or data cleansing activities will be beneficial for data-dependent tasks like backups or Unicode Conversions.



Page 32 of 67

4.3.7 Business Continuity: Avoid Surprises

The ultimate goal of any project is that on "Monday morning" after the upgrade weekend the users can run their business in the same way like on Friday evening before the upgrade. Ideally, they should not experience any differences or difficulties due to the upgrade.

In reality, of course, this goal can only be approached. But what needs to done to approach it as far as possible? At least, you should complete the following tasks to minimize the risk of disruptions, and thus, ensuring maximum business continuity:

Understand the adjustment needs

Define the right test scope

Determine training requirements

Set up a proper cut over plan

Understand the change impact to solution operation

Adjustments

First, you have to understand the change and adjustment requirements introduced by the upgrade and their impact to business. Refer to section 4.2.3 for a detailed discussion of this topic.

Testing

Because of the amount of program code and the complexity of the implemented business logics, one should not assume that a technical analysis of the software alone really ensures maximum business continuity. Particularly, changes in the SAP standard business logic may not be visible in a technical analysis in the first place. Nevertheless, they could lead to se-rious issues, for example, in custom developments. A proper testing is the only way to detect such changes. This is the reason why testing the business applications is usually the key cost driver of upgrade projects.

To limit these efforts, we recommend following the approach described in section 4.2.3: per-form a risk-impact-analysis of your business processes with regard to upgrade and business criticality. This analysis results in a classification of the processes like the following

Class A: have to be tested

Class B: should be tested, if time and resources allow this

Class C: are disregarded; issues will be resolved later as they appear

We recommend end-to-end testing of the business critical core processes anyway, regard-less if they are affected by the upgrade in the first place. Additionally, processes that are strongly impacted by the upgrade (high upgrade criticality) fall in class A as well.



Page 33 of 67

Low High Very

High Upgrade Impact

Low

Medium

Business Criticality

Class B

Class A

Class CVery High

High

1

Medium

Figure 4.6: Classification of test cases

User Training

Besides testing of the processes, end user training is an important measure to ensure busi-ness continuity. Specifically, changed screens, menu paths or new or changed business functions can lead to a wrong handling or leave the end-user in a situation not knowing how to proceed. As a consequence, business performance decreases. This risk is the larger the greater the leap is between source and target release or if the application has been rede-signed on large scale.

However, as for testing, the extent of the training measures has to be carefully determined in order to limit the investments in this area. First, you have to determine the trainings require-ments by identifying those areas with the largest changes to user experience. Second, you should define key users for each of these areas, who receive a full delta training curriculum and may also take part in the integration or acceptance tests. Together with these key users, then the project team has to define the training curriculum for the end users in each critical business area.

Efficient end user training concepts should not only rely on SAP courses or in-house class room trainings. Rather, consider additional training techniques like e-learning sessions or short remote info sessions on special topics. A good documentation of business changes is a key to organize these trainings well. Finally, a special help desk should be set up during the initial stabilization phase after the upgrade to provide swift answers to user questions and problems. Using new Internet communication techniques, like FAQ pages, discussion forums, or Wiki pages through your Intranet will help to efficiently share information among your end users on problems and their solution.

Cut-over Planning

The creation of the cut-over plan is a key milestone on the way to a successful upgrade of the production system. It describes each and every step to be executed by the project team



Page 34 of 67

that are necessary to prepare and conduct the upgrade. The most important building blocks are as follows:

steps for of OS or database version updates,

application-specific preparation tasks

ramp-down of the production system,

upgrade execution,

implementation of customer corrections and additional software packages

tasks for data or Unicode conversions

final baseline tests and business sign off

ramp-up of production system

follow-up tasks in upgraded system

Basis for the cut-over plan is the SAP Upgrade Guide for the specific release combination of the target SAP, OS, and DB soft

Documents

SAP Ugrade Std