SAP Standard for Upgrade and Enhancement Management

Transcription

1 October 2009 SAP Standard for Upgrade and Enhancement Management Whitepaper Active Global Support SAP AG Page 1 of 67

2 Change history: Version Date Changes 1.0 April 2007 Original version 2.0 October 2009 Completely updated and revised version Page 2 of 67

3 Table of Content 1 MANAGEMENT SUMMARY SAP STANDARDS FOR E2E SOLUTION OPERATIONS UPGRADE STANDARD AT A GLANCE WHAT IS THE BASIC CONCEPT OF THE UPGRADE MANAGEMENT STANDARD? SOLUTION CHANGES ALONG THE APPLICATION LIFE CYCLE UPGRADES MANAGEMENT IN THE APPLICATION LIFE CYCLE KEY FOCUS AREAS OF UPGRADES Program Definition: Align Upgrades with Corporate Strategy IT Infrastructure Planning: Ensure Compatibility and Capacity Application Adaptation: Understand Adjustment Requirements Technical Change Management: Manage parallel changes Data Conversions: Manage Unicode and Data changes Business Downtime: Minimize System Outage Business Continuity: Avoid Surprises PROTECTION OF INVESTMENT: ENSURE SOLUTION UPGRADEABILITY GET READY FOR INNOVATION: SAP ENHANCEMENT PACKAGES How to Include Enhancement Packages in your Upgrade Activation of Business Functions HOW TO IMPLEMENT THE UPGRADE STANDARD? METHODOLOGY SEQUENCE OF UPGRADE PROJECT ACTIVITIES Overview Planning Phase Implementation Phase ROLES AND RESPONSIBILITIES Roles during Upgrade Planning Roles during Upgrade Implementation RECOMMENDED UPGRADE PROJECT LANDSCAPE UPGRADE PROJECT DURATION AND TIMELINES ERP Upgrades Experience Database Evaluation of Upgrade Experiences QUALITY ASSURANCE OF UPGRADE PROJECTS SAP UPGRADE TOOLS Technical Upgrade Tools Upgrade Management by SAP Solution Manager Additional Tools UPGRADE INFORMATION SOURCES Page 3 of 67

4 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. Page 4 of 67

5 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 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. Page 5 of 67

6 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 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 Page 6 of 67

7 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. Page 7 of 67

8 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. Page 8 of 67

9 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. Page 9 of 67

10 Effort 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. Figure 4.1 outlines the most important change events in the life cycle of your solution. Installation Update Customer Enhancement Customer Patch Upgrade Enhancement Update New proces roll-out Enhancement Update Time Time Discrete Change Events Ongoing Change Events 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. Page 10 of 67

11 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. Page 11 of 67

12 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 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. Page 12 of 67

13 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. Page 13 of 67

14 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. Page 14 of 67

15 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: Summary Which tools have been deployed? Are there intensions or requirements to add or change some? Are there known scenarios where investments are required? 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. Page 15 of 67

16 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 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 ( 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 this tool provides dependency information to support the planning of upgrade projects. Page 16 of 67

17 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 non- Unicode systems need careful analysis. Additionally, the compatibility with non-sap software and peripheral equipments like printers or fax machines is a critical aspect that is often 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 ( 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: Page 17 of 67

18 100,0% 80,0% 60,0% 40,0% 20,0% 0,0% Source Release: SAP Note: 4.0b 4.5b 4.6b 4.6c Enterprise 1.10 Enterprise 2.00 ECC Memory App CPU App Disk DB Figure 4.2: Average total increase in hardware consumption for upgrades from the source release to SAP ERP 6.0. Note: The SAP notes provided in the figure only contain delta-sizing information from the respective source release to the next release. The shown total increase is the sum of all delta-sizing information from source to target release. CPU + 5% 30% depending on existing scenario (MDMP, double byte) and type of CPU RAM + 40% 50% reason: application servers are based on UTF-16 internally Database size UTF-8 ORACLE 1, DB/2 (Unix): +10% 2 35% 3 UCS-2 MaxDB, SQL Server: % UTF-16 DB2 (AS400): % UTF-16 DB2 (zos): % 4 Network Load UTF-8 almost no change due to efficient compression 1 Oracle uses UTF-8 variant called CESU % is the observed maximum for bigger systems (db size > 200 GB). 3 35% is the observed maximum in growth for small systems (db size < 200 GB). 4 SAP Unicode installations on z/os always use hardware compression which overcompensates the growth due to Unicode; without compression DB size would increase between 20 60% Figure 4.3: Average hardware requirements for Unicode Conversions. The numbers are based on parallel benchmarking of Unicode / non-unicode test systems. Page 18 of 67

19 All of the values in Figure 4.3 are average values. Also refer to SAP note 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 ( 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 Business Downtime: Minimize System Outage for details. Performance Optimization Many transactions can be speed up by small adjustments to the customizing scenario, the coding, or the way the database is accessed. If there are a few transactions that dominate the total system load, having a look at their optimization options may result in a considerable reduction of the system load before the upgrade. In the end, hardware additions may even be avoided if the performance optimization was successful. Page 19 of 67

20 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 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. Page 20 of 67

21 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. Page 21 of 67

22 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 Page 22 of 67

23 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, Page 23 of 67

24 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. Page 24 of 67

25 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 Technical Change Management: Manage parallel changes For a system in continuous improvement phase, most organizations have a comprehensive procedure in place to manage changes: the requirements are evaluated, there is a workflow for decisions making, implementation, testing, and deployment. The reason to have such a mechanism in place is first, to perform an assessment if the final value of a realized change exceeds its implementation effort and second, to minimize the potential impact including side effects on the rest of the solution. It is very important not to compromise any aspect of this process in the course of an upgrade. A project could be tempted to allow mass exceptions from the set of rules because there are usually many changes that have to be implemented in a short period of time and because there is often not enough time for a thorough evaluation if a change is really required. Page 25 of 67

26 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 ). It is clear that this procedure is costly and error prone. Page 26 of 67

27 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 Data Conversions: Manage Unicode and Data changes Required data conversion is an activity that can account for considerable preparation and execution effort. The most prominent is certainly the conversion from a non-unicode to a Page 27 of 67

28 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 and also visit the Unicode Homepage in the public web: 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 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 Page 28 of 67

29 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 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. Page 29 of 67

30 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. Page 30 of 67

31 Delta replay clone SAP Standard Upgrade PRD R/3 4.6C (reduced) uptime downtime Recording PRD SAP ECC 6.0 cloned PRD Upgrade and Unicode Conversion Validation, sign-off 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. Page 31 of 67

32 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: Adjustments 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 First, you have to understand the change and adjustment requirements introduced by the upgrade and their impact to business. Refer to section 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. Page 32 of 67

33 Business Criticality Class A Class B Very High Class C High Medium 1 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 Page 33 of 67

34 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. Page 34 of 67

35 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. Page 35 of 67

36 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. Page 36 of 67

37 Business Requirements / System Functionality Business Requirements / System Functionality SAP Standard Upgrade Traditional SAP Application Innovation Lifecycle New SAP Application Innovation Lifecycle Business Requirements Business Requirements Implementation Upgrade Time EHP 1 EHP 2 EHP 3 EHP 4 Time = innovation gap = SAP core (old release) = innovation gap = SAP core functionality = SAP core (new release) = EHP functionality Upgrade as a major business activity every 5-6 years to fulfill business requirements. 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. Page 37 of 67

38 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. Page 38 of 67

39 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 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. Page 39 of 67

40 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 ( 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 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. Page 40 of 67

41 Upgrade Project started Upgrade Project completed Plan Build Run Upgrade Discovery Upgrade Evaluation Upgrade Implementation Operations & Continuous Improvement Define Business and IT requirements Define strategy Minimize costs and risks of Upgrade Project Project prepared Blueprint completed Solution built Tests completed Cutover prepared Go-live Upgrade Roadmap Project Preparation Blueprint Realization Final Preparation for Cutover Production Cutover & Support Document current solution and set-up project Specify implementation scope and solution adjustment needs Implement and adjust solution Perform integration and system tests and plan cutover Execute production system Upgrade & Support Figure 5.2: Overview of upgrade project phases Plan Build Upgrade Discovery Upgrade Evaluation Project Preparation Blueprint Realization Final Preparation for Cutover Production Cutover & Support Document current Business Processes and IT Infrastructure Update Business and IT Strategy Define Business and IT Requirements Update IT Program Definition Obtain Information about new Product Release Derive Upgrade Projects Scope & Goals Create Upgrade Master Plan Create Business Case Release Upgrade Project Create Project Structure Plan and Time Schedule Plan temporary and future IT Infrastructure Facilitate Delta Training for Project Staff Define Test Concept 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 Plan End-User Training and Documentation Review Solution Operation Concept Setup temporary Dev-System for Maintenance 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 Create Detailed Cutover Schedule Perform Final Integration and System Tests Sign-off Production Upgrade Conduct End-User Training Roll-Out Documentation Deploy new Productive Infrastructure Upgrade PRD System Final Business User Acceptance and Go-Live End-User Support after Upgrade Handover to Production Operation and Close Project 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 Page 41 of 67

42 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 Planning Phase 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 Deliverables Milestone 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) 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 There is no standard milestone for this phase. Page 42 of 67

43 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 Milestone 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 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. Page 43 of 67

44 5.2.3 Implementation Phase 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 Deliverables Milestone Create project structure plan and time schedule Plan temporary and future IT Infrastructure Facilitate delta training for project staff Define test concept 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 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 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) Page 44 of 67

45 Deliverables Milestone 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 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 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. Page 45 of 67

46 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 Deliverables 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 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 Page 46 of 67

47 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 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) Page 47 of 67

48 Deliverables Milestone Cut over schedule and upgrade script are compiled Final integration and system tests are completed without issues Infrastructure is ready for production system upgrade 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 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 Deliverables 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 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 Page 48 of 67

49 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 Update Business and IT Strategy Corporate Release Project Key User Business Champs Define Business Requirements Obtain Information about New Release PMO Update IT Program Derive Upgrade Project Scope & Goals Create Business Case Appl Mgmt & Quality Mgmt Identify Current Business Process and IT Infrastructure Definition Create Master Plan Create Project Structure Plan and Time Schedule Facilitate Delta Training for Project Staff Custom Development Obtain Information about New Release Review Custom Developments Tech Op/ IT Define IT Requirements Obtain Information about New Release Plan temporary and future IT Infrastructure Perform Initial Business Tests Project Kick-Off Plan Upgrade Process in Detail Upgrade Project System Define Future IT Infrastructure Business Process Design Create Test Plan Business Process Design Setup Temporary Maintenance Landscape Plan End-User Training and Documentation Adjust Application and Perform Unit Tests Upgrade DEV System Update Solution Operation Concept Optimize Downtime Perform Integration and Acceptance Tests Prepare and Conduct End- User Trainings Sign-off Applications Sign-off Production Upgrade Prepare Integration Tests Create Detailed Cutover Schedule Upgrade QA System Perform Final Upgrade Test Deploy new Productive Infrastructure Support Business Go- Live Handover to Production and Close Project Support Business Go- Live Upgrade PRD System Figure 5.4: Upgrade project tasks and responsible customer units Page 49 of 67

50 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 Roles during Upgrade Planning Role Organization Tasks Quality Manager for Protection of Investment Quality Manager for Business Process Improvements Business Stakeholders and Board representatives Business Process Champions Application Management / Customer Center of Expertise Application Management / Customer Center of Expertise Corporate Management Team Business Units - coordinate planning process - create upgrade master plan - document solution - facilitates collection and definition of business requirements - define corporate strategies and constraints - approve project - define business requirements IT Architects SAP Technical Operation and IT Infrastructure team - define IT requirements - plan infrastructure Program Manager Program Management Office - update IT program - define project scope and goals - create business case Page 50 of 67

51 5.3.2 Roles during Upgrade Implementation Role Organization Tasks Project Manager Business Units or Application Management Project Quality Manager Application Management / Customer Center of Expertise Project Sponsors & Business Stakeholders Test Coordinator Training Coordinator Corporate Management, Business Units and Program Management Office Business Units or Application Management Business Units or Application Management - manage project - responsible for project quality management - co-ordinates activities of CCoE Quality Manager - supervise project - organize and coordinate integration tests - organize and manage user trainings Business Process Champions Business Units - design business processes Technology Specialist SAP Technical Operation and IT Infrastructure teams - support test plan definition - sign-off business changes - upgrade infrastructure - minimize technical downtime System Administrator IT Infrastructure Team - provide technical upgrade infrastructure - 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 Page 51 of 67

52 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 Upgrade project system UPS New System copy Legend = new release = old release = Transport route = System copy Temporary maintenance landscape Double maintenance DEV Old Transfer changes QAS Old Transfer changes Productive landscape 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. Page 52 of 67

53 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- Page 53 of 67

54 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 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 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. Page 54 of 67

55 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/ Week Project preparation 3 weeks 2 Upgrade Blueprint 3 weeks 3 Upgrade Realization 8 weeks 4 Final preparation for cutover 3 weeks 5 Go-Live & Support 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. Page 55 of 67

56 Week Project preparation 3 weeks 2 Upgrade Blueprint 3 weeks 3 Upgrade Realization 6 weeks 4 Final preparation for cutover 3,5 weeks 5 Go-Live & Support 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 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 Page 56 of 67

57 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 Upgrade Project Released Project prepared Sandbox Upgrade Dev.-System Upgrade / Start Code Freeze Blueprint Completed Integration, Performance & System Tests Completed Q-System Upgrade Solution Built Cutover Prepared Start of Production Plan Build Run Upgrade Discovery & Evaluation 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 Page 57 of 67

58 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 Technical Upgrade Tools 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. Page 58 of 67

59 For more information on both tools refer to the SAP Upgrade Guides 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 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 Page 59 of 67

60 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 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 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. Page 60 of 67