Why upgrade

In response to todays 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 selfservices 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. Its 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 Improvement
Focus on functionality extension and improvement
Enablement of new and optimized business processes and scenarios based on new
ERP core functionality
Functional/Retrofit Upgrade
New functionality to be implemented as part of the upgrade, modification clearing
Focus on reduction of system complexity
Technical Upgrade
Focus on pure technology upgrade
Retain functionality used
Review 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 checklist
You 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 tool
This tool enables field to help customers learn about new capabilities introduced
between R/3 and SAP ERP versions

It helps customers to identify the value proposition of an upgrade to SAP ERP

SAP Upgrade Experience Database
The SAP Upgrade Experience Database provides experiences/statistics of
completed upgrade projects. The SAP Upgrade Experience Database includes the
following upgrade aspects:
1. Additional hardware requirements
2. Project duration
3. Business Downtime
4. Reasons for upgrade, etc.
Platform Availability Matrix (PAM)
OS/Database Dependencies
Check the Product Availability Matrix (PAM) to determine if any upgrades
are required to the OS or RDBMS while upgrade - Upgrade strategy
Unicode Compliance
Unicode is the master-codepage
Acting in global business requires Support of a Global Character Set!
Companies running global business processes like Global HR Systems
Companies offering Web Services to their customers: Global Master Data containing
multiple local language characters!
Companies using Open Standards: J2EE and .NET integration
Hardware sizing resizing
Customer & consulting partner need to work along with hardware partner to verify if
the present hardware meets the expected workload post SAP upgrade, if it doesnt
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 Instance
The 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 Procedure
During 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

Operation of production and
system and shadow system
shadow system only possible
independently of each other
Higher demand on system
Production operation stops
resources
before import of substitution set into
Shorter downtime
shadow tables or, at the latest, before
Import of the substitution set
shadow instance is started for first
into the shadow tables during
time

production operation
Modification adjustment of the
ABAP Dictionary objects during
production operation
Activation and distribution
during production operation
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

Long downtime
resources due to parallel operation of
Offline backup required after
production and shadow system
upgrade
No offline backup required after
upgrade if archiving deactivated at
some stage
Disk capacity for a possible
database recovery is monitored
What tools are used during upgrade and how they affect overall plan?
Easy-to-Use Tools for a Smart Upgrade Process
SAP 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 PREPARE
The 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 / SAPup
R3up / 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 System
The 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 Upgrade
The 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 Objects
There 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 Import
The 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 languagedependent tables that were created for the target release are filled during production
operation. This means that downtime is kept to a minimum.

ABAP Load Generation

As 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
OS: HP-UX 11.23
DB: Oracle 9.2.0.7
DB: Oracle 10g
SAP : R/3 4.7 Enterprise Extension set
SAP : ECC 6.0
1.10
The project plan included upgrading systems in following sequence
Sandbox (copy of production) Development Quality Production
Reference
1. XYZ CORP._ECC6.00_Upgrade_Project_Plan_Rev4.mpp
2. 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.

Reference
1. Oracle Upgrade Checklist.xls
2. 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.xls
Its 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. Thats 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.
Reference
SOP Roles and Authorizations.doc