SAP Upgrade – Key points to remember

Purpose of this blog
Purpose of this blog is to highlight why customers across industry need SAP ERP upgrades & how effectively these upgrade projects can be executed. This document also covers actual upgrade experience of customer XYZ Corp.
Why upgrade
In response to today’s competitive business pressures, companies now need to be innovative and adaptable to changing ways of doing business, collaborating more closely with customer and suppliers to streamline the value chain. At the same time, organisations are seeking greater efficiency from their core processes, through standardisation, automation and internal integration. These operational drivers must be achieved while at the same time maintaining stability and reducing total cost of ownership. MySAP ERP and various SAP New dimensional products have evolved to meet these changing requirements. Powered by SAP NetWeaver, The SAP products provide an open integration and application platform that aligns people, information, and processes to facilitate external integration with business partners through Enterprise Services and operational efficiency within the organisation through self-services and improved analytics. The SAP upgrade can deliver significant benefit if managed properly. For example, MySAP ERP offers greater functionality compared to SAP R/3 but the additional NetWeaver components that may be required to support this new functionality means that customers have a lot more to consider when planning an upgrade. Upgrade Approaches for the “Go-To-Release”
It is recommended to create and evaluate your own upgrade roadmap, considering the whole spectrum of SAP solutions. It’s very important to define business justification first, however you can start with small technical upgrade only.Customers can adopt any of these approaches for upgrades.
• Strategic Business ImprovementFocus on functionality extension and improvementEnablement of new and optimized business processes and scenarios based on new ERP core functionality
• Functional/Retrofit UpgradeNew functionality to be implemented as part of the upgrade, modification clearingFocus on reduction of system complexity
• Technical UpgradeFocus on pure technology upgradeRetain functionality usedReview Usage of custom developments
How do we start – The first steps
The key to successful upgrade project is planning; ensure you collect as much information as possible. The information has to be studied both by functional and technical team, and then the team can start working on a pre-upgrade checklistYou can start making pre-upgrade checklist after you have captured all system information. The upgrade questionnaire created by Basis team is a good starting point
Technically speaking upgrades essentially consists of version upgrades of one or more components like Operating system, database and SAP software. You may need to upgrade only SAP or upgrade all the three components together. You can verify this from Platform availability matrix of SAP, which lists the availability of SAP components on various OS/DB combinations.(https://service.sap.com/pam )It is recommended that you plan upgrade of each component OS, DB & SAP separately, so as to minimize the system down situation; this will also help in identifying & troubleshooting the real cause of system down.Therefore schedule these activities separately in your project plan.
You must check following for making pre-upgrade checklist
• SAP Solution browser toolThis tool enables field to help customers learn about new capabilities introduced between R/3 and SAP ERP versionsIt helps customers to identify the value proposition of an upgrade to SAP ERPURL: http://solutionbrowser.erp.sap.fmpmedia.com/
• SAP Upgrade Experience DatabaseThe SAP Upgrade Experience Database provides experiences/statistics ofcompleted upgrade projects. The SAP Upgrade Experience Database includes the following upgrade aspects:1. Additional hardware requirements2. Project duration3. Business Downtime4. Reasons for upgrade, etc.
• Platform Availability Matrix (PAM)OS/Database DependenciesCheck the Product Availability Matrix (PAM) to determine if any upgradesare required to the OS or RDBMS (http://service.sap.com/pam ) while upgrade - Upgrade strategy
• Unicode ComplianceUnicode is the “master-codepage“Acting in global business requires Support of a Global Character Set!Companies running global business processes like Global HR SystemsCompanies offering Web Services to their customers: Global Master Data containing multiple local language characters!Companies using Open Standards: J2EE and .NET integration
• Hardware sizing – resizingCustomer & consulting partner need to work along with hardware partner to verify if the present hardware meets the expected workload post SAP upgrade, if it doesn’t than start the delta hardware sizing exercise as early as possible.
What Happens During an SAP System Upgrade – Technical perspective?
An upgrade updates an existing R/3 System to a new release. An upgrade has to take into account the data in the customer system, and various dependencies on external resources. There are two basic strategies for upgrading the R/3 System: the Repository Switch Upgrade (standard procedure up to mySAP Technology Rel. 4.6D) and the System Switch Upgrade (standard since mySap Technology Rel. 6.10). In both cases, the system is divided into the following technical types of data: • Customer data • Control data • Language data • SAP Repository • SAP Kernel Customer Data is the area in which customer data is stored. SAP does not modify the contents of the tables. However, the structures of the tables may be modified by developments to the SAP System, meaning that structure conversions have to be made. This may be challenging if the customer tables contain a lot of data. Some application tables can contain hundreds of gigabytes of customer data.Control Data is the area in which various SAP System control data is stored. Customer data and SAP data is often merged in this area. An upgrade merges data from SAP with existing customer data.Language Data contains language-specific data. The SAP Systems are multilingual and can contain several different languages in parallel. In the upgrade, the language tables are supplemented according to the needs of the customer. English and German are imported as standard languages. Customer data and SAP data are also merged in the language tables. The upgrade must take this into account.The SAP Repository contains all central objects of the R/3 System. The Repository consists physically of approx. 80 database tables and contains the following objects: • ABAP Dictionary objects • ABAP source code and ABAP load modules • GUI descriptions, GUI load modules • Messages • Documentation • Other object types The customer repository is integrated into the SAP Repository. During the Upgrade the entire Repository is switched by replacing all Repository tables and their contents. Before the switch is made, all modifications and customer repository objects are copied into the new Repository.The SAP Kernel contains all kernel programs. In contrast to the previous categories, the SAP Kernel is not located in the database, but at the operating system level. Customers cannot modify the kernel. This means that the kernel upgrade is a simple switch of programs at file level.
The system switch upgrade
• Upgrade with a Shadow InstanceThe new, patented System Switch Upgrade is available for upgrades to SAP Components that are based on SAP Web Application Server 6.10 or higher. The System Switch Upgrade ensures short downtime especially for systems that have been modified extensively and for upgrades that include a large number of Support Packages.
• General ProcedureDuring the upgrade, a second instance, called shadow instance is installed in the same database as the production system. This instance adjusts the delivered target release software during production operation, to the requirements of customer modifications and Support Packages. This shadow system deals with the software of the target release and is used to integrate Support Packages and add-ons that are included in the upgrade, and customer modifications into the target release while the system is still live. The customer is therefore able to perform the modification adjustment for DDIC objects during uptime in the shadow system. The referential integrity of the DDIC objects can then be restored afterwards using the mass activation program.Former restrictions due to the need of using source release upgrade tools and programs are therefore eliminated
Upgrade strategies for SAP software
Downtime-minimized or Resource-minimized
If you are upgrading with the System Switch Upgrade procedure, SAP provides you with two upgrade strategies: the downtime minimized strategy and resource minimized strategy. Choose the strategy that is best suited to your SAP System and to your requirements concerning system availability. Your decision depends on two factors: • Maximum permitted downtime • System resources Comparing the two strategies
Downtime-minimized
Resource-minimized
Parallel operation of production system and shadow system
Higher demand on system resources
Shorter downtime
Import of the substitution set into the shadow tables during production operation
Modification adjustment of the ABAP Dictionary objects during production operation
Activation and distribution during production operation

Operation of production and shadow system only possible independently of each other
Production operation stops before import of substitution set into shadow tables or, at the latest, before shadow instance is started for first time
Short downtime
Medium amount of space required if you need to recover the database
No additional system resources during upgrade
No additional space requirements for enabling possible database recovery
Disk capacity for a possible database recovery is not monitored
Increased demand on system resources due to parallel operation of production and shadow system
No offline backup required after upgrade if archiving deactivated at some stage
Disk capacity for a possible database recovery is monitored
Long downtime
Offline backup required after upgrade
What tools are used during upgrade and how they affect overall plan?
Easy-to-Use Tools for a Smart Upgrade ProcessSAP provides you with a range of high performance tools to help you with all activities before, during, and after the upgrade. In many phases the upgrade can run without user input since it is almost fully automated.
Complete Preparation of the Upgrade Using PREPAREThe Prepare program automatically makes most of the checks that are required before an upgrade. It checks the prerequisites for an upgrade during production operation, imports tools into your database, and copies data and programs to the upgrade directory. The results of Prepare appear in a log file.
The program runs during production operation and gives you the following information: • Forecast of the amount of database conversion • Correction and database analysis • Improved database space check • List of modifications that have to be adjusted during the upgrade
During the run of PREPARE, you can enter the Support Packages, CRTs, languages, and add-ons that you want to be included in the upgrade. For upgrades up to Basis Release 4.6D, the tables for the incremental table conversion are determined during the run of PREPARE, and you are prompted to start transaction ICNV. R3up / SAPupR3up / SAPup is the central coordination process of the upgrade. This process controls all upgrade activities including initialization, data transfer, basis adjustment, application adjustment, and completion.The Upgrade Assistant Helps You to Upgrade Your SystemThe Upgrade Assistant enables you to control and monitor the upgrade process. The GUI of the Upgrade Assistant can run in an Internet browser. The following features are available: • A remote upgrade • One administrator and multiple observers can log on to the Upgrade Assistant • Access to the SAP Notes database in SAPNet from a GUI using an internet connection • Execution of operating system commands on the R/3 Server • Files can be viewed at operating system level Whenever the upgrade program stops because it is waiting for user input, an integrated alert function informs you by e-mail or telephone.
Monitoring the Upgrade
The Upgrade Monitor gives you an overview of the time schedule for the upgrade. You receive information about when the upgrade is due to end, and about the progress of important steps. If you use the Upgrade Assistant, this information is displayed graphically. The Upgrade Monitor also informs you about each process that is running. Easy Inclusion of Your Modifications
A modification adjustment during the upgrade checks any modifications that you made to application objects in your old release and includes them in the new release. Depending on the prerequisites, the Modification Assistant either automatically includes your modifications or offers you semiautomatic support for a manual adjustment. If two systems have the same modification status, you can adjust the modifications in the first system and then use a transport to include the changes in the second system. This procedure saves time when you upgrade the second system. Easy Integration of Transport Requests in the UpgradeThe transport requests for Support Packages, add-ons, languages, and the modification adjustment are imported into the shadow Repository during production operation. At a later stage during the upgrade, the shadow Repository is loaded into the SAP System. The shadow import considerably reduces downtime during the upgrade of the SAP System. Incremental Table Conversion (ICNV) Speeds Up the Upgrade The ICNV is a transaction that is integrated into the upgrade as of Release 4.6A to convert database tables whose structure changes whenever the release changes. Since incremental table conversion runs during production operation, it does not increase downtime. The PREPARE program determines the tables for the incremental conversion and prompts you to start Transaction ICNV. A list of the tables to be converted appears. You then select which tables you actually want to be incrementally converted. Transaction ICNV enables you to start and monitor the conversion, and estimates its remaining runtime.
Mass Activation of Dictionary ObjectsThere are different dependencies between the various Dictionary objects. To take these dependencies into consideration when they are activated, the Dictionary objects are sorted accordingly and divided into levels. These levels are activated in succession. As of Release 4.6C, this activation runs through multiple dialog processes (at least 6) within a request. This reduces downtime and speeds up the upgrade.
Fast Language ImportThe language import was completely updated as of Release 4.6C. To make the handling of the code pages and the import of data easier, languages are now imported using the SAP transport program R3trans. Since multiple R3trans processes are used, you can import all languages at the same time. There are usually four R3trans processes available for this import. However, depending on your database configuration, you can use many more than just these four processes. The language-dependent tables that were created for the target release are filled during production operation. This means that downtime is kept to a minimum.
ABAP Load GenerationAs of Release 4.5B, transaction SGEN is available for generating ABAP loads that are still missing after the upgrade. To avoid interrupting production operation, you can generate ABAP loads directly after the upgrade. If you do not, you have to generate the loads when you call up programs for the first time. Transaction SGEN provides the following: • Selection of the generation set • Generation as a background job • A job monitor for the background job
Why Downtime?
Downtime is necessary, whenever live transactions have to be replaced by new functions, and a potential risk of data inconsistency is given, changing the processing logic, or changing the data model/structure, for example.The big advantage of SAP upgrade technology is, that we allow our customers to adapt, extend, and modify SAP software, and that these extensions are kept and adjusted to the new release during the upgrade process. Most of the required processing steps can be performed during system uptime.
How do we support while upgrade is going on?
In order to increase the availability of system for production support and new developments during upgrade following dual system landscape helps. In this scenario, you need to setup a parallel landscape to support your production operations. In case of non availability of hardware, you would need to freeze code development immediately after first system i.e. development is upgraded to newer version. During this period it is recommended not to make any repository changes in production system directly. However you can record and perform customizing changes.Before Upgrade
Retaining older version system after the upgrade for about 2-3 months helps in resolving post-upgrade issues. The objective should be to minimize dual maintenance window.
Key things to have in place before starting - actual upgrade
Ensure you are ready with following for starting your upgrade project• Project plan with clear responsibilities• You have read all upgrade master, upgrade guides, SAP notes for your platform• Upgrade checklist is ready (covering OS, DB & SAP pre-upgrade, post upgrade tasks)
A Real example – Strategy adopted for (XYZ CORP.)
Source Version
Target Version
OS: HP-UX 11.23
DB: Oracle 9.2.0.7
SAP : R/3 4.7 Enterprise Extension set 1.10
OS: HP-UX 11.23
DB: Oracle 10g
SAP : ECC 6.0
The project plan included upgrading systems in following sequenceSandbox (copy of production) „³ Development „³ Quality „³ Production
Reference1. XYZ CORP._ECC6.00_Upgrade_Project_Plan_Rev4.mpp2. SAP Basis - Assessment Questionnaire For Upgrades Projects.doc
DB Upgrade Tasks:All DB related upgrade tasks were first listed & then performed according to upgrade checklist. Reference1. Oracle Upgrade Checklist.xls2. Oracle_Patch_Set.xls
SAP Upgrade Tasks:All SAP related upgrade tasks were first listed & then performed according to upgrade checklist. 3. SAP ECC Upgrade Checklist.xls
This checklist is divided into various phases of upgrade, all possible tasks are listed which technical team has to perform before and after upgrade. Note that majority of the steps can be performed online and some steps require exclusive downtime. Hence all downtime related activities have to be planned at least two weeks in advance.
4. Final Upgrade Timings.xlsIts very important to differentiate upgrade steps in online phases and downtime phases, basis team generated upgrade timings excel file after upgrade of sandbox system. This sheet lists execution time of each step performed during upgrade. This time only reflects system time spent during upgrade. You can compare the timings of each step in all the three systems (sandbox, development & quality) and arrive at approximate downtime required for production upgrade. This will also help you to further tune the downtime requirement. And helps customers increase their production system availability.
5. Golive Upgrade Checklist_v3.xls (The MINI plan)There are many small tasks which functional team & technical team needs to perform just before starting upgrade and after finishing upgrade, i.e. before releasing the system to end users. It is recommended that all teams, technical (hardware / software) & functional team sit together and work on Go Live checklist. “Go Live Upgrade Checklist_v3.xls” was made and updated after three rounds of brainstorming sessions. And it ensured that nothing was missed before releasing the system to end users. That’s why we call this checklists a MINI plan.
Change Management (For regular production support):
Since the project schedule was of very less duration (less than 2.5 months), XYZ CORP. & implementation team decided NOT to setup a parallel landscape for supporting production operation. Instead team decided to make only CRITICAL changes in production system directly. One single person was nominated for recording all the changes during entire upgrade duration. These changes were then performed again in Development system. These change requests were later imported in production system post upgrade.
System testing after upgrade (Test scripts):
The dedicated functional team was setup to test all critical business processes. And the test scripts were readily available before starting the upgrade. Instead of performing testing of each functionality, the team decided to perform testing of delta functionality and all the critical business processes. Delta functionality list was available from solution browser tool as mentioned above. Functional team started testing after first system (sandbox) was upgraded to target release.Change management (Due to upgrade):While testing processes in sandbox system, changes due to missing functionality were made & recorded directly in sandbox system, this continued till development system upgrade. Subsequently changes were made in Development system and imported in respective system (i.e. quality and then production). This ensured that the original source code system remains development system only.
Role Management:
All used roles were exported from 4.7 production system and imported into sandbox system prior to upgrade. After upgrade these roles were adjusted in sandbox system and then imported in development system. All delta modifications performed in running 4.7 system was then performed in development system, after upgrade of quality system these roles were then imported into quality and a final testing in quality was performed with user authorizations. Finally these roles were imported in target production system just after upgrade i.e. before releasing to end user.ReferenceSOP Roles and Authorizations.doc
Interfaces – Connecting systems:
While upgrading its important to consider all connecting system to ERP, the most important being BIW system. For the XYZ CORP. upgrade, BIW pre-upgrade and post upgrade tasks were listed in the checklist and performed as required.ReferenceXYZ CORP. BW Checklist during upgrade.xls