Version: 2.0
October 2009
SAP Standard for Upgrade
and Enhancement
Management
Whitepaper
Active Global Support
SAP AG
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 1 of 67
SAP® Standard Upgrade
Change history:
Version
Date
Changes
1.0
April 2007
Original version
2.0
October 2009
Completely updated and revised version
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 2 of 67
SAP® Standard Upgrade
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
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 3 of 67
SAP® Standard Upgrade
1 Management Summary
Managing complexity, risk, costs, skills and resources is at the heart of implementing application 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 4 of 67
SAP® Standard Upgrade
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. SAP‟s ALM portfolio consists of processes, tools, services, and best practices, to manage 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 comprises 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 applications should be used to map the processes.
In the build and test phase, a system landscape is set up and configured to implement 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 system administration, system monitoring, business process monitoring, message
processing (Service Desk), root cause analysis, issue management, and service delivery.
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 management office communicates business requirements to the IT organization, decides on the financing 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 specialization is possible within these organizations. For example, there may be separate experts
for different applications within SAP technical operations, in larger organizations.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 5 of 67
SAP® Standard Upgrade
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 infrastructure, and a clear definition of the collaboration processes, including the activities involved, 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 Solution 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 bestpractices 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 optimize the supportability of customer solutions
Root Cause Analysis defines how to perform root cause analysis, end-to-end, across
support levels and technologies
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 6 of 67
SAP® Standard Upgrade
Exception Handling and Business Process and Interface Monitoring explains how to
define a model and procedures to manage exceptions and error situations during daily 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 safeguards 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 solutions
System Administration describes how to administer SAP technology to run a customer 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 7 of 67
SAP® Standard Upgrade
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 functionality, leverage new technologies that foster innovation, and guarantee long-term protection 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 lifecycle events of its products. Quick links to the respective SAP information sources are provided 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 creation, 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 complexity 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 8 of 67
SAP® Standard Upgrade
Finally, SAP provides tools and services supporting the upgrade projects in all stages. 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 9 of 67
SAP® Standard Upgrade
4 What is the Basic Concept of the Upgrade Management 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 management 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.
Effort
Figure 4.1 outlines the most important change events in the life cycle of your solution.
Discrete
Change
Events
Installation
Customer
Enhancement
Enhancement
Upgrade
Update
Customer
Patch
Update
New
proces
roll-out
Enhancement
Ongoing
Change
Events
Update
Time
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 depending 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 system 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 Solution Manager.
This maintenance process has the aim to correct known errors in applications by minimizing the impact to any existing landscape elements and running processes. Regression tests are needed and non-disruptiveness in user interfaces shall be assured. New
functionality or different behavior of existing processes is not expected.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 10 of 67
SAP® Standard Upgrade
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 Enhancement 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 release.
The concepts of enhancement packages and switches are also the recommended technology for customer enhancements in the future.
4. Upgrade
An Upgrade contains all objects of a software release. The media for this are software releases. 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 previous software is also available within the higher release, which allows a Technical Upgrade 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. Typically, 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 customizing 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 lifecycle 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 company‟s 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 company‟s software landscape on a regular basis. This careful maintenance results in a well-defined, harmonized 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 quality manager is to prevent the introduction of unnecessary modifications or custom development to the software landscape. Keeping custom code to a minimum helps reduce development costs in general and upgrade costs in particular.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 11 of 67
SAP® Standard Upgrade
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 company‟s 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 company‟s own strategic needs, for example, whether there should be stronger
emphasis laid on customer management, integration of supplier systems, or compliance
Operational issues of the existing solutions, like functionality gaps or compatibility issues
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 depending 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 explained in the seven sub-chapters of this section.
If all of these focus topics are properly managed, a successful upgrade should only be a matter 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 Standard 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 systems and databases, SAP products and versions, language support and communication
structure.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 12 of 67
SAP® Standard Upgrade
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 discussed: Technical Infrastructure, Business Solutions, and Solution Operations. The methodology 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 upgrade.
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 considered when looking at the technical infrastructure. Among those, the provider concept, geographical 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 program 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 13 of 67
SAP® Standard Upgrade
For each individual situation, the right balance between risks and costs can only be determined 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 different 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 implemented 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 template 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 dependencies 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 preparation 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 requirements are the main driver for upgrades of a SAP solution. In these cases, an early involvement 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 onboarded 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 successfully 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 14 of 67
SAP® Standard Upgrade
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 potential benefits for operations and implicitly for the upgrade. Some changes may be a precondition 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. Therefore, 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. Dependencies 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 15 of 67
SAP® Standard Upgrade
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 excellence. 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 challenges of this task, which are ensuring the compatibility of all connected software components 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 combinations 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 strategy 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 horizontal stack. In general, different SAP systems can communicate to each other independently 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 dedicated 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 16 of 67
SAP® Standard Upgrade
A special challenge arises if a Unicode conversion is necessary. Here, it has to be guaranteed 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 consideration 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 installation of additional languages in a Unicode-converted system, the data exchange with nonUnicode 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 forgotten. 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 release 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 hardware requirements. Your hardware partner will help to further refine the actual size of all major 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:
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 17 of 67
SAP® Standard Upgrade
100,0%
80,0%
60,0%
40,0%
20,0%
0,0%
Source
Release:
SAP Note:
4.0b
4.5b
4.6b
4.6c
113795
178616
323263
517085
Memory App
Enterprise 1.10 Enterprise 2.00
CPU App
752532
778774
ECC 5.00
901070
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 delta-sizing information from source to target release.
CPU
RAM
+ 5% … 30%
 depending on existing scenario
(MDMP, double byte) and type
of CPU

Database size
Network Load

UTF-8 –
DB/2 (Unix):
+10%2…35%3
 UCS-2 – MaxDB, SQL Server:
+40…60%
 UTF-16 – DB2 (AS400): +10...20%
 UTF-16 – DB2 (zOS): - 20...10%4
ORACLE1,

1
2
3
4

+ 40% … 50%
reason: application servers
are based on UTF-16
internally


UTF-8
almost no change due to efficient
compression
Oracle uses UTF-8 variant called CESU-8
10% is the observed maximum for bigger systems (db size > 200 GB).
35% is the observed maximum in growth for small systems (db size < 200 GB).
SAP Unicode installations on z/OS always use hardware compression which overcompensates the growth due to Unicode;
without compression DB size would increase between 20…60%
Figure 4.3: Average hardware requirements for Unicode Conversions. The numbers are
based on parallel benchmarking of Unicode / non-Unicode test systems.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 18 of 67
SAP® Standard Upgrade
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 different 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 databases 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. Details 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 upgrades 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 19 of 67
SAP® Standard Upgrade
Summary
A compatibility check of all software components and the proper sizing of the hardware 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 requirements, availability of country versions and languages or SAP solution extensions 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 upgrade 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 constellation 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 impact 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 inspected 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- impactanalysis:
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 upgrade.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 20 of 67
SAP® Standard Upgrade
Regarding impact and criticality, just imagine the "Monday morning" after the upgrade weekend: 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 application adaptation along business functionality or business processes and work on the individual 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 before 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 21 of 67
SAP® Standard Upgrade
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 understand 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 modifications 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 extracting 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 upgrade. 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 technology. Another source of problems is the fact that custom code usual contains static or dynamic 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
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 22 of 67
SAP® Standard Upgrade
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 upgrade, there can be changes to SAP standard processes and functions that require adjustments 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. Additionally, we recommend using the Application Specific Upgrade (ASU) toolbox to analyze
changes in the application areas. The ASU Toolbox enables you to recognize additional,
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 23 of 67
SAP® Standard Upgrade
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. reportvariants, 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 authorization 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 account 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 special 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 interface 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 24 of 67
SAP® Standard Upgrade
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 highly 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 possible. This enables you to analyze your system and set the right focus for your adjustment 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 25 of 67
SAP® Standard Upgrade
Three aspects can be seen as success factors not only from change management perspective 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 lacking 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-today business some time before the upgrade.
The SAP Solution Manager provides powerful tools to implement the change request management, change impact analysis, test management, the testing itself (eCATT), and eLearning. 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 implementing 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 system 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 26 of 67
SAP® Standard Upgrade
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 system, 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 development system upgrade. Even if the respective customizing and coding is already in the development 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 prepared 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 account.
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 efficient 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 landscape 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
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 27 of 67
SAP® Standard Upgrade
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 single 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 conversion process are the main available options for downtime reductions.
In addition to the Unicode conversion, there could also be the need for other applicationspecific 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 reduction 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 applicationspecific 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
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 28 of 67
SAP® Standard Upgrade
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 upgrade 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 completely 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 upgrade 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 database table are changed by the upgrade, can be scheduled to run during uptime. This methodology is able to handle the conversion of a complete table while certain entries are still modified, 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 downtime 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 29 of 67
SAP® Standard Upgrade
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 recommended 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 productive 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 timeframe (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 specific 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 performed by a tool based on the migration workbench. The tool also transforms the data structure 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 30 of 67
SAP® Standard Upgrade
(reduced) uptime
PRD
R/3 4.6C
Upgrade and Unicode Conversion
Delta replay
clone
Recording
downtime
PRD
SAP ECC 6.0
Validation,
sign-off
cloned
PRD
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 application of SAP support pack stacks, database maintenance, or operating system maintenance – resulting in greatly reduced system downtime. It should be possible to reduce business 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 implementations, 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 reliable estimates for the business downtime.
Agree and decide as early as possible with business what the downtime requirements 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 structure or content). Nevertheless, general archiving or data cleansing activities will be
beneficial for data-dependent tasks like backups or Unicode Conversions.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 31 of 67
SAP® Standard Upgrade
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 serious 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: perform 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, regardless 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.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 32 of 67
SAP® Standard Upgrade
Business Criticality
Class A
Class B
Very High
Class C
High
1
Medium
Low
Low
Medium
High
Very
High
Upgrade Impact
Figure 4.6: Classification of test cases
User Training
Besides testing of the processes, end user training is an important measure to ensure business 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 redesigned 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 requirements 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
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 33 of 67
SAP® Standard Upgrade
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 software. It contains all critical steps and tasks to complete the
upgrade without errors and ensures that all data is available and consistent in the new release. The Upgrade Guides are regularly updated. They can be found in the Upgrade info
center in the SAP Service Marketplace.
Additionally, the cut-over plan contains all customer-specific tasks required for the release
change. Of particular importance are application-specific tasks that are not part of the standard upgrade procedure. The ASU tool box provides an overview of the most critical steps to
be performed.
Another important topic is the proper ramp-down and ramp-up of the production system in the
custom-specific solution environment. The more interfaces exist, the more complex these
tasks are and, hence, the higher the risk is that something goes wrong. Important questions
to be answered are as follows:
What steps have to be performed in what sequence?
Has a connected system to be shut down as well?
If not, where can the data be temporarily stored and what is the business impact
when loading this data after the upgrade in terms of duration and performance?
Have all documents been analyzed that stay the inbound or outbound queues with an
error status and is it clear how to handle them before or after the upgrade (if still
possible)?
A draft of the cutover plan should be established early in the project and then be refined on a
regular basis based on the experience gained in the project. When the final rehearsal upgrade is carried out at the beginning of the project phase “final preparation for cut over”, your
cutover plan should be available in its near final version. After the final rehearsal upgrade,
only the time intervals in the plan should need an adaptation. With this final update the cutover plan should be ready to support the production system cutover.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 34 of 67
SAP® Standard Upgrade
Solution Operations
A SAP upgrade may affect all areas of solution operations. However, proper solution operations is key for a smooth transition to the new release. Therefore, the current procedures for
daily, weekly, monthly, and annual tasks must be reviewed for actuality and updated as required; and the operation staff has to be trained accordingly. This may include the following
tasks
If new business processes, application components or technologies are implemented
in the course of the upgrade project (functional upgrade), the new parts of the solution need to be integrated into the existing operations concept.
If a hardware, operating system or database software migration is taking place to a
different platform, the system administration and monitoring procedures must be analyzed and updated.
If interface technologies are changed or new interfaces are added, the interface
management concepts and handling procedures need to be inspected and adopted
to ensure performance and stability of the business processes.
A revision of the general security policy is usually required.
End-user support during the initial stabilization phase is the first challenge solution operation
has to handle after the upgrade. Of course, the upgrade project team should provide support
in this phase as well until a formal hand-over to the regular operations team is done. This
phase normally lasts 2-3 weeks. However, it is strongly recommended including the responsible operations team already during the testing and initial stabilization phases to enable
maximum knowledge transfer. This allows the operations team gaining experience on the
new or updated operation procedures early.
Summary
Testing, training and a proper planning of the cut-over activities are key measures to
ensure maximum business continuity.
To limit the efforts for these activities, focus on the things that really matter. This requires that you prioritize your business processes according to their business criticality and that you understand the upgrade impact to the critical business processes as
good as possible.
Use the ASU toolbox for analyzing and preparing your applications for the upgrade.
Do not forget to test and train any changed operation procedures. Wrong system
administration or application support can be as dangerous as user handling errors or
software bugs.
4.4 Protection of Investment: Ensure Solution Upgradeability
A SAP Upgrade to a higher release is a change event that usually happens only once in several years. An upgrade means a massive investment in the IT solution that need to be justified by a solid business case. When looking at the key drivers for costs and risks described in
the previous chapters, you will find that many of them are related to daily operations topics.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 35 of 67
SAP® Standard Upgrade
This means the way how you organize and live your solution operations has a strong impact
on the upgradeability of that solution. Therefore, reviewing and reconsidering these established practices already before the launch of an upgrade project will help reducing or limiting
the upgrade investments and will lead to a faster return on investments.
In this context, the term „upgradeability‟ shall describe the ability to upgrade a SAP solution in
accordance with SAP best practices and standards. Following these standards is the key to
minimize risks and costs. Any deviations from these best practices and standards regarding
the set-up of software, hardware, business processes and operations will usually lead to extra investments when upgrading the solution later on.
For example, modifications and custom code are the main cost drivers of upgrades and, for
that reason, need to be kept to a minimum. Therefore, it is crucial to implement a change
management process that prevents the introduction of unnecessary modifications or custom
developments. This includes regular checks of intended and existing custom development
against standard functionality as well as regular monitoring of the usage of existing custom
developments. The SAP standards for change management and custom development help
you setting up the appropriate processes in your company. An upgrade project is a good
point in time to analyze the existing modifications in your SAP system and analyze if they are
still needed or can be replaced by SAP standard functionality within the course of the Upgrade project.
Another example is test management. Improvements in test environment, test management
or test tools could have a large impact on the bottom line of an upgrade projects' costs. The
SAP Solution Manager, for example, offers a comprehensive test workbench with integration
to the eCATT test tool. The Solution Manager also offers integration with the HP test environment. The SAP standard for test management provides you with all necessary information
on the recommended test management procedures and available tools.
When making such changes to your solution operations procedures, they should be moved in
front of the start of the project as far as possible. This allows establishing the new procedures
or tools before a major project like an upgrade takes place and, hence, providing the benefits
while minimizing potential risks.
Generally, it is recommended performing a review of the upgradeability of the current solution
on a regular basis depending on the number and frequency of changes to your solution operations. Ideally, a first solution operations review should be a part of the initial implementation.
We recommend following the Run SAP methodology for implementing SAP‟s solution operations standards for this purpose. This will ensure best upgradeability of the SAP solution and,
additionally, help you reducing your TCO.
4.5 Get Ready for Innovation: SAP Enhancement Packages
SAP has introduced the concept of enhancement packages as an innovative way to ship new
business functions without requiring a full release upgrade. Enhancement Packages were
first available with SAP ERP 6.0. However, the concept is or will be extended to all business
suite products and SAP NetWeaver.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 36 of 67
SAP® Standard Upgrade
Business Requirements /
System Functionality
Business Requirements /
System Functionality
Traditional SAP Application
Innovation Lifecycle
Business
Requirements
Implementation
= innovation gap
Upgrade
Time
= SAP core (old release)
New SAP Application
Innovation Lifecycle
EHP 1
EHP 2
EHP 3
= innovation gap
= SAP core (new release)
Upgrade as a major business activity every
5-6 years to fulfill business requirements.
Business
Requirements
EHP 4
Time
= SAP core functionality
= EHP functionality
New functionality implemented in digestible
portions via SAP enhancement packages.
Figure 4.7: Improved Application Lifecycle by Enhancement Packages
The principles of the Enhancement Package concept are as follows:
Clear separation of new functions and corrections of existing functions:
SAP enhancement packages only deliver new or improved functionality as a delta
shipment to the respective business suite products (e.g. ERP, CRM). Any corrections or legal changes are shipped by support packages. Software innovations delivered by enhancement packages may include UI simplifications, functional enhancements or enterprise services.
Strict separation of technical installation and the implementation of the new functionality: New business functions are not active unless they are explicitly activated via
the switch-framework. Therefore, there are no UI or process changes for end users
after the pure installation of a SAP enhancement package. However, SAP enhancement packages require defined ERP Support Package Stack.
Note: Enhancement Packages for SAP NetWeaver (ABAP/Java) do practically not
follow this approach. In this case changes become immediately visible with the installation.
Selective installation of enhanced software components:
Only those software components can be selected and updated that are needed to
use a specific business function. All other software components remain unchanged.
Selective activation of business functions:
An explicit activation is possible separately for each business function. However, only
ABAP based functionality use the switch framework.
The installation and subsequent functional roll-outs should be carried out as projects. Best
practices and standards for these projects will be described in a separate SAP operation
whitepaper for Innovation Management.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 37 of 67
SAP® Standard Upgrade
4.5.1 How to Include Enhancement Packages in your Upgrade
SAP introduced enhancement packages to significantly reduce costs and risks of functional
updates in comparison to traditional upgrades. Particularly, the separation of technical installation and functional activation on the one hand and the selective implementation of business
functions on the other hand, allow IT to adopt faster to new innovations and react more flexible to business demands at lower costs of implementation. From a technical point of view, the
enhancement package installation can be compared better with a maintenance activity, like
the implementation of a support package stack, than with a release upgrade (see figure 4.7).
To fully leverage the advantages of SAP Enhancement Packages, we recommend considering a direct upgrade to the latest available Enhancement Package when planning an upgrade. This step would give you also some advantages from a project point of view. You can
save extra downtime required for a separate installation. Additionally, overall testing efforts
can be reduced by the combination.
The main question from IT strategy point of view is how to include enhancement package
installations in the upgrade project. Particularly, a decision of the update scope has to be
made. Generally, the following approaches are possible:
1. Selective installation: Change (install) only what is needed for activating a business function that the business decided to use.
This approach minimizes the risks and efforts for the installation. SAP recommends using
this approach as default for enhancement package installations or updates. Prerequisite
is, however, that business is able to specify the required business functions to be implemented immediately or soon after the installation.
2. Broad installation: Proactively add relevant scope of new functions to be in best shape to
activate further business functions as soon as these are requested by the business.
This approach avoids the need for immediate additional installations of enhancement
packages or parts of it in case that the business experts are not sure if they want to use a
certain functions later on. Thus, a technical installation can be done by IT together with
planned release maintenance activities, for example an upgrade or larger support package implementation, without waiting for a business decision.
Disadvantage of this approach is, however, that any installed technical usage of an enhancement package has also to be updated during subsequent enhancement package
updates because all components in an application system can only consist of one enhancement package level. This can lead to extended, unnecessary adjustment activities
and business downtimes.
3. Complete installation: Install all available functions regardless of their possible usage
later on.
SAP does not recommend following this approach. Note that the installation of an enhancement package is a non-reversible process. Even if the respective business functions are not activated, the enhancement package components cannot be de-installed
later on.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 38 of 67
SAP® Standard Upgrade
Therefore, the decision, which technical usage shall be installed, has to be taken carefully. Anyway, technical usages that will or cannot be used on a system should never be
installed. There is no additional benefit in doing so; however, the efforts for the installation and update of enhancement packages will be maximized.
As part of the stack calculation for the upgrade SAP recommends to include also the selective installation of the required Enhancement Package Functionalities.
4.5.2 Activation of Business Functions
The activation of new business functions requires a business improvement project like for
other functional roll-outs. This project has to be driven, of course, by the business. As first
step, business shall analyze the new functions, for example, in a sandbox system.
Note: The activation of business functions is a non-reversible process. Once activated, the
business functions cannot be switched off again. Therefore, do not use any systems of your
production environment (e.g. development or quality assurance systems) for the first evaluation of new business functions.
The activation of business functions in ABAP systems is controlled by transaction SFW5. The
activation can be saved to a change request and transported through the system landscape.
SAP provides standard test cases for all business functions delivered by the enhancement
packages. This helps reducing the test efforts significantly.
During the activation process, ABAP coding and DIDC objects are activated and generated.
XPRAS, After Import Methods and other data conversion can be performed depending on the
chosen business functions. Therefore, you have to plan for a business downtime during the
activation, at least for those areas that are affected.
A particular challenge arises from the fact that the activation of business functions via the
switch framework currently works only for ABAP-based applications. Java based business
functions are not activated by switches, but are immediately active after the software installation. Therefore, the activation of business functions that require ABAP and Java components
has to be planned very carefully.
In fact, you should not install the Java components of an enhancement package in the solution landscape before the respective business functions are activated in the corresponding
ABAP based backend system. Otherwise, business processes may not work correctly.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 39 of 67
SAP® Standard Upgrade
5 How to Implement the Upgrade Standard?
5.1 Methodology
The suggested upgrade implementation is based on SAP‟s Upgrade Roadmap. The SAP
Upgrade Roadmap has been derived from the more general Accelerated SAP (ASAP) principles that cover the most important aspects and phases of any type of SAP business configuration project. It is a detailed guideline for project leads to control all relevant activities of a
“standard” SAP upgrade. It is available in SAP Solution Manager (in the Implementation /
Upgrade work center and via transaction RMMAIN) and in the SAP Service Marketplace
(http://service.sap.com/upgraderoadmap).
In addition, SAP uses the Application Management Life Cycle described in ITIL (V3) as a
general model to depict the phases of business configuration processes (service.sap.com/alm). One process within the application life cycle management is dedicated to
upgrade management. The Upgrade Roadmap (URM) covers multiple application life-cycle
management (ALM) phases. Figure 5.1 maps the different URM phases to the corresponding
ALM phases.
Figure 5.1: Relation of ALM phases and URM phases
5.2 Sequence of Upgrade Project Activities
5.2.1 Overview
Figure 5.2 shows an overview of the most important upgrade project phases, the major objectives of each phase and key project milestones.
Remark: The overview in figure 5.2 implies that the SAP Upgrade Roadmap mainly focuses
on the execution of the upgrade project in the build phase. Actually, however, it also describes the most important planning tasks as part of the project preparation phase. Nevertheless, in this document these planning tasks, like for example an analysis of new functions and
features, a definition of business requirements and the creation of a business case, have
been moved to the separate phases Upgrade Discovery and Upgrade Evaluation to outline
that the related planning tasks are usually done several month before a project organization
is really set-up.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 40 of 67
SAP® Standard Upgrade
Upgrade Project
completed
Upgrade Project
started
Plan
Upgrade
Discovery
Upgrade
Evaluation
Project
prepared
Minimize costs
and risks of Upgrade Project
Tests
Blueprint Solution
completed
built
completed
Upgrade
Project
Preparation
Document current
solution and set-up
project
Blueprint
Specify implementation
scope and solution
adjustment needs
Operations &
Continuous
Improvement
Upgrade Implementation
Define
strategy
Define Business and IT
requirements
Run
Build
Cutover
prepared
Go-live
Roadmap
Realization
Implement and adjust
solution
Final Preparation
for Cutover
Perform integration
and system tests and
plan cutover
Production
Cutover &
Support
Execute production
system Upgrade &
Support
Figure 5.2: Overview of upgrade project phases
Plan
Build
Upgrade
Discovery
Upgrade
Evaluation
Document
current
Business
Processes and
IT Infrastructure
Create Upgrade
Master Plan
Update Business
and IT Strategy
Create Business
Case
Release Upgrade
Project
Define Business
and IT
Requirements
Update IT
Program
Definition
Obtain
Information
about new
Product Release
Project
Preparation
Create Project
Structure Plan
and Time
Schedule
Plan temporary
and future IT
Infrastructure
Facilitate Delta
Training for
Project Staff
Define Test
Concept
Blueprint
Kick-off Project
Upgrade Project
System (Sandbox)
Define future IT
Infrastructure
Detailed planning
for Upgrade
Process
Perform initial
Business Tests
Design Business
Processes
Start Application
Adjustments
Create Test Plan
Derive Upgrade
Projects Scope &
Goals
Plan End-User
Training and
Documentation
Review Solution
Operation
Concept
Setup temporary
Dev-System for
Maintenance
Realization
Upgrade DEV
System
Complete
Applications
Adjustments
Perform Unit
Tests
Optimize technical
Downtime
Update Solution
Operation
Concept
Prepare
Integration Test
Prepare End-User
Training
Upgrade QAS
Systen
Transports from
DEV’ to QAS’
Perform Main
Integration and
Acceptance Test
Final Preparation
for Cutover
Create Detailed
Cutover Schedule
Production
Cutover
& Support
Upgrade PRD
System
Perform Final
Integration and
System Tests
Final Business
User Acceptance
and Go-Live
Sign-off
Production
Upgrade
End-User Support
after Upgrade
Conduct End-User
Training
Handover to
Production
Operation and
Close Project
Roll-Out
Documentation
Deploy new
Productive
Infrastructure
Facilitated by
Solution Manager
Solution Landscape Directory
Business Process Repository
Solution Docu. Assisstent
Upgrade Roadmap
Upgrade Project
Custom Dev. Manage. Cockpit
Appl. Specific Upgrade Toolbox
Transport Management System
Maintenance Optimizer
Test Management
e-Learning
Service Desk
Figure 5.3: Sequence of tasks in an upgrade project
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 41 of 67
SAP® Standard Upgrade
Additionally, a possible outcome of the planning phase could also be that a release upgrade
is not carried out or postponed to a later time. Therefore, it makes sense to separate these
planning phases from the implementation phase. If you conduct an upgrade project based on
the SAP Upgrade Roadmap, you should regard the planning tasks as prerequisites for the
project that are finally verified in the project preparation phase.
Figure 5.3 outlines the standard sequence of steps that are usually comprised in a technical
upgrade. In the following sub-chapters, the objectives, tasks and deliverables of each phase
is described in more detail.
5.2.2 Planning Phase
5.2.2.1 Upgrade Discovery
Objectives
The goal of the Upgrade Discovery phase is to get an understanding if possible new software
release versions better support your operational and strategic business objectives and requirements.
Tasks
Identify and document current status of business solution
Define Business Requirements
Define IT Requirements
Obtain functional and technical information about new product release
Map requirements to possible target solution(s)
Deliverables
Documentation of existing business processes in a central business process repository
Documentation of software components, hardware and IT infrastructure used in the
solution in a central solution landscape directory.
List of known solution gaps and future business and IT requirements
Documentation of advantages and disadvantages of possible target software release
versions with regard to operational and strategic business and IT requirements
Milestone
There is no standard milestone for this phase.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 42 of 67
SAP® Standard Upgrade
5.2.2.2 Upgrade Evaluation
Objectives
In the Upgrade Evaluation phase you define the target release and the transition roadmap to
the new solution. The project goals and scope are clearly defined and a master project plan
is created. Based on these facts, a business case is calculated and the upgrade project is
decided.
Tasks
Define upgrade scope and goals
Create upgrade master plan
Create business case
Get project approval
Deliverables
Definition of target solution landscape(s) (releases and software components)
Definition of strategic IT requirements that should be accomplished in connection with
an upgrade (e.g. platform changes, hardware exchange, Unicode conversion)
Evaluation of solution transition roadmaps describing pros and cons, decision criteria‟s and final recommendation.
Upgrade master plan for recommended target landscape and transition path including high-level description of required change tasks, infrastructure investments, upgrade strategy, project set-up and project schedule.
Business case providing estimates for upgrade project, change and maintenance
costs of the future landscape as well as a return on investment calculation
Decision memo for project approval by steering committee
Milestone
Upgrade Project Released
When this milestone is reached, all tasks of the discovery and evaluation phases have been
completed. All relevant parties at the corporate level have been involved to define the project
objectives and create and approve the overall business case. Finally, the upgrade project is
decided by the corporate steering board. In case of an approval, a project leader is defined
that takes over responsibility for all further activities of the upgrade implementation phase,
which starts after passing this milestone.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 43 of 67
SAP® Standard Upgrade
5.2.3 Implementation Phase
5.2.3.1 Project Preparation
Objectives
In this phase, you define the project plan and carry out the organizational preparation of the
project to have all human and technical resources in place to kick-off the upgrade project.
Tasks
Create project structure plan and time schedule
Plan temporary and future IT Infrastructure
Facilitate delta training for project staff
Define test concept
Deliverables
Project plan exists describing the project organization with roles, tasks and responsibilities as well as exact timelines, milestones and deadlines
Project resources (internal/external) are nominated and trained
Test focus and framework have been defined
Upgrade project (sandbox) system is prepared for first test upgrade
Milestone
Project Prepared
The end of the project preparation phase is reached when a project plan and organization
has been defined and the project team is ready to start the project work. After passing this
milestone, the project is normally started with a kick-off meeting of all project members.
5.2.3.2 Upgrade Blueprint
Objectives
In this phase, you carry out the detailed planning and design of the new solution. Additionally,
you finally specify the procedure, required resources and timelines for carrying out the upgrade.
Tasks
Upgrade sandbox system
Define future IT infrastructure
Perform detailed planning of upgrade project (based on test upgrade results and
process design)
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 44 of 67
SAP® Standard Upgrade
Define maximum business downtime and specify upgrade strategy and optimization
measures (e.g. archiving, usage of INCV, etc.)
Define maintenance and code freeze strategy during the project
Perform initial business tests
Design business processes
Start application adjustments
Review solution operation concept
Create test plan
Plan end-user training and documentation
Setup temporary maintenance landscape and prepare development system upgrade
Deliverables
Project plan and timelines have been refined
New business processes, process enhancements and replacements of custom developments with the SAP standard are fully specified
Adjustment requirements are specified and all performed adjustment activities
(SPDD, SPAU, custom developments, customizing, etc) are documented
Existing core business processes run in sandbox system without errors, at least for
standard regression test scenarios.
Full documentation of upgrade procedure, issues and problem resolutions exists in
central upgrade script
Documentation and first analysis of technical downtime performed during sandbox
upgrade
Milestone
Blueprint completed
The end of the blueprint phase is reached when the planned business processes to be implemented or upgraded as well as the baseline scope are described and the technical and
integration design of the future solution is completed.
The customer project team, especially the business process owners, proceeds to the readout
of the created business blueprint document that is then approved and signed-off by the customer‟s project management – including project sponsor, steering committee and business
process and IT owners. This sign-off is a formal approval of the blueprint for the SAP upgrade
to proceed to the realization phase. This ensures that all parties have a common understanding of the scope, effort, schedule and outcome of the project, as well as the remaining challenges to overcome.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 45 of 67
SAP® Standard Upgrade
5.2.3.3 Upgrade Realization
Objectives
In this phase, the solution described in the blueprint phase is implemented and tested in a
project environment, which consists of upgraded copies of the development and quality assurance system of the current production environment. The upgrade procedures are optimized and the technical downtime is minimized.
Tasks
Upgrade development system
Freeze development and IT projects that are not part of the upgrade project scope
Set temporary maintenance development system live and start double maintenance
period for emergency corrections in current production system
Complete applications adjustments (in upgraded development system)
Update solution operation concept
Optimize technical downtime
Upgrade quality assurance system
Prepare integration test
Prepare end-user training
Perform main integration and acceptance test
Deliverables
Development system and quality assurance system are upgraded to new release
Double maintenance and code freeze phase for current production environment is in
place
All changes or enhancements to business processes, customizing or custom developments are completed and unit tested in the development system
Core business processes and interfaces are tested in quality assurance system
Updated solution operation tools and procedures are tested in quality assurance system
Open test issues are documented and for each issue an action plan with completion
criteria and upgrade impact description exists.
Business downtime has been optimized to meet target time windows
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 46 of 67
SAP® Standard Upgrade
Milestones
Solution built
The milestone “Solution Built” represents the point in time during the upgrade realization
phase at which all necessary coding, data dictionary or interface adjustments have been
completed and passed a first functional unit test. Additionally, the necessary upgrade delta
customizing has been completed. In case of functional or strategic upgrades, the extensions
and new functionalities have been implemented as well.
When reaching this milestone, the development system has been upgraded and code freeze
period has started.
Integration, performance and system tests completed
The milestone “Integration, Performance, and Systems Tests completed” marks the end of all
test activities. This includes all unit (developer) tests, application, interface, integration and
mass tests as well as all system tests and test upgrades, except a possible final dressrehearsal test. All test results have been documented and issues have been either resolved
or at least addressed. Successfully tested functions are signed-off by business.
At this point in time, the quality assurance system of the production landscape has been upgraded.
5.2.3.4 Preparation for Cutover
Objectives
The goals of this phase are to get the final approval for the upgrade of the production system
by the project steering committee and to prepare this production system upgrade.
Tasks
Define detailed cutover schedule
Define support concept for stabilization phase including additional requirements for
staffing, service level agreements, support processes, escalations paths and support
infrastructure during this phase
Perform final integration and system tests
Sign-off production upgrade by project steering committee and business stakeholders
Conduct end-user trainings
Roll-out documentation
Deploy new productive infrastructure
Start upgrade prepare phase for long running tasks like incremental conversion
(INCV)
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 47 of 67
SAP® Standard Upgrade
Deliverables
Cut over schedule and upgrade script are compiled
Final integration and system tests are completed without issues
Infrastructure is ready for production system upgrade
Milestone
Cutover prepared
The completion of the cutover planning for the production system upgrade is the final milestone before the production system upgrade. All test activities have been completed. Any critical issues have been resolved and documented in the upgrade script. The results and experiences of the tests have been used to create the cutover plan. A (optional) dress rehearsal
test (mock upgrade) has been performed based on this cutover plan. A support and disaster
handling concept for the production cutover and the stabilization phase after the upgrade has
been defined.
As a result of the successful completion of this project phase, the technical upgrade of the
production system is signed-off, which includes the go/no go decision by the steering board
and the confirmation of the cutover plan.
5.2.3.5 Production Cutover & Support
Objectives
The objective of this phase is to upgrade the production system and to ensure that the core
business processes function in the production system landscape.
Tasks
Upgrade production system
Perform final business user acceptance
Release upgraded solution for user operation
Support for the go-live
Handover solution operation to the operating organization
Close project
Deliverables
Production system is upgraded to new release and released for production operation
Standard operating organization resumes responsibility for the solution
Project is finally signed off and closed
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 48 of 67
SAP® Standard Upgrade
Milestones
Start of Production
The milestone “Start of Production” marks the end of the upgrade of the production system
and the final sign-off by the customer‟s project management including project sponsor, steering committee and business process and IT owners. The major goal of this milestone is to
ensure that the core business processes function in the production system landscape. For
this purpose, final acceptance tests by IT and business have been carried out. If the upgraded solution cannot be released, the system landscape has to be restored to the status
prior to the upgrade.
Hand-over to Production
At the project milestone “Hand-over to Production” the solution operation organization resumes responsibility for running the solution. For this purpose, the project team transfers the
solution and the updated administration concept to the operation organization. Prerequisite
for this step is that the upgraded solution runs stable, consistent and with sufficient performance. After this milestone, the project is closed and the project organization dissolved.
5.3 Roles and Responsibilities
Corporate
Update Business and IT
Strategy
Key User
Business
Champs
Release Project
PMO
Appl Mgmt
& Quality Mgmt
Custom
Development
Tech Op/ IT
Identify Current
Business Process and IT
Infrastructure Definition
Define IT Requirements
Define Business
Requirements
Update IT Program
Obtain Information about
New Release
Derive Upgrade Project
Scope & Goals
Create Business Case
Obtain Information
about New Release
Create Master Plan
Obtain Information about
New Release
Create Project Structure
Plan and Time Schedule
Review Custom
Developments
Plan temporary and future
IT Infrastructure
Facilitate Delta Training
for Project Staff
Project Kick-Off
Perform
Initial Business Tests
Upgrade Project System
Plan Upgrade Process
in Detail
Define Future IT Infrastructure
Create Test Plan
Business Process
Design
Business Process Design
Plan End-User Training
and Documentation
Setup Temporary
Maintenance Landscape
Adjust Application and
Perform Unit Tests
Upgrade DEV System
Prepare and Conduct EndUser Trainings
Perform Integration and
Acceptance Tests
Sign-off Applications
Update Solution
Operation Concept
Optimize Downtime
Prepare Integration
Tests
Upgrade QA System
Create Detailed Cutover
Schedule
Perform Final Upgrade Test
Deploy new Productive
Infrastructure
Sign-off Production
Upgrade
Support Business GoLive
Handover to Production
and Close Project
Support Business GoLive
Upgrade PRD System
Figure 5.4: Upgrade project tasks and responsible customer units
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 49 of 67
SAP® Standard Upgrade
Figure 5.4 shows a mapping of the project activities to the organization model defined in the
SAP Solution Operations Standards.
The key organizations and roles involved in the upgrade planning and implementation phases are described in the following to sections.
5.3.1 Roles during Upgrade Planning
Role
Organization
Tasks
Quality Manager for “Protection of Investment”
Application Management / Customer Center of Expertise
- coordinate planning process
Quality Manager for “Business Process Improvements”
Application Management / Customer Center of Expertise
- document solution
Business Stakeholders and
Board representatives
Corporate Management Team
- define corporate strategies
and constraints
- create upgrade master plan
- facilitates collection and definition of business requirements
- approve project
Business Process Champions
Business Units
- define business requirements
IT Architects
SAP Technical Operation and IT
Infrastructure team
- define IT requirements
Program Management Office
- update IT program
Program Manager
- plan infrastructure
- define project scope and
goals
- create business case
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 50 of 67
SAP® Standard Upgrade
5.3.2 Roles during Upgrade Implementation
Role
Organization
Tasks
Project Manager
Business Units or Application
Management
- manage project
Project Quality Manager
Application Management /
Customer Center of Expertise
- responsible for project quality
management
- co-ordinates activities of
CCoE Quality Manager
Project Sponsors & Business
Stakeholders
Corporate Management, Business Units and Program Management Office
- supervise project
Test Coordinator
Business Units or Application
Management
- organize and coordinate integration tests
Training Coordinator
Business Units or Application
Management
- organize and manage user
trainings
Business Process Champions
Business Units
- design business processes
- support test plan definition
- sign-off business changes
Technology Specialist
System Administrator
SAP Technical Operation and
IT Infrastructure teams
- upgrade infrastructure
IT Infrastructure Team
- provide technical upgrade
infrastructure
- minimize technical downtime
- adapt technical system security
Authorization Specialist
Security Team
- adapt authorization concept
Key User
Business Units
- test business processes
- support go-live
Developers
Custom Development Team
- analyze and implement
changes (coding, data model,
customizing)
Interface Experts
Custom Development Team
- analyze and implement
changes to interfaces to legacy
systems
3rd Party Software specialists
Custom Development Team
- analyze and implement
changes to non-SAP software
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 51 of 67
SAP® Standard Upgrade
5.4 Recommended Upgrade Project Landscape
This section gives recommendations on how to set up your system in order to minimize upgrade risks and reduce the code-freeze period.
System landscape
Legend
= new release
Upgrade project
system
UPS
New
Temporary
maintenance
landscape
DEV‟
Old
= Transport route
= System copy
Transfer
changes
QAS‟
Old
Transfer
Double
maintenance
Productive
landscape
= old release
System copy
changes
DEV
New
Transfer
changes
QAS
New
PRD
Old
Figure 5.5: Recommended landscape for a standard upgrade project based on a classical
three-tier transport landscape for the production environment. All systems in the landscape
are connected to the productive SAP Solution Manager.
We distinguish three lines of systems during the project (see Figure 5.5).
Productive landscape:
The productive landscape is the one to be upgraded. It consists of a development
system, a quality assurance (or test) system and the production system. Development and quality assurance systems are used for bulk of upgrade project work.
Temporary maintenance landscape:
This landscape consists of temporary development and quality assurance systems
for the double maintenance phase.
Upgrade project systems:
Usually, this line consists only of the sandbox or upgrade project system, in which the
initial upgrade and functional tests are carried out in the blueprint phase. Later, the
system could also be used for additional upgrade tests, for example, to optimize the
downtime. However, some projects, for example when a Unicode Conversion is done
as well, may require additional temporary upgrade test systems, for example, to perform the vocabulary scan for the Unicode conversion.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 52 of 67
SAP® Standard Upgrade
The systems are created and made available in the following action sequence:
1. Copy production system to a sandbox system.
Advantages to use productions system as source:
- first realistic downtime estimates are possible
- adjustment analysis (SPDD/SPAU, syntax, UCCHECK) focuses objects that are in
production
- test data for first business tests available
Disadvantages:
- higher system resource requirements
- development projects not yet transported cannot be analyzed
- no versions of development objects available for application adjustment
2. Upgrade sandbox system
3. Copy current development system to temporary maintenance development system and
link to current QA system.
4. Upgrade development system in production landscape
5. Copy of production system to temporary maintenance QA system and link to production.
Instead of the production system, also a copy of the current quality assurance system
can be considered. However, since the QA system is usually a copy of production, it is
better to use production as source to have the latest data and configuration available for
the (test) upgrade.
6. QA system in productive landscape is upgraded to new release.
7. Upgrade productive system and link to upgraded development and QA systems
8. Remove temporary maintenance landscape and upgrade project system.
If you have a development system available which contains a good excerpt of data on which
testing of the upgrade can be based (e.g. a system which is loaded from a productive system
using SAP Test Data Migration Server - TDMS), this system could alternatively be used as a
basis for the sandbox copy.
In reality, there are many variations on this simple landscape. Many organizations may have
far more complicated system landscapes due to their business and geographic requirements.
This leads to deviations of the landscape and sequence above depending on your specific
situation and requirements.
Generally, the complexity increases for a system landscape that contains either fewer than or
more than three systems in a transport landscape. Each system adds an additional upgrade,
but having fewer than three systems limits the possibilities for testing and can lead to a less
efficient upgrade.
For example, if you already use a five-tier production landscape with a separate development
and test system for the development of new projects and another development and QA system for corrections of the production system, you need not to create a separate maintenance
landscape during the project. The existing maintenance system can still be used for this pur-
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 53 of 67
SAP® Standard Upgrade
pose, while the project systems can be used for the upgrade project work. However, of
course, after completing the upgrade project work, all five systems of the landscape have to
be upgraded.
In case of NW PI, EP and BI systems or for smaller Business Suite systems, frequently a
two-tier production landscape is used, consisting only of a combined development and quality
assurance system and the production system. Here, the QAS systems in the recommended
project landscape can be omitted as well. However, you should nevertheless set up a sandbox system created from a production copy.
It is obvious that an upgrade project (in fact, an upgrade project often consists of multiple
projects) can require the management of an upgrade rollout program to ensure that all systems in a landscape are correctly and appropriately upgraded. This involves timing and
spending decisions, and last but not least a large amount of coordination.
5.5 Upgrade Project Duration and Timelines
The overall duration of upgrade projects usually varies strongly depending on the specific
conditions of your solution as well as your project goals. Nevertheless, when evaluating customer experiences, some general rules can be derived for the duration of upgrade projects
and its main influencing factors. This is particularly true for ERP upgrades, for which SAP has
built up an Upgrade Experience Database allowing a statistical analysis of customer experiences. The next chapter presents the Upgrade Experience Database and the major findings
that can be drawn from it.
5.5.1 ERP Upgrades Experience Database
The SAP Upgrade Experience Database provides experiences and statistics from completed
upgrade projects. It provides benchmarking data or project statistics from SAP, gathered from
completed upgrades by other customers.
It tracks the following important upgrade aspects:
Additional hardware requirements
Project duration
Business Downtime
Reasons for upgrade
You can use the benchmark data to plan your upgrade and discover how other organizations
experienced the upgrade project, with information gathered in similar upgrades. You access
the upgrade experience database in SAP Service Marketplace at
http://service.sap.com/upgradedb.
5.5.2 Evaluation of Upgrade Experiences
When analyzing the SAP Upgrade Experience Database, a first result regarding project durations and efforts is that minimum and maximum project duration exists for ERP upgrades.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 54 of 67
SAP® Standard Upgrade
The minimum duration is mainly determined by the number of systems in the transport landscape to be upgraded and the number of additional technical tasks like OS or database updates. For a typical 3-tier transport landscape it is about 3-4 weeks. However, such times can
only be achieved if no or only few application adjustment requirements exist and if the business scope of the system is very small. The business scope is mainly defined by the number
of used business scenarios, the number of users and the business volumes.
At the other end of the duration spectrum, we find rarely projects that take longer than 18
months. Even for complex system landscapes for which multiple upgrades are performed,
this period of time is sufficient to accomplish technical upgrades.
Within this timeframe, the project duration mainly depends on the upgrade efforts. The two
main drivers for those efforts are the leap between start and target release versions and the
number of custom developments and modifications.
The reason for the first effort driver is intuitively clear; the older a release is the bigger the
delta is in SAP functionality and user experience. Therefore, the upgrade project efforts and
duration increase with the distance between the start release and the target release. Figures
5.6 and 5.7 show this result for average ERP upgrade projects from releases R/3 4.6c and
R/3 4.7.
Week
1
Project preparation
2
Upgrade Blueprint
3
Upgrade Realization
4
Final preparation for
cutover
5
Go-Live & Support
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
3 weeks
3 weeks
8 weeks
3 weeks
2 w.
Figure 5.6: Average duration of project phases for an ERP Upgrade from R/3 4.6c to ERP
6.0. The average overall duration for the project is 5 months (+/- 2 months). The statistic is
based on 157 customer cases.
For release upgrades from releases older than R/3 4.6c and from ECC 5.0, no reliable statistical data exists. However, the existing data supports the trend above, i.e. upgrades from
ECC 5.0 take less than 4 months on average and releases older than 4.6c take more than 5
months.
Looking at the data for a specific start-target release combination, it can also be seen that the
project duration and efforts depend on the business scope of the system. This correlation can
also be easily understood because the more a system is used; the more it is hit by change
events like upgrades. However, the data also shows that this is actually only valid for comparatively large release jumps. This means that for upgrades to ECC 6.0 this dependency can
be clearly seen for source release on R/3 4.6c or below, but that it vanishes for upgrades
from ECC 5.0 to ECC 6.0.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 55 of 67
SAP® Standard Upgrade
Week
1
Project preparation
2
Upgrade Blueprint
3
Upgrade Realization
4
Final preparation for
cutover
5
Go-Live & Support
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
3 weeks
3 weeks
6 weeks
3,5 weeks
2 w.
Figure 5.7: Average duration of project phases for an ERP Upgrade from R/3 4.7 to ERP 6.0.
The average overall duration for the project is 4 months (+/- 2 months). The statistics is
based on 85 customer cases.
The second major upgrade effort driver is the number of custom developments of any type
(e.g. modifications, custom enhancements or developments in the customer namespace). It
is obvious that the higher this number is, the more efforts have to be spent on adjusting and
testing these developments. Therefore, it is easily possible that 30-50% of the overall upgrade budget is spent for these activities. It is clear that this has also an impact on project
duration, even though the times are not linearly increasing with the efforts because parallelization of work (by more resources) helps to limit the duration.
Other influencing factors of the project duration are activities that have to be done in addition
to the pure technical upgrade. So, the implementation of new functionality or business scenarios certainly can extend the project duration. How much depends on the scope of the implementation. Another factor is the required Unicode Conversion of MDMP systems when upgrading to ERP 6.0. Particularly for systems on R/3 4.6c or below, the average project duration is extended by two months. Single code page system that are converted or MDMP systems on SAP Basis 6.20 and above are affected less.
Finally, of course, the project duration depends on the number of system upgrades that are in
the scope of the project. So, solution landscape upgrades with more than two systems involved also take longer than times shown in the figures 5.6 and 5.7.
5.6 Quality Assurance of Upgrade Projects
Basically, the quality management for upgrade projects shall follow the established general
best practices for quality management of any type project management. One fundamental
concept within these best practices is the introduction of special check or milestone “sign-off”
points called quality gates (also known as Q-gates). At a Q-Gate, the project situation is assessed against an agreed set of quality criteria. It can take place in relation to a milestone
(point in time) or to an important phase of a project. Establishing major quality checkpoints is
a way to
review the status and progress of the open risks and issues identified during and
since the previous Quality Gate
identify new issues and risks
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 56 of 67
SAP® Standard Upgrade
take corrective actions throughout the project life cycle
provide adequate confidence that the deliverables satisfy the given requirements with
regards to quality standards– bring visibility and transparency
reduce the risk of failure
keep the project efforts aligned with the projects targets.
These quality checks of an SAP project are normally scheduled prior to the deadlines for all
major deliverables. The outcome of these timely assessments is an important input for the
customer project stakeholders to evaluate if the criteria to pass a quality gate and proceed to
the next phases are met or not.
Figure 5.8 shows an overview of the standard Q-gates of an upgrade project that could be
used to review the project when reaching the quality gate. It is not obligatory that each single
Q-Gate needs to be executed. Depending on the engagement, some of them may be
skipped.
Milestone and Q-Gate
Other Milestone or important steps
Integration,
Performance &
System Tests
Completed
Q-System
Upgrade
Dev.-System
Upgrade / Start
Code Freeze
Project prepared
Upgrade Project
Released
Blueprint
Completed
Sandbox
Upgrade
Plan
Upgrade
Discovery &
Evaluation
Solution
Built
Start of
Production
Cutover
Prepared
Run
Build
Project
Preparation
Blueprint
Realization
Final
Preparation
for Cutover
Production
Cutover &
Support
Quality
Gates
Figure 5.8: Recommended Q-Gates for upgrade projects
There are three types of results at a Q-Gate:
Green: All deliverables, key activities and documents have been completed and accepted prior to this Gate and “All systems are „Go‟ ”. There is no increase to the risk
of the project
Yellow: Identified documents, key activities or deliverables have either not been
completed or are in the process of being completed or have not been accepted as
satisfactory by the client. With client approval, one can proceed beyond the Q-Gate.
However there is elevated risk to the project and one must proceed with caution.
Client over-ride is recommended to move forward with the project.
Red: One or more critical deliverables or activities have not been completed and/or
have not been completed to the satisfaction of the client. SAP does not recommend
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 57 of 67
SAP® Standard Upgrade
moving forward past the Q-Gate. SAP deems the project to be in high risk category.
Client over-ride is mandated to move forward with the project.
The project quality manager must ensure that all relevant quality gates are part of the project
schedule. Ideally, this role should be assigned to the CCoE quality manager responsible for
protection of investment (see also section 5.3) or another member of the application management team. As a result, the project schedule should be adapted to include relevant Quality Gates and the Resource Plan should take into consideration that the experts must be
made available timely to support the underlying activities.
SAP offers the Safeguarding for Upgrade service to perform or support the project quality
management. In this case, the SAP Technical Quality Manager, established with the Safeguarding for Upgrade engagement, can take over the role of the project quality manager.
5.7 SAP Upgrade Tools
This section introduces the upgrade tools and technology provided by SAP and gives a short
overview of their usage. The technical upgrade tools that are required to perform the actual
upgrade process are introduced first, followed by the tools and methodologies provided in
SAP Solution Manager to manage your upgrade project. Finally, additional SAP tools are
described that support you with special upgrade tasks.
This section is not intended to explain in detail how these tools work – this is explained, for
example, in the SAP ERP upgrade guides, SAP online documentation and SAP Solution
Manager configuration guides.
You should also refer to chapter 4, which explains the usage of the mentioned tools and how
to address and mitigate the main upgrades challenges.
5.7.1 Technical Upgrade Tools
5.7.1.1 SAPup and SAPJup
The program SAPup controls the entire upgrade of ABAP-based SAP systems. SAPJup does
the same for Java based systems. Both programs check the requirements, the import of necessary programs, and the restart of production operation of the system. SAPup and SAPJup
control the upgrade sequentially in phases, where one phase must have ended successfully
before the next one can begin.
The administrator controls the upgrade tools by the SL Controller described in the next section. In the individual phases, SAPup starts various tools, of which the most important ones
are tp and R3trans. You should always use the newest version of these tools in your project.
During the upgrade, SAPup checks the results and creates a series of logs. These logs are
stored in the log subdirectory of the upgrade directory. This subdirectory also contains the
main log file SAPup.log.
In case of a double stack upgrade, synchronization between SAPJup and SAPup ensures the
parallel upgrade of both parts with minimized downtime.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 58 of 67
SAP® Standard Upgrade
For more information on both tools refer to the SAP Upgrade Guides.
5.7.1.2 SL Controller and STDGUI
As of SAP Business Suite 7 based on SAP NetWeaver 7.01 as well as SAP NetWeaver 7.1,
the upgrade is performed using the SL Controller, which replaces the Upgrade Assistant of
previous SAP releases. The SL Controller provides a unified and system-independent user
interface which leads the system administrator through the upgrade.
The administrator controls the upgrade from the corresponding SDT GUI component. The
SDT GUI is the user interface of the SL Controller. Only one user can be in control of the
upgrade at the same time. The SL Controller must be started on the host on which you want
the upgrade process to run. The SDT GUI components can be executed on any other host.
From the SL Controller, you are led through the upgrade in a wizard-like navigation and enter
all required parameters for the upgrade as well as select a technical upgrade option. The SL
Controller does not perform the technical upgrade directly but starts the required utilities for
each phase. It determines automatically the type of system which is being upgraded (ABAP,
JAVA or Dual-Stack) and starts all required tools, checks the results, logs any errors, and
tracks the upgrade process. Thus, the SL Controller simplifies the upgrade procedure.
Figure 5.9: Distribution of Upgrade Assistant components
5.7.1.3 Application-specific Upgrade Toolbox
You can use the Application Specific Upgrade (ASU) toolbox to analyze changes in the application areas. The ASU toolbox enables you to recognize additional, 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. reportvariants, display variant, exist, ...)
Information on necessary customizing settings for new functionalities
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 59 of 67
SAP® Standard Upgrade
Start of reports adjusting your data to the new release that are not part of XPRA's
started automatically during the upgrade
ASU toolbox is integrated with the upgrade GUI through the ASU phase in the upgrade
process. It uses automatically generated task lists providing all required tasks in their optimal
sequence. The ASU toolbox is also integrated with the upgrade project management in SAP
Solution Manager to guide you through manual pre- and post-upgrade activities, including
e.g. direct display of related notes.
Currently the ASU toolbox is only available for the ABAP-based systems. Further information
is available in SAP Note 1000009.
5.7.2 Upgrade Management by SAP Solution Manager
To help you plan and execute your upgrade projects, SAP Solution Manager gives you
access to upgrade road maps, the latest upgrade methodologies, and related tools. You are
supplied with best practices for the functional and technical aspects of upgrading an entire
SAP landscape; documentation on configuration support, testing, and e-learning management; and a service desk. In the following, the most important upgrade relevant SAP Solution
Manager tools and features are described (see figure 5.10).
Figure 5.10: Overview of Upgrade Tools in SAP Solution Manager
5.7.2.1 Work Centers
SAP Solution Manager Work Centers bundle role-based content with task-specific authorizations and a state-of-the-art, Web-based user interface. Work centers deliver all the functionality, components, and tools needed to manage an entire landscape throughout the IT lifecycle. For upgrades, the work center Implementation & Upgrades is available. It provides a
central access to the Solution Manager project management and upgrade relevant tools and
processes grouped by the major Upgrade Roadmap project phases. Additionally, the work
center Change Management provides access to some important tools like the Upgrade Dependency Analyzer.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 60 of 67
SAP® Standard Upgrade
5.7.2.2 Project Management Tools
To enable you to deal with impending bottlenecks quickly and efficiently, it is essential that
you have professional, more transparent project management procedures and a clearly defined project scope. With these in place, you will be able to safeguard your company‟s investments, deploy resources for specific objectives, set priorities, and ensure that everyone
involved in a project communicates well.
SAP Solution Manager‟s role during this phase is to provide you with roadmaps – proven
procedures for project management – and to structure project management activities clearly
using tools such as project administration functions. The basis for upgrade projects is the
SAP Upgrade Roadmap. Additionally, the Run SAP Roadmap should be used for topics related to solution operation.
5.7.2.3 Solution Documentation Tools
To create a baseline for your upgrade project, SAP Solution Manager helps you document
your current IT landscape as well as implement your business processes.
The SAP Solution Manager System Landscape repository, accessed by transaction SMSY or
via the System Landscape Management work center, provides a storage location for your IT
infrastructure. The maintained repository is also the basis for system administration and monitoring tools like EarlyWatch Alert.
The Solution Documentation Assistant in SAP Solution Manager evaluates business
processes on productive systems. It prepares upgrade projects, evaluates new functionality,
and analyzes custom developments. This tool can help you determine what business
processes are used in your production systems and display the results graphically.
The SAP Solution Manager also helps you to draw up a well-defined, transparent conceptual
design (Business Blueprint) for your project in the business blueprint transaction SOLAR01. It
provides valuable support, especially for mapping and documenting the processes with regard to implementation.
5.7.2.4 Solution Browser
The SAP Solution Browser provides detailed delta information for new capabilities and business functions that have been added between two SAP software releases or any of the
available enhancement packages. It also helps identifying their respective business benefits.
The tool can be accessed via the link http://erp.fmpmedia.com/. It is currently provided for
SAP ERP, but will be extended to support the complete SAP Business Suite.
5.7.2.5 Upgrade Dependency Analyzer
The Upgrade Dependency Analyzer (UDA) helps you with analyzing known dependencies
when upgrading technical components in their landscape. It is accessible from the SAP Service Marketplace at the link http://service.sap.com/uda and from the SAP Solution Manager
work center for Change Management. This tool provides dependency information to support
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 61 of 67
SAP® Standard Upgrade
the planning of upgrade projects. It can compare two systems at a time: the one being upgraded versus one other system in the solution landscape. The output is an online dependency statement and an optional reference to an SAP Note. Customers can also provide
their feedback through the tool as well. Additional information can be found in the FAQ on
the site as well.
Note: Be aware that the Upgrade Dependency Analyzer is a high-level planning tool for upgrades; it does not cover all dependencies that are relevant for planning an upgrade.
Therefore, the SAP master and upgrade guides must be consulted upfront in any case. They
refer to specific SAP standard notes which always reflect the most current status regarding
release restrictions.
Additionally, the dependency statement does not generally indicate whether two components
are technically compatible. It refers to upgrade scenarios and is relevant only for functions
that were already in use before the upgrade.
Finally, the upgrade dependency analyzer performs a check on the technical component
level only. It does not provide information at the business process level. Information on business processes is available through the Scenario and Process Component List.
5.7.2.6 Custom Development Management Cockpit
SAP Solution Manager infrastructure empowered by Custom Development Management
Cockpit (CDMC) helps you to centrally leverage the visibility of the SAP changes triggered by
an upgrade or appliance of Support Package and their impacts on your custom developed
solutions. This supports you in optimizing upgrades of these developments and, thus, reducing costs.
The cockpit provides the following functions:
Identification of potentially obsolete objects
Analysis how custom developments are being used
Identification of the impact an upgrade or support package installation may have on
custom developments
Support of the effort calculation necessary for adjusting the custom developments affected by an upgrade or support package installation
Further functions and tools will be successively integrated in the CDMC. This will include
tools for identifying SAP clones and performing similarity analysis of custom programs.
5.7.2.7 Test Management Tools
Once the delta changes and adjustments have been executed, the SAP Solution Manager
helps you plan, execute, and monitor your integrated testing based on your business process
documentation and the delta changes that you selected to be implemented. For this purpose
a number of testing tools are provided:
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 62 of 67
SAP® Standard Upgrade
Test Workbench – This tool helps you to document and to manage your test cases.
SAP Business Process Change Analyzer (BPCA) – This tool analyzes your business
processes by means of application traces. As a result, it provides a list of all technical
objects used in this process (technical "bill of material", T-BOM), including objects
that have been called only dynamically at runtime. Based on this result, a change
analysis can be conducted in case of implementation of support packages, enhancement packages, or customer transports, helping you to identify affected business processes and to create specific test cases for those processes.
SAP Test Acceleration and Optimization (TAO) – SAP TAO is a suite of applications
that provides automated test case creation, system change detection, test data management, reporting and analysis. It includes test cases for the most important business processes and for Industry Solutions.
eCATT – The extended computer-aided test tool allows you to automate the testing
process and to create test data for user acceptance tests.
Additionally, SAP Solution Manager provides access and interfaces to external tools, such as
SAP Quality Center by HP and the SAP LoadRunner by HP.
5.7.2.8 Upgrade Log Monitor
The Upgrade Log Monitor helps you to monitor the progress of your technical upgrade at the
cut over weekend. It extracts information from the upgrade log files at runtime, which can be
used to raise alerts in case of critical events, like errors, warnings or delays in the execution.
eMail or SMS notification can then be sent to arbitrary recipients based on this alerts.
The tool should be used in addition to the SAP Upgrade Assistant or STD GUI, the user interface of the SL Controller. It mainly targets project leaders or support staff who are not permanently involved in the upgrade execution, but still want to be automatically informed in case of
critical events. In addition, it allows the simultaneous monitoring of multiple SAP system upgrades executed in parallel.
The Upgrade Log Monitor is based on the SAP Solution Manager capabilities for business
process monitoring. Within this framework, the technical upgrade has been defined as
“process” with the upgrade phases as “process steps”. There is a set of predefined content
and alerts for the monitor. Additionally, however, the framework allows very flexible the definition of own alerts and monitoring rules. For example, expected phase durations or start and
end times of phases can be entered based on the results of test upgrades and alerts can be
defined in case these timelines are not met.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 63 of 67
SAP® Standard Upgrade
5.7.3 Additional Tools
5.7.3.1 Product Availability Matrix
The Product Availability Matrix (PAM) bundles technical and release planning information on
SAP components for quick reference. You will find information on the availability of SAP
component releases (product versions), maintenance end dates, and upgrade paths, as well
as technical release information (DB-platforms, Java SE-platforms, J2EE engines, operating
systems, languages, countries etc.).
SAP is publishing its PAM on the Service Marketplace (http://service.sap.com/pam).
5.7.3.2 Scenario and Process Component List
The Scenario and Process Component List is a tool available in SAP Service Marketplace
that allows you to flexibly illustrate possible technical realization alternatives for key business
scenarios or processes.
Within the context of an upgrade, the Scenario and Process Component List tool can be used
to:
Find out if all business scenarios are still possible after upgrades
Find out which business scenarios are additionally possible after upgrades or after
adding new components
For more details, see the SAP Service Marketplace at http://service.sap.com/scl.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 64 of 67
SAP® Standard Upgrade
5.8 Upgrade Information Sources
Getting Started
Topic
Information Sources
SAP Upgrade Infocenter
http://service.sap.com/upgrade
SAP Upgrade News
http://service.sap.com/upgrade-news
Introduction to Release Upgrades
https://www.sdn.sap.com/irj/sdn/upgradetech
ERP Upgrade in the SAP Community
Network
SAP ERP Upgrade Wiki:
https://wiki.sdn.sap.com/wiki/display/ERP6/SAP+E
RP+6.0+Upgrade
SAP ERP Upgrade Forum
https://forums.sdn.sap.com/forum.jspa?forumID=250
Overview and details of SAP ERP Upgrades
http://service.sap.com/upgrade-erp
SAP Enhancement Packages
SAP ERP:
http://service.sap.com/erp-ehp
SAP NetWeaver:
https://www.sdn.sap.com/irj/sdn/nw-mainreleases >
choose NW 7.0 (or later) > enhancement packages
Delta training and workshops for SAP
ERP
SAP ERP course finder:
http://sap.com/services/education/catalog/erp/coursef
inder.epx
Trainings for Technical Upgrade Management
General link to SAP NetWeaver trainings:
http://www.sap.com/services/education/catalog/netw
eaver/index.epx
Path: Components > System Administration > Cross
Component Role: General Administration >
ADM326 – SAP ECC Upgrade
Path: Tools and Methodology > End-to-end (E2E)
solution operations > E2E400 - Technical Upgrade
Management
Upgrade Roadmaps and Best Practices
Topic
Further Information Sources
Upgrade project plan, standards and
guidelines
SAP Upgrade Roadmap:
Upgrade-related guidelines and best
practices for Solution Operation
Run SAP Roadmap:
SAP Standards for Solution Operations
http://service.sap.com/supportstandards
© 2009 SAP AG
http://service.sap.com/upgraderoadmap
http://service.sap.com/runsap
Upgrade and Enhancement Management
Version: 2.0
Page 65 of 67
SAP® Standard Upgrade
Planning an Upgrade Project
Topic
Information Sources
SAP Maintenance strategy
http://service.sap.com/maintenance
Technical prerequisites and limitations
Product availability matrix:
http://service.sap.com/pam
Unicode conversion
http://service.sap.com/unicode
http://service.sap.com/unicode@sap
Availability of country versions
http://service.sap.com/localization
Compatibility issues with other SAP
applications, business scenarios and
processes
SAP scenario and process component list:
Dependencies in your application landscape when upgrading a system
Upgrade dependency analyzer:
http://service.sap.com/uda
Benchmark information for project duration, project effort, and so forth for preparing upgrade project cost and effort
estimation
SAP upgrade experience database:
http://service.sap.com/upgradedb
Media library in the Upgrade Information Center containing useful presentations, e-learnings, customer testimonials,
and much more
http://service.sap.com/upgrade
http://service.sap.com/scl
Media Library
Executing an Upgrade Project
Topic
Information Sources
Upgrade Guides
http://service.sap.com/instguides
SAP Solution Manager
http://service.sap.com/solutionmanager (general)
Solution Manager Tools for Upgrade
Application server resizing
http://www.service.sap.com/sizing
Application Specific Upgrade toolbox
http://service.sap.com > ASU
Testing SAP solutions
http://service.sap.com/testing
SAP Upgrade Services
Topic
Information Sources
SAP Upgrade Service Portfolio
http://service.sap.com/upgradeservices
SAP Enterprise Support
http://service.sap.com/enterprisesupport
SAP Safeguarding for Upgrade
http://www.service.sap.com/safeguarding
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 66 of 67
SAP® Standard Upgrade
Copyright 2009 SAP AG. All Rights Reserved
All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business
ByDesign, and other SAP products and services mentioned herein as well as their respective
logos are trademarks or registered trademarks of SAP AG in Germany and other countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal
Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services
mentioned herein as well as their respective logos are trademarks or registered trademarks
of Business Objects S.A. in the United States and in other countries.
Business Objects is an SAP company.
All other product and service names mentioned are the trademarks of their respective
companies. Data contained in this document serves informational purposes only.
National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP
AG and its affiliated companies (“SAP Group”) for informational purposes only, without
representation or warranty of any kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group products and
services are those that are set forth in the express warranty statements accompanying such
products and services, if any. Nothing herein should be construed as
constituting an additional warranty.
This document is not subject to your license agreement or any other agreement with SAP.
SAP has no obligation to pursue any course of business outlined in this document or to
develop or release any functionality mentioned in this document. This document and
SAP's strategy and possible future developments are subject to change and may be
changed by SAP at any time for any reason without notice.
© 2009 SAP AG
Upgrade and Enhancement Management
Version: 2.0
Page 67 of 67