My Profile
Active Members
TodayLast 7 Days
more...
Awards & Gifts
Online Exams
Fresher Jobs
Our fresher job section is exclusively for fresh graduates! Find jobs for freshers in major Indian
cities including Bangalore, Chennai, Hyderabad, Pune or Kochi
Resources
Find educational articles, blogs, discussion threads and other resources.
Colleges
Find details about any college in India or search for courses.
|
NEED OF SAP UPGRADE
Posted Date:
12 Aug 2008
Total Responses:
1
|
Posted By: soumik roy Member Level: Silver Points: 1
|
SAP Labs, Inc.
Palo Alto, California
ASAP Upgrade Guide
Simplifying Your Upgrade
Copyright
© 2002 by SAP AG. All rights reserved.
Neither this documentation nor any part of it may be copied or reproduced in
any form or by any means or translated into another language, without the
prior consent of SAP AG.
Disclaimer
SAP AG makes no warranties or representations with respect to the content
hereof and specifically disclaims any implied warranties ofmerchantability or
fitness for any particular purpose. SAP AG assumes no responsibility for any
errors that may appear in this document. The information contained in this
document is subject to change without notice. SAP AG reserves the right to
make any such changes without obligation to notify any person of such
revision or changes. SAP AG makes no commitment to keep the information
contained herein up to date.
Trademarks
SAP, the SAP logo, R/2, R/3, mySAP, mySAP.com,ABAP, and other SAPrelated
products mentioned herein are registered or unregistered trademarks
of SAP AG. All other products mentioned in this document are registered or
unregistered trademarks of their respective companies.
Simplification Group
SAP Labs, Inc.
3475 Deer Creek Road
Palo Alto, CA 94304
www.saplabs.com/simple
simplify-r3@sap.com
Printed in the United States of America.
iii
Acknowledgements
I wish to acknowledge the following individuals who contributed expertise,
ideas, time, material, and resources to assist us in writing this guide.
Customers and Partners: Martin Baer, Multivision Consulting,
Switzerland; Rebecca Crowley, Guidant; Udesh Naiker; Jean Oya, Hawaii
Stevedores; Ken Shannon, Datahorse
SAP: Jacquelyn Byrd, Eddie Carter, Michael Demuth, Donata Ducati,
Andreas Graesser, Roland Hamm, “Casper”Wai Fu Kan, ArmandoManipon,
Arthur Miller, Lance Pawlikowski, Joerg Schmidt, Fabian Troendle
Documentation: Scott Bulloch, KurtWolf
Gary Nakayama, CPA
SAP Labs, Inc., 2002
iv SAP Upgrade Guide | Simplifying Your Upgrade
C O N T E N T S
Acknowledgements ..................................................... iii
Overview ...................................................................... 1
You Can Perform the Upgrade Yourself ......................... 1
Key Success Factors ....................................................... 1
Discipline ................................................................................. 2
Planning ................................................................................... 2
Teamwork ................................................................................ 2
The Upgrade Team ........................................................ 2
mySAP Technology Staff ................................................................ 3
Functional / Business Process Team ............................................... 4
User Owners / Key Users .............................................................. 4
Training Staff ................................................................................. 5
Your IT Organization ..................................................................... 5
Your Network of Contacts .............................................................. 5
Partners or Consultants .................................................................. 6
SAP ................................................................................................ 6
CBS Provider for VAR customers .................................................... 6
SAP Support .................................................................................. 7
Key Planning Documents ............................................... 7
ASAP for Upgrade Roadmap ........................................................ 8
Upgrade Manual ........................................................................... 8
Upgrade Script .............................................................................. 9
Relevant SAP Notes from SAPNet ...............................................10
Maintaining Documentation .........................................................11
Planning Your Upgrade ............................................... 11
System Downtime .........................................................................12
When to Perform the Upgrade ...............................................12
Items that Affect the Length of System Downtime ...................12
Long Lead-Time Items ...................................................................13
vi SAP Upgrade Guide | Simplifying Your Upgrade
Personnel ...........................................................................................14
Hardware Upgrades ..........................................................................14
Database and Operating System Upgrades and Patches ..................15
SAP Security Changes .............................................................................15
Modification Adjustments of SAP Objects ................................................15
Contingency .............................................................................................16
Other Components and Products to Consider .........................17
Other SAP Components in Sync with the SAP Release .............................17
Third-Party Products Affected by Upgrade ...............................................17
The Upgrade ..........................................................................18
Practice Upgrades ...................................................................................19
Learning Upgrade .............................................................................19
Validation Upgrade ...........................................................................26
Timing Upgrade .................................................................................26
Other Non-Pipeline Systems to Upgrade .................................................27
The Pipeline Upgrade (DEV, QAS & PRD) ...............................................28
Upgrade Landscape with Temporary Production Support Pipeline ....29
Performance Improvement Items ..........................................29
Sizing .......................................................................................................30
CPU ...................................................................................................30
Memory .............................................................................................31
Disk I/O .............................................................................................31
Copy Upgrade CDs to Disk ......................................................................31
Archiving .................................................................................................32
Support Packages and Service Release ...................................................32
Replacement Server .................................................................................33
Options to Reduce Backup Time ..............................................................34
Customer-Based Upgrade (CBU) .............................................................35
Prerequisites .......................................................................................36
New Technology and Methods ................................................................36
SAP Upgrade Services ...........................................................36
Upgrade Angel Program .........................................................................37
GoingLive Functional Upgrade Check .....................................................37
Remote Upgrade Service .........................................................................38
Resources ..............................................................................38
Bibliography .........................................................................40
Appendix ..............................................................................41
Excerpts from an Upgrade Script .............................................................41
Change Documentation ...........................................................................45
New Information ................................................................................46
1
Overview
Customers sometimes approach an upgrade with fear or apprehension.
Usually, they do not know what the SAP upgrade is and what it entails. But
an upgrade is not something to fear.
The goal of this document is to demystify the upgrade process. This
document also points out the various resources available to you concerning
your upgrade.
For this document to be database–, operating-system–, and releaseindependent,
we do not repeat instructions from the various referenced
documents and manuals. Think of this document as a compilation of various
tips, tricks, and explanations to help make your upgrade easier.
You Can Perform the Upgrade Yourself
SAP intends that you (the customer) be able to perform an upgrade by
yourself.
While upgrading SAP components is not as simple as entering
upgrade.exe and having the rest of the process run automatically, it is not
a complex problem. However, upgrading SAP components can be an
involved project.
If you have an adequate number of experienced mySAP Technology and
functional/business process team members, you should be able to perform
the upgrade with little or no external help. Be realistic. If you do not have the
proper staff to do an upgrade yourself, get the assistance of your consulting
partner. In any case, you should have your consulting partner on-call if any
problems arise.
Key Success Factors
A few key success factors to performing an upgrade successfully are:
Discipline
Planning
Teamwork
Note
The term ‘mySAP Technology’
encompasses SAP Basis and other
technologies.
2 SAP Upgrade Guide | Simplifying Your Upgrade
Discipline
You must have the discipline to plan the upgrade and follow the plan.
Your solutions can still be creative, but you must be methodical about what
you do and how you do it. If you deviate from the plan to fix a problem
without documenting it, you may not be able to duplicate that deviation on
other upgrades. Conversely, if you deviate from the plan, you may create a
problem. The upgrade could even fail because you did not perform the
procedures correctly.
Unfortunately, a number of people do upgrades (and other tasks) without the
required discipline. As a result, problems occur that otherwise should not.
Planning
Do not expect to open the upgrade kit and immediately begin the upgrade
without proper planning.
A plan is a road map. It tells you where you are going and how to get there.
You must be able to reliably duplicate the upgrade for each of your systems.
The only way to duplicate an upgrade is to follow a plan. If you do not have a
plan documented, your ability to reliably repeat the process for each system
decreases. If you cannot repeat the upgrade identically on each system, the
end result may be a failed upgrade.
Thus, discipline and planning are interrelated.
Teamwork
An upgrade is not just a mySAP Technology task. The next section, “The
Upgrade Team,” shows that the upgrade requires many different groups to
succeed. Each group must do their part in the upgrade for it to be successful.
The Upgrade Team
An upgrade is more than just an SAP Basis or mySAP Technology task. In
fact, in many cases, that portion of the upgrade is smaller than the other
portions. The upgrade team is made up of many different groups, all of them
important.
The upgrade team includes:
mySAP Technology staff (formerly know as SAP Basis staff)
Functional / business process staff
User owners / key users
3
Training staff
IT (network, servers, desktop, and so on)
Your network of contacts and peers
Partners or consultants
SAP
• Your sales contact:
• SAP Sales for direct customers
• CBS provider for VAR customers
• SAPlocalsupport
The groupings that we describe are logical groups by task or function. In a
small organization, the same person may perform several roles that fall into
many of the described groups. In a large organization, just the opposite may
happen, wheremany individuals or departments may fall into a single group.
We have a group for partners or consultants. In fact, they could be providing
you with staff for many of the other groups such as mySAP Technology team,
Basis, functional/business process team, and IT.
mySAP Technology Staff
Who They Are. Your mySAP Technology staff consists of the technical team
members familiar with the SAP systems’ technical operation and
maintenance.
What They Do. The mySAP Technology staff performs the technical
upgrade of the system. They also assist the functional / business process team
to resolve object conflicts caused by modifications that have been made by
customers.
Note
As of SAP Basis release 4.6C, the term Basis has been superseded by and is a subset of
mySAP Technology.
The mySAP Technology staff assist the functional / business process team and cannot make
the decisions about modification adjustments. Technical staff usually do not have the functional
area knowledge to properly determine the modification adjustment. Even if your technical team
has the functional knowledge, the functional team member should make the decision.
Example
We do not expect the technical team member to understand pricing procedures in the Sales and
Distribution (SD) component or cost allocations in the Controlling (CO) component.
4 SAP Upgrade Guide | Simplifying Your Upgrade
Functional / Business Process Team
Who They Are. The functional / business process team consists of team
members who are responsible and familiar with the various SAP components,
such as FI-Finance, and SD-Sales and Distribution. The team members are
normally from the various functional departments (for example, accounting
and shipping). Members of the mySAP Technology team specializing in
various functional areas (such as an FI programmer) supplement the
members of the functional team.
What They Do. The functional / business process team provides functional
area knowledge to properly test the upgrade and make business process
changes where required.
The functional / business process team performs the following tasks:
Regression testing to ensure that the business processes still work properly
after the upgrade.
Modification adjustment. Resolve changes made to SAP objects (such as
programs and tables) that conflict with new updates as a part of the
upgrade.
Business process reengineering. If the upgrade has affected the business
process, the business processmay have to be changed to accommodate the
change. A functional team member works with the various user
departments to make these changes.
Assist the training staff in updating the training and documentation for the
new release.
User Owners / Key Users
Who They Are. The user owners are the representatives of the various user
organizations or departments, such as accounting, sales and order processing,
and shipping.
What They Do. They are responsible for verifying that the system works as it
should for the end user. They perform quality assurance testing and
validation.
5
Training Staff
Who They Are. The training staff trains the end users and maintains the
specific user documentation.
What They Do. If processes and screens have changed in the target SAP
release, training documents and training programs will require revision. Such
changes probably also require the retraining of users.
The revising of the training documents and procedures should be done
jointly with the functional / business process team members.
Your IT Organization
Who They Are. The IT organization is known by various names, such as IT,
MIS, DP, computer operations, network, and telecommunications.
What They Do. The IT organization supports the hardware, operating
system, network, and the users’ desktops and mobile computers.
The IT organization runs the necessary backups, upgrades the non-SAP
software on the servers (such as the operating system and database), and
upgrades the frontend or GUI on the users computer. If hardware needs to be
upgraded, the IT organization also performs the hardware upgrade.
Your Network of Contacts
Who They Are. Your network of contacts includes other SAP customers and
consultants that you have met (in classes, customer functions, and during
SAP functions) with whom you have built a professional relationship.
Your best resource is a customer who has done exactly what you will be
doing on the same operating system, database, and SAP component release.
What They Do. Your contacts can provide guidance and advice about the
upgrade, problems to watch out for, and possible solutions. They could also
use their own network of contacts to provide you with access to even more
assistance.
Your own network can provide youwith good information at less cost than a
consultant. If a contact has just performed an upgrade, the information is still
fresh in their minds and they can provide valuable advice.
Example
In SAP R/3 4.6,many transactions differ
significantly from prior releases, such
that users may need additional training.
For example, in Release 4.6, many
transactions use a tab-based scheme
instead of the sequence of screens
used in prior releases. Therefore, the
screens look and behave differently.
6 SAP Upgrade Guide | Simplifying Your Upgrade
Partners or Consultants
Who They Are. The partners or consultants are your implementation
partners. You may also rely on outside consultants if you have released your
implementation partner.
Depending on your arrangement, SAP may be your consulting partner.
What They Do. Partners or consultants provide the project planning
guidance on performing an upgrade. They also provide the detailed technical
and functional knowledge required to perform an upgrade.
If you have the staff to perform the upgrade, the partners can provide the
training, guidance, and advice for a smooth upgrade.
If you do not have the technical or functional staff to performthe upgrade, the
partners can provide consulting personnel to perform the required functions.
A good partner assists you in planning the upgrade and helps you through
any problems faster than if you were to do it yourself.
Have them teach and assist you with the first upgrade (see “Learning
Upgrade” on page 19) and then be on-call to assist you during the upgrade of
the remaining systems.
Furthermore, partners and consultants know where problems are likely to
occur and have benefitted from the experience of upgrading other customers.
With a partner, you are buying expertise. The partner should add value to the
upgrade and not merely be another body on the upgrade team.
SAP
What They Do. As part of SAP’s support to the customer, we ask that you
advise us as to when you are performing an upgrade of your production
system. Problems related to the upgrade can be treated with greater urgency.
SAP customer support provides various upgrade services, some included as
part of your annual maintenance fees, whereas others are billable.
CBS Provider for VAR customers
Who They Are. For US customers with revenue under $500 million, the sales
and initial service contacts occurs through a VAR, a Certified Business
Solution (CBS) provider.
Have your partner teach
you to performthe
upgrade, so you can do
most of it yourself. Learning from
partners or consultants saves a
significant amount of money and
increases your knowledge of the
system.
Note
See SAP Note 30068 to register the upgrade of your production system with the support group.
7
What They Do. For CBS customers, trouble calls and messages are routed to
and handled by the CBS providers. They are your first line of contact for any
problems.
SAP Support
Who They Are. SAP Support is the same organization formerly known as
the SAP hotline.
What They Do. SAP Support provides assistance to customers for SAPrelated
problems or bugs.
If, during your upgrade, you run into an SAP problem you cannot solve, SAP
Support is available to provide assistance. If you notified them that you are
performing an upgrade of your production system, your problem messages
will have increased priority.
Key Planning Documents
During planning for an upgrade, you must gather and prepare all materials,
including the:
ASAP Upgrade Roadmap
Upgrade manuals
Upgrade script
The following graphic illustrates how these three items relate to each other.
Note
SAP Support is not a consulting
organization. If your problem is viewed
to be a consulting question, rather than
an SAP problem or error, you will be
referred to your consulting partner.
8 SAP Upgrade Guide | Simplifying Your Upgrade
ASAP for Upgrade Roadmap
What Is It. The ASAP for Upgrade Roadmap is a generic project plan,
developed by SAP for performing upgrades. Like the rest of ASAP, this
roadmap is a general tool and must be tailored for your environment.
When. The ASAP for Upgrade Roadmap should be obtained as soon as
possible so that you can begin the planning process.
Good planning takes much more time than most people realize. Planning
should be done at a high level using the ASAP for Upgrade Roadmap.
Where is it. The ASAP for Upgrade Roadmap is included in the upgrade kit,
up to SAP R/3 4.6C. For example, in the 4.6C upgrade, the CD labeled R/3
Upgrade 4.6C, contains the ASAP for Upgrade. The CD can also be ordered
separately from SAP Shop (at http://www.sap.com/shop). In SAP Shop, do a
search on the word upgrade to find the CDs.
The upgrade kit and the ValueSAP CD should be ordered as soon as possible
so you can have the CDs and begin the planning process.
Why. If you have not previously performed an SAP upgrade (and even if you
have), the tasks in the ASAP for Upgrade Roadmap should be reviewed. There
may be tasks of which you are unaware or have forgotten.
How to Use ASAP for Upgrade Roadmap . The ASAP for Upgrade
Roadmap is a general tool that must be tailored for your environment. Using
the ASAP Upgrade Roadmap as a template, you then make your own upgrade
plan.
Evaluate the various tasks and determine if they apply to your environment.
There may be tasks that do not apply and can be deleted. There may be tasks
that need to be expanded or added.
When you finish, you will have an upgrade plan tailored for your installation.
Upgrade Manual
What It Is. The upgrade manual contains details for the specific tasks to be
performed.
Note
As of this printing, the latest version of the ASAP for Upgrade Methodology can be found on the
Value SAP Edition 2 CD, material number 500-40-910. This CD is available online in the
SAPShop also.
Note
With all SAP customers, the various
materials from SAP are delivered to a
specific person. In many cases, the
person receiving the materials is not the
mySAP technology manager or the SAP
projectmanager. Sometimes, packages
are lost or are opened and material lost.
If the ASAP for Upgrade Roadmap is
not in the upgrade package, either:
Contact your SAP account
representative
Contact your VAR or CBS
provider
Order the ASAP for Upgrade
Roadmap from SAPShop
We also recommend that your internal
personnel be instructed on what to do
when SAP material is received, and to
whom the different material should be
routed.
9
Locating the Upgrade Manual . On older releases, the upgrade manual
was a printed manual included in the upgrade package. On current SAP R/3
releases, the upgrade manual is on the R/3 Upgrade CD (for example,
R/3 Upgrade 4.6C).
The current upgrade manuals are also available for download from SAP
Service Marketplace at the following URL:
http://service.sap.com/instguides
How to Use the Manual. The upgrade manual should be used in
conjunction with the ASAP for Upgrade Roadmap and your own upgrade plan
to organize the upgrade and to write the upgrade script (described in the next
section). An important thing to look for in the upgrade manual is various
prerequisites. For example, the database must be SQL Server 7 with Service
Pack 1.
Upgrade Script
What It Is . Unlike the upgrademanual, the upgrade script is a chronological
task list that tailors the processes and tasks in the ASAP for Upgrade Roadmap
and upgrade manuals to your specific installation.
The upgrade script contains detailed tasks for each person.
Why It Is Needed. You create and maintain an upgrade script to:
Organize everything to be done
Document every task and role so that no steps are omitted and no roles
forgotten
Having an upgrade script reduces the danger of making a mistake caused by
late-night exhaustion.When upgrading the system at 2 AM, if you can follow
a script to complete the process, you can rely less on your memory.
Even if it is not 2 AM when you upgrade the production system (PRD), you
still might face difficulties remembering whether you performed a step on
PRD or on one of the prior servers (test server, DEV, QAS, sandbox, or
training server). Using an upgrade script as a checklist allows you follow and
record when you complete each step of the process.
Repeat the upgrade process identically on each system.
The upgrade manual is organized by subject, not chronologically. Therefore, some tasks
discussed later in the manual must be performed earlier than tasks appearing earlier in the
manual. Furthermore, because of this organization, you cannot simply open the manual and
begin the upgrade. You need an upgrade script.
A printed manual can only be organized one way. Each way of organizing has its advantages
and disadvantages. If organized chronologically, for example, tasks for a specific subject or
person could be scattered throughout the manual.
If something in the
manual does not apply,
such as a section for a
different database, cross the
section out to avoid confusion. For
example, if you are running on
DB2, cross out the sections for the
other databases.
Note
Beginning with SAP Basis 6.10, the
upgrade manual will contain a
chronological checklist with links to all
documentation necessary for the
specific task.
Caution
If you do not have an
upgrade script, you may
forget an important step.
Consequently, the upgrade
process could be damaged, which
would require that the database be
restored from backups.
10 SAP Upgrade Guide | Simplifying Your Upgrade
By the time you perform the upgrade on the production system, everything
must have been performed at least once in practice. Rehearsing the upgrade
can only be accomplished using detailed scripts that can be followed and
duplicated. The key word is duplicated. Everything to be donemust be written
in the detailed script in the proper order.
For information on how to construct a sample script, see “Bibliography” on
page 40. The upgrade checklist in the upgrade manual will help you to list the
tasks in their chronological order.
How to Use an Upgrade Script. You need to create an upgrade script with
detailed tasks for each person.
Unlike the upgrade manual, the upgrade script is a chronological task list that
tailors the processes and tasks in the manual that are specific to your
installation. Some examples of processes requiring customer-specific tailoring
include:
Databases
User IDs
Passwords
Drive letters
Directories
Files
Assign tasks in the script. You need to identify decision points (including who
makes the key decisions) and actions for go/no-go.
Each task should have a completion indicator, so you can mark that the task is
complete. A date and time when the task is started and completed could also
be helpful.
Everything done during the upgrade should be on the upgrade script.
Conversely nothing should be done that is not on the script. This ensures that
the upgrade is duplicated reliably on each system.
Relevant SAP Notes from SAPNet
Before you complete your upgrade script, gather all relevant SAP Notes from
SAP Service Marketplace at http://service.sap.com/notes or from SAPNet-R/3
through transaction OSS1. The SAP Notes advise you of problems and issues.
In most cases, the notes can provide solutions to those problems. The longer
the target release has been out, the more problems have likely been found and
solved.
SAP Notes can be critical.
Your upgrade may fail if a
critical note is not applied.
11
You should look for several different kinds of notes:
The upgrade manual lists all necessary notes to conduct your upgrade. The
General Upgrade note is the most important for your upgrade as it
complements the upgrade manual and is continuously updated. It also
contains links to other critical notes that you might have to consider during
the upgrade.
Maintaining Documentation
After reading relevant SAP Notes, you should review the following
documents:
ASAP for Upgrade Roadmap (your upgrade plan)
Upgrade manual (Make corrections if changes from the notes affect your
upgrade plan and the upgrade manual.)
Your upgrade script
Keep the upgrade script updated with changes from the various SAP Notes.
Update the script based on what you learn from performing practice
upgrades.
Planning Your Upgrade
We do not intend to duplicate tasks specified in the ASAP for Upgrade
roadmap. However, certain items and tasks require more discussion,
including:
System downtime
Long lead-time items
Note Type Description
Upgrade-specific notes Upgrade-specific SAP Notes can contain corrections or updates to
the upgrade manual. These notes are specific to the target
upgrade release and are therefore critical. The main notes are
listed in the upgrade manual.
R/3-related notes R/3-related notes address general problems. The upgrade manual
or the upgrade note usually references these notes.
Database notes Database notes tell the minimum release and patch level on which
the upgrade can be performed. These notes also set database
parameters for the upgrade.
Operating system notes Operating system notes also tell the minimum release and patch
level on which the upgrade can be performed.
SAP Notes can reference
other SAP Notes, so you
may have to follow a trail
of notes. After locating all relevant
notes, you must evaluate how all
the notes interact and relate.
Some SAP Notes are
continuously updated.
You must download the
latest notes on a regular basis,
before an upgrade is performed.
12 SAP Upgrade Guide | Simplifying Your Upgrade
SAP security changes
Resolving SAP object conflicts
Contingency planning
System Downtime
System downtime is the time that the SAP system is not available to users.
The reason for the downtime does notmatter—to the users, it is still
downtime.
The SAP upgrade itself is only a part of the total downtime required for
upgrading your SAP system to a new release.
When to Perform the Upgrade
An upgrade requires the SAP system to be down and not available to users
for a period of time. You need to plan for this downtime according to your
business operations. Upgrades should be scheduled on three- or four-day
weekends when possible.
For seven-days-a-week operations or others where a 3 or 4-day weekend is
not available, downtime is especially difficult to plan for. See the section
“Performance Improvement Items” on page 29 for options and ideas to
reduce the system downtime.
Items that Affect the Length of System Downtime
Your total system downtime is not just limited to the time to perform the
technical upgrade of the SAP system. Several other related items extend the
downtime, sometimes significantly, such as:
Backups
Problem resolution
Testing
Backups. Taking your offline backups before and after the upgrade can
significantly add to downtime.
Example
If it takes three hours to take an offline
backup of the system, the system is
down for three hours, even before
starting the upgrade. The same applies
to the post-upgrade backup. Thus, an
additional six hours of downtime for
taking backups, three hours before and
three hours after, must be factored into
the plan.
13
Certain drive systems on themarket can be used to significantly reduce
backup downtime.
We discuss different options to reduce backup time in the section “Options to
Reduce Backup Time” on page 34.
Problem Resolution. Problem resolution often involves the resolving
conflicts with SAP objects (see “Modification Adjustment” on page 23).
During the learning upgrade, problem resolution takes a significant amount
of time. However, with the transports generated as a result of the learning
upgrade, this step on subsequent upgrades will be relatively insignificant.
Testing. The post-upgrade testing (both regression testing and acceptance
testing) also requires the system be unavailable for general usage.
Using Computer-Aided Test Tools (CATTs) or other automated testing aids
can significantly reduce the amount of time required for testing. The other
advantage in using a CATT is repeatability. The same test can be run on each
system. Human error and inconsistency is virtually eliminated.
Long Lead-Time Items
Early in the planning of the upgrade, several long lead-time tasks need to be
addressed. These include:
Personnel availability
Hardware upgrade
Database upgrade
Operating system upgrade
Example
If you have a three-waymirror, you can break the three-waymirror to take a snapshot and thus
have a backup downtime of your R/3 System in minutes rather than hours.
Note
These drive systems are not inexpensive solutions.
CATTs are sensitive to changes in the transaction screen. If the transaction has been changed
in the upgrade, the CATT will fail and must be fixed.
This has the fortunate benefit of telling you that the transaction has changed and needs to
be reviewed to determine what effect the change has.
Note
In the SAP R/3 4.6C Online
Documentation, information on CATTs
can be found by following the menu
path: SAP Library?Basis
components?Computer Aided Test
Tools (BC-CAT)
Caution
14 SAP Upgrade Guide | Simplifying Your Upgrade
Personnel
Availability of Personnel. An obvious but often forgotten item is personnel
availability. All key personnel who are involved in the upgrade must confirm
that they will be available during key phases of the upgrade process and
when the upgrades are planned. It is normally understood that the SAP team
personnel will be available, but what is often missed are the various key
personnel from the functional organizations.
All key personnel involved in the upgrade must be informed of the upgrade
schedule well in advance of the upgrade. If a three or four day weekend is in
the upgrade plan, be aware that employees may have already planned
vacation during the same period, and quite possibly well in advance of the
upgrade plan. The company must either plan for the person not being
available, or make compensating arrangements for the employee to change
their vacation.
Avoiding single point failure with personnel . During the early phase of
the upgrade process, a process should be put in place to find, train and have
at least two people in each area or task, sufficiently trained and
knowledgeable so either can do each other’s job. This reduces the risk that the
upgrade process will stop if someone is unavailable due to illness, job change,
leaving the company, and so on.
Hardware Upgrades
What. When you upgrade your SAP System, your hardware may also need
to be upgraded to a configuration with greater resources; number and speed
of processors, amount of memory, and amount of disk space.
Why. When you upgrade SAP, keep in mind that additional functionality
and increased transaction volume may be more than the system was built to
handle. You may require additional resources. Check for SAP Notes that
describe resource requirements.
A problem with hardware upgrade is that not all the equipment may be
available off-the-shelf. If it must be special ordered or if it is in short supply,
procurement could take a significant amount of time. In addition, the
hardware has to be shipped and installed, which could take several months.
When. Since hardware procurement and installation can take a significant
amount of time, this must be planned into your upgrade schedule.
If the hardware upgradewill be done on the live system, it needs to be
planned and scheduled, as it will result in system down time.
How. To simplify the upgrade project management, we recommend that the
hardware upgrade should be treated as a separate project, and must be
completed before the SAP system can be upgraded.
With the falling cost of
high-performance
computer equipment,
replacing old equipment may be
more cost-effective, rather than
upgrading older equipment.
For example, an older server with
two Pentium® 166MHz
processors, 512MBRAMand 4GB
hard drives can only house two
more 166MHz processors—if you
can find the processor expansion
kits. You are still processor-speed
limited at 166MHz, whereas
current servers have 800+MHz
quad processors. You may not be
able to add anymore memory, and
thus may be memory bound,
whereas newer servers can
contain over 2GB of RAM. You can
replace the 4GB hard drives with
larger drives for a larger database,
but you are still limited by the
speed of the processors.
15
In this way the SAP upgrade projectmanger does not have to also manage the
hardware upgrade. The hardware upgrade becomes a task in the SAP
upgrade plan. The IT organization would manage the hardware upgrade.
Database and Operating System Upgrades and Patches
What and Why. Interdependencies exist between the SAP component,
databases, and operating system release levels. For example, SAP R/3 could
require the database and operating system to be at a minimum release and
patch level. Also, the database upgrade could require that the operating
system be upgraded to a minimum release and patch level before it can be
upgraded.
When and How. If the database and/or the operating system are required to
be upgraded, the upgrade should be treated as a separate project that must be
completed before the SAP systems can be upgraded.
In this way, the SAP upgrade project manger does not also have to manage
the database and operating system upgrade. They simply become tasks in the
SAP upgrade plan. The IT organization would manage the database and
operating system upgrade.
SAP Security Changes
A common problem that is overlooked or left to the end of the upgrade
process is the changes to SAP security in the target release.
Resolving security changes in the new release, or rebuilding the security with
the new tools (such as implementing the Profile Generator) takes a significant
amount of time. If the security model has changed significantly from what
you know, there will also be a steep learning curve.
User security involves all functional groups, requiring many people to
investigate and resolve any upgrade issues.
Modification Adjustments of SAP Objects
A potentially major problem is adjusting your modifications to the newly
delivered SAP objects. These are changes that you have made to standard
SAP objects that are being updated in the upgrade. See “Modification
Adjustment” on page 23.
Until you get a listing of modification to be adjusted, estimating the amount
of time that it will take to adjust the objects may be difficult or impossible.
You would know how many objects have to be adjusted only when you get
the listing. Once this list becomes available, in the PREPARE phase, you will
be able to evaluate the effort and make adjustments to the upgrade plan and
schedule.
Note
The ability to make the database and or
operating system upgrade a separate
project depends on the specific details.
There may be situations where the
database and/or operating system
upgrade must be done at the same time
as the SAP upgrade. This will be
specified in the Upgrade Manual or SAP
Notes for the specific target SAP
release.
The expedient solution of
granting the security
profiles SAP_ALL and
SAP_NEW to all users will
circumvent your existing security.
At that point there is NO security in
the system.
16 SAP Upgrade Guide | Simplifying Your Upgrade
If proper documentation standards (see the Appendix on page 40) have not
been maintained during development, the amount of time to resolve object
conflicts can be enormous. Unfortunately, in many cases, it is when an
upgrade is performed that it is discovered how poorly documentation
standards were followed, if at all.
Contingency
Contingency is defined in this case as what if something goes wrong, what do I
do? Your upgrade should happen without problems, but it is always a good
idea to plan for any problems that might occur.
For the upgrade, this contingency is taken care of by go/no-go decision points.
You should put into place various decision points in your upgrade plan and
upgrade script where go/no-go decisions should be made. These critical
decision points can occur in all phases of the upgrade. The decision point is at
a critical place where a failed task puts the upgrade at risk, or the resulting
system is not usable.
A contingency does not always have to be at a go/no-go decision point. Any
task could fail, for any number of reasons. The question then becomes what
you do when that task fails. The decision could be to abort the upgrade. Or
the failure could be so minor that you could safely continue the upgrade.
However, in all cases, the failure must be addressed.
Where go/no-go decisions exist, steps need to be defined and matched with an
owner who is responsible for making the go/no-go decision.
Items to resolve when a no-go decision terminates the upgrade include:
Who needs to be consulted prior to aborting the upgrade?
Who is the person with the authority to make the decision to abort the
upgrade?
Who needs to be informed of the abort?
You must have an abort list of people to call if the upgrade is aborted.
What needs to be done to get the system back to a pre-upgrade state?
Example
Some examples of contingency points are:
Was the pre-upgrade backup of the system successful?
• A failure here would mean you have no safety net if the upgrade fails and you
have to restore the system.
Did the technical upgrade complete without fatal errors?
• A failure here could require a restore of the database.
Have all acceptance tests completed successfully?
• A failure here means that the users will not accept the system as delivered. They
cannot do their jobs with the system in an unacceptable condition.
Murphy’s Law applies to
upgrades. Anything that
can go wrong, will go
wrong.
This is especially true on the
upgrade of the production system.
The no-go process must
also be planned for. If it is
not, and a no-go decision
ismade, you will not have a plan of
action in place. The no-go process
can be even more critical than the
go process.
A very commonmistake is
to make a plan assuming
everything works
properly. But when something
fails, there is no plan to
accommodate the failure.
17
How long do you have to recover the system?
Other Components and Products to Consider
Other SAP Components in Sync with the SAP Release
Other SAP components need to be in sync with the SAP release. These
components must be compatible with the target SAP release, or a new release
of the component must be compatible with the target SAP release. If the
component is not available for the target release, this situation may prevent
your upgrade. Thus you need to plan for upgrading these components as
well.
Some of these components have dependencies that will require a specific
order that they must be upgraded in.
The components that you need to ensure compatibility and availability with
include:
Industry solutions
Plug-ins
Extractors
Internet Transaction Sever
Third-Party Products Affected by Upgrade
Any third-party products that interface to SAP systems need to be checked.
These products must be compatible with the target SAP release, or you must
obtain a new version of the product that is compatible with the target SAP
release.
Example
If IS Software is not available for SAP R/3 4.6C, you cannot upgrade to SAP R/3 4.6C until the
IS Software component upgrade is available for SAP R/3 4.6C.
Example
For the ITS, the ITS release must be equal to or greater than the backend SAP R/3 release. If
you have ITS 4.6B, and you will be upgrading to SAP R/3 4.6C, you must first upgrade the ITS
to release 4.6C or higher before upgrading the SAP R/3 system.
18 SAP Upgrade Guide | Simplifying Your Upgrade
If a third-party product is not available for the target release, this situation
may prevent your upgrade. You must establish alternate plans if you cannot
use the third party products.
In some cases the third party products have not been upgraded for the release
of the database or operating system that the target SAP release runs on.
Some third party products are:
Sales tax programs
Credit card authorization programs
Print management systems
Background job schedulers
System monitoring programs
The Upgrade
We discuss the upgrade in two major phases:
The practice upgrades, to learn and refine the upgrade process.
The pipeline upgrades,when you upgrade your development support and
production systems.
These phases and upgrades will differ from those described in the ASAP
for Upgrade Roadmap. This is because for this guide, we usemeaningful
labels that describe what the various upgrades are and their purpose.
Example
Your third-party printer output manager does not work with SAP R/3 4.6C. In order to upgrade
to SAP R/3 4.6C, you must also upgrade the external printer output manager to an SAP R/3
4.6C-compatible version, or consider an alternate solution.
Example
Your external tax calculation program only runs on Microsoft SQL Server 6.5, it does not work
on Microsoft SQL Server 7. Your target SAP R/3 4.6C requires Microsoft SQL Server 7. You
cannot upgrade SAP R/3 until your external tax calculation program has been upgraded to run
on MS SQL Server 7.
19
Practice Upgrades
We recommend that you plan to go through at least three practice upgrades.
The three practice upgrades that we recommend are:
Learning upgrade
Validation upgrade
Timing upgrade
These upgrades are named by function, but may be known by different
names. They each have a specific purpose in the upgrade process, and will be
described in greater detail in their respective sections.
We will go into more detail about the learning upgrade and then refer to the
details of the learning upgrade in the later upgrades.
Learning Upgrade
Your first practice upgrade is the learning upgrade.
The learning upgrade fulfills the following purposes:
Familiarity with the upgrade process
Learning what the upgrade does
Determining what problems you will run into, and to solve these problems
Adjustingmodifications to SAP objects, and generating the transports that
will be used in subsequent upgrades
You should expect this learning upgrade to take the longest time of all the
upgrades, and to have the most problems.
The process in brief is as follows:
Copy your production system into a test server.
You must use a good copy of the production system (such as database,
operating system files and so on) to duplicate as close as possible
everything that could occur on the production system. This process of
copying the production system is the same process that you would use to
perform a disaster recovery.
Go through the upgrade to learn what to expect, and what you need to do
for each step.
If you have a LARGE
production system (for
example, over 200GB)
you might want to take a copy of
your development system (which
is presumably much smaller) to
use for learning. The upgrade on
the smaller database will run
faster.
Do a copy of the production
system later in the timing upgrade,
to learn the effects of the size of a
system with representative data
(the size of objects and potential
areas of problems with the
production system.)
You can do this only if your DEV
system is in sync with your PRD
system.
Until you can go through
the learning upgrade
without problems, you are
not ready to move to the next
upgrade.
20 SAP Upgrade Guide | Simplifying Your Upgrade
Validate the accuracy of your plan and script.
Fix your plan where it is not accurate.
Gather preliminary timing for each step.
For accurate timing, the test systemshould duplicate as closely as possible
the configuration of the production system.
Repeat the upgrade as many times as necessary to understand and learn
what needs to be done.
The functional/business process staff needs to evaluate the modification
adjustments.Whenever possible, go back to SAP standard. Make the
modifications to reapply object changes, creating transports that you can
apply to subsequent upgrades. For more information, see “Modification
Adjustment” on page 23.
The functional/business process team and users must perform a functional
test of the upgrade and sign off on the upgrade. This is to validate that the
business processes will be able to function.
Tasks to Do Prior to the Upgrade . There are various phases of the
upgrade process that need to be done before running the upgrade itself. They
are:
Tasks to do prior to the PREPARE phase
Executing the PREPARE phase
Tasks to do after the PREPARE phase, but before the UPGRADE
Tasks to Do Before the PREPARE phase.
R/3 System.
SAP System Prerequisites for the source release:
The upgrade may require that the source SAP release (the release that you
will be upgrading from) be at a certain minimum level before the upgrade
can begin.
Support packages installed to a defined minimum level.
Update the following to the current level:
Kernel
tp
R3trans
SPAM
Support Packages for the target release. Consider installing the support
packages for the target release as part of the upgrade, instead of separately
after the upgrade. As of SAP R/3 4.6, support packages can be installed as
part of the upgrade process, saving time after the upgrade. The upgrade time
Note
If you will be installing the support
packages as part of the upgrade, you
must have the support package files
available during the PREPARE phase.
21
increases because of the additional time spent installing support packages,
but the overall time decreases because the support packages are installed
faster in the upgrade than when done separately after the upgrade.
Profile Parameters. Be sure to set SAP profile parameters as specified for
the upgrade.
Database and Operating System.
Version and Patch Level. Before running PREPARE, upgrade the version or
patch level of the database and operating system if needed.
Parameters. Be sure to set database parameters as specified for the upgrade.
Upgrade. The DB/OS upgrade should be run in a separate maintenance
period other than the one for the SAP upgrade. SAP offers a downward
compatible kernel for the start release, which is already linked with the
appropriate releases of OS and DB libraries.
Upgrading the version or patch level should be done as a project in itself.
While upgrading the database (DB) or operating system(OS)may be required
by the SAP upgrade, the DB/OS upgrade is a major project and should be
managed as such, not as part of the SAP upgrade.
The PREPARE Phase. The PREPARE program runs checks on your system to
determine if the prerequisites for the upgrade have been met. In the later
releases, PREPARE:
Checks space in the database
Performs RFC and batch checks
Checks for open repairs
Identifies objects to be adjusted
Identifies modification adjustments
The earlier you run the PREPARE program, the more time you have to act on
the results.
Tasks After PREPARE and Before the Upgrade. Tasks to be run after
PREPARE but before the upgrade include:
Communications
Keep users informed of:
• The upgrade schedule (start, end and down-time)
• How the successful upgrade will be communicated
• Problems
• Available options if the upgrade is aborted
For SAP
22 SAP Upgrade Guide | Simplifying Your Upgrade
• Set the SAP profile parameters as specified for the upgrade.
• Install the Upgrade Assistant.
For your database
• Set database parameters as specified for the upgrade.
For your operating system
• Set operating system parameters as specified for the upgrade.
Download upgrade notes to see if any late changes or updates have been
made to the notes. Always review the notes just prior to the upgrade to see if
any new changes have appeared since you last reviewed the notes.
The Upgrade Assistant. The Upgrade Assistant is a frontend for running
and monitoring the upgrade. The Upgrade Assistant has two modes:
Administrator, to actively run the upgrade
Observer, to monitor the progress
The Upgrade Assistant can also be used remotely.
After installing the Upgrade Assistant and checking it out on the local
network, make sure that you can get through your remote connection
firewall.
The SAP Upgrade Phase. The technical upgrade is performed during the
SAP upgrade phase. As mentioned previously, we will not duplicate the
detailed procedures from the upgrade manual and other documents, but will
provide additional hints and tips where problems normally occur.
Backup. Before the upgrade begins, you should perform a full backup of the
SAP component, the database, and operating system files. If you have the
time, making two backups is not an unreasonable task, given the critical
nature of the task.
Note
While the upgrade team is running the upgrade in the office, the technical manager can monitor
progress from his office or home in observer mode.
If there is a problem, others can access the Upgrade Assistant in observer mode to review the
problem. In this way the person running the upgrade and the resource helping him can view the
upgrade using the Upgrade Assistant at the same time.
If you cannot connect to the SAP server from your remote connection, get the help of your
network security group to open the port the Upgrade Assistant uses.
The Upgrade Assistant uses port 4239 (or port 4241, if the native UA is used for remote
connection via SAProuter, see Upgrade Assistant Online Help and SAP Note 133402).
TechTalk
Your backup procedure
must be a reliable, tested
and verified procedure. If
the upgrade fails and you must
restore the system, this is your
only way of restoring the system.
There is no option to fail, the
backup procedure MUST finish
successfully.
23
Problems. During the practice upgrades (see “Practice Upgrades” on
page 19), you might run into problems that need to be researched on SAP
Service Marketplace or SAPNet-R/3. The solutions must be added to your
upgrade script. Some may be as simple as repeat the phase or ignore the error
message, whereas others may require the application of an SAP Note.
Organization. Plan for the production and dress rehearsal upgrades to go
nonstop to minimize downtime.
Organize your staff in shifts to monitor the upgrade. If the staff is on-site,
consider having a break room with cots, food and drink. Rent a nearby
hotel room for the off-shift staff so they do not lose time driving home.
Maintain a status board for the upgrade, so people will not bother the
upgrade staff with questions about how the upgrade is going.
Notification of Delays. An alert mechanism can be used to generate a page
if the system waits too long for a user response. This alert mechanismmust be
configured and tested in advance.
Post-upgrade Tasks. Backups. After the SAP upgrade, you should first
back up the SAP component, the database, and the operating system.
Modification Adjustment. After backing up SAP, you will need to resolve
conflicts to SAP objects. These are the modifications that you have made to
various SAP objects (such as programs and tables) that are affected by the
upgrade. As a part of the upgrade process, the conflicts are identified for you
to resolve.
The functional team must determine:
If the changes are in the upgrade, and thus do not need to be reapplied.
If the changes are not in the upgrade, and thus need to be reapplied.
• In making the changes, transports will be created. These transports
will be imported into subsequent upgrades, so the changes do not
have to be manually reapplied.
Whenever a change is made to SAP programs and other objects, your change
documentation should reflect the SAP Note number that brought about the
change. Reading the note may indicate that the problem in the note was fixed
in a particular SAP release. If this release is equal to or less than the release
you are upgrading to, you could let the program return to SAP standard.
Adjusting the
modifications made to
SAP objects is probably
the most difficult and timeconsuming
part of the upgrade,
and requires extensive advanced
planning.
Note
The mySAP Technology team could
have Basis-related or mySAP
Technology changes that need to be
reapplied.
24 SAP Upgrade Guide | Simplifying Your Upgrade
If the changes made to the system were not properly documented, it will be
very difficult and time-consuming to determine why the changes were made.
Once all the corrections have been made, the resulting transport files can be
saved and imported into subsequent upgrades, thus saving the manual
repetition for each upgrade, in which mistakes could be made.
The recommended process is as follows:
On the first upgrade:
Reset the object to SAP standard.
Reapply the required changes. This will generate a transport.
Save the transport files.
On the subsequent upgrades, import the transports saved in the third step.
This transport applies the changes made in the previous step.
Testing. Two kinds of testing need to be done:
Regression testing determines if business processes, such as order entry,
still work the same after the upgrade.
Acceptance testing is performed as a QA check to determine that the
system, as upgraded and fixed meets the user’s requirements.
Regression Testing. Regression testing has two purposes:
Determine if business processes still function as in the prior release.
Identify changes in the new release that will require additional work
• Business processes that will require changing to work with the
upgraded system
• Documentation and training for changes
Example
The modification adjustment step identifies a change to an SAP program. But nowhere in the
program is there any documentation of why the change was made, who made the change, are
there any related programs or objects affected by the change. Trying to determine this could
take a week for just one object.
Record the transport numbers for the conflict fixes. Save the associated transport files (these
are in the directory usr/sap/trans/data and usr/sap/trans/cofile directories) to import into the
other systems.
On subsequent systems that are upgraded, import the transports created above, in the order
that they were released, after the upgrade is completed. This process then applies all the fixes
made in the first system to all subsequent systems. It eliminates human error of fixes done
manually and saves a significant amount of time.
If many undocumented
changes are found, this
could easily add weeks of
time to your schedule.
Tips & Tricks
25
• Changes that may be required of the system if the business processes
cannot accommodate the changes from the upgrade
Regression testing checks if business processes such as the following can be
performed correctly:
Can you enter an order?
Can you enter a journal entry?
Can you ship a product?
Does the order flow through into the billing?
Can you look up information, such as orders or journal entries?
Are the prices calculating correctly?
Are the financial statements and reports correct?
Do third-party programs function properly?
Regression testing also involves various technical groups. Check to see if the
various in-bound and out-bound interfaces with other systems still work,
such as:
EDI interface
Payroll
Connections to various legacy systems
Also check for the following:
Do system management processes developed for the prior release still
work in the new release?
Does the disaster recovery plan have to be changed because of changes in
the new release?
After regression testing has uncovered changes that need to be made to the
business process or the SAP system, the functional team and any other
required group (training, users, and so on) will perform the required changes
to the business process or the SAP system.
As discussed in “Modification Adjustment” on page 23, some of the changes
made to the SAP R/3 system can be captured in transports. These transports
can be saved, then applied to subsequent upgrades, saving time and effort.
Acceptance Testing. The representatives of the user organization do
acceptance testing.
After the system is upgraded and all required fixes are made, the user owners
will perform a final QA test, similar to the regression test, to determine if the
upgrade had succeeded and the users will be able to perform their tasks. The
regression test looks for problems. The acceptance test should have no
problems found. If there are no problems found, the users sign off. The signoff
is the acceptance by the users of the system as delivered.
26 SAP Upgrade Guide | Simplifying Your Upgrade
Validation Upgrade
In the validation upgrade, repeat everything you did in the learning
upgrades. This time, you verify that everything you need to do is documented
properly and that you now know what to expect. Essentially, your upgrade
script gets validated in this step, with one difference. Rather than
investigating and making fixes, everything should be documented. There
should be nothing new. The modification adjustments is done by importing
the transport requests generated in the learning upgrade. Thus from the
validation upgrade and later, the time to fix the system is dramatically
reduced.
If there are problems in the validation upgrade, fix the problem as in the
learning upgrade. Then repeat the validation upgrade.
The final validation upgrade should complete without any problems.
Timing Upgrade
The timing upgrade serves as a dress rehearsal. You would do everything as
if it were the production system. The primary purpose for this test is to
determine how long the various steps of the upgrade will take. This will assist
in the planning of the timing of the production upgrade.
You perform this procedure to rehearse and time the upgrade of the
production system.
Copy your production system to a test server.
Use a good copy of the production system to duplicate as close as possible
everything that could occur on the production system.
For accurate timing, the test system should duplicate the configuration of
the production system.
Do not do anything different than the validation upgrade, or you could
invalidate your planning.
To time this rehearsal as if it were the production system:
• Start on same day and time (for example, Friday afternoon).
• Schedule and run on a 24-hour, nonstop schedule.
Time each step to finalize the preliminary timing.
If you have a large
production system (for
example, over 200GB) for
your learning upgrades, you might
want to take a copy of your
development system (which is
presumably much smaller).
The timing upgrade would use a
copy of the larger production
system to learn the effects of the
size of the production system on
the upgrade.
27
The functional/business process team and users must perform a functional
test of the upgrade, and must sign off on the upgrade.
If the timing upgrade goes beyond the target time, then the timing upgrade
phase becomes a second learning upgrade. This time, the purpose is to reduce
the time to perform the upgrade. You must then repeat the QA and validation
that are part of the learning upgrade. Any changes to the upgrade process
could invalidate any QA and acceptance work that has been done in prior
phases.
Other Non-Pipeline Systems to Upgrade
You may have other systems in your system landscape besides the pipeline
systems (see the next section for definition of pipeline systems). The upgrade of
these systems is not critical but may influence the entire upgrade strategy.
Note
The results of the timing upgrade may, or may not apply to the other systems, depending on if
they are configured the same as the production system.
For example, if the DEV system has two 500MHz CPUs and 1GB of RAM vs. the PRD system
with eight 800MHz CPUs and 4GB of RAM, the DEV performance would be less than the PRD
system. But the DEV system generally has very little data compared to the PRD system.
Example
Constraint:
The upgrade must be completed so users can begin work at 8AM Monday morning. The timing
upgrade begins at 11 PMFriday evening and runs to 6 PMMonday evening. The timing upgrade
has taken ten hours longer than the allotted time. The task now is to determine what can be
done so that the upgrade process completes by the 8AM target time.
Comments:
Some of the options are:
The start time for the upgrade could be negotiated with the users to begin at 7 PM
Friday evening, four hours earlier.
Run the upgrade on a three-day weekend, thus gaining an additional 24 hours.
Techniques:
Look for the task that took the longest amount of time to complete. This is where the
potential for saving time is greatest. Then from there work to the shorter tasks. For
example, saving 25% of a two-hour task saves 30 minutes, saving 25% on a tenminute
task saves 2 ½ minutes.
Look for wait time. This is time lost waiting for action or a decision.
28 SAP Upgrade Guide | Simplifying Your Upgrade
Sandbox – This is generally the system that you were practicing your
upgrades on, so as not to break the pipeline during the initial phases of the
upgrade.
Training – To prepare your users for the upgrade, the training system
should be upgraded before the development system. This approach allows
the users to practice on the new release while you are upgrading the
pipeline.
• If the new release is significantly different than the old release, we
strongly recommend having a training system available to train the
users on before the pipeline is upgraded.
The Pipeline Upgrade (DEV, QAS & PRD)
Overview. After a clean validation and timing upgrades, you are ready to
upgrade the pipeline. The pipeline is the path made up of the standard three
systems—development (DEV), QA (QAS) and production (PRD). Normally,
the pipeline describes how fixes are brought into the production system,
developed in the development system, tested in the QA system, and then
finally moved into the production system.
Phases. The phases of the pipeline upgrade correspond to the systems in the
pipeline.
Development (DEV)
Quality Assurance (QAS)
Production (PRD)
• Do nothing different than what you practiced. If you do something
different, you could invalidate all of your practices.
• Arrange for on-call consulting assistance with your partner.
• Notify SAP of the upgrade, using SAP Note 30068. You can obtain
special assistance if needed during the upgrade.
Acceptance Testing. Acceptance testing is done by the Functional Owners,
representatives of the user organization. If there are no problems found, the
users sign off. The sign off is the acceptance by the users of the system as
delivered. The most important sign off is the sign off on the production
system.
A major planning issue is
that, once the
development system has
been upgraded, you no longer
have a production support
pipeline. The DEV system is on the
new release and the PRD system
is on the old. You now need to
complete the upgrade of the
pipeline as fast as possible.
Note
In many companies, where the upgrade
of the pipeline may take many months,
there are other options. These all
involve additional systems for a
temporary production support pipeline,
which is used to provide production
support during the upgrade of the
pipeline. Note that this increases the
number of systems from three to as
many as five! For more information, see
“Upgrade Landscape with Temporary
Production Support Pipeline” on
page 29.
29
Upgrade Landscape with Temporary Production Support
Pipeline
What . The upgrade with a temporary production support pipeline is a dual
path landscape. The production support pipeline remains in place (DEV and
QAS). In addition, an upgrade pipeline is created (DEV2 and QAS2).
Why. The temporary production support pipeline alternative is for
installations where the upgrade of the pipeline may take many months, or
where you absolutely must have a production support pipeline during the
upgrade. This allows productions support changes to be made, tested and
moved into production during the pipeline upgrade.
How. Briefly, the development (DEV) and QA (QAS) systems are copied to
another pair of systems to be used for the upgrade (DEV1 and QAS1).
Whenever a change is made to the production support pipeline, the same
change must be evaluated and then made to the upgrade pipeline systems.
Note that there are many variations of this process. In one variation, it is the
production support that is moved to the copied systems. In another variation,
only one copied system is used for production support.
In all cases, the planning and coordination in this landscape is critical. To
minimize the problems, only critical changes should be implemented.
Performance Improvement Items
There is no quick fix to improve performance. Many items affect performance,
some more than others, and not always in a consistent manner between
different installations.
With this in mind, we discuss several items that could improve the
performance of your upgrade. Depending on your situation, configuration,
and production system considerations, some of the following may apply to
your situation. You must evaluate their applicability to your installation.
30 SAP Upgrade Guide | Simplifying Your Upgrade
The performance improving items we discuss are:
Sizing
CPU
Memory
Disk I/O
Copy upgrade CDs to disk
Archiving
Support Packages and Service Releases
Replacement Server
Options to reduce backup time
Customer Based Upgrade (CBU)
Sizing
Sizing refers to the capacity of the hardware that the system is installed on,
and if the hardware has sufficient resources for adequate performance. Sizing
is important for both the upgrade itself as well as the running of the system
after it has been upgraded.
Is the server undersized for the target SAP release and your business?
Is the server undersized as you project for one to two years?
If the server is determined to be undersized, consider upgrading or replacing
the hardware in advance of or as a part of the upgrade. Replacing hardware
could make your upgrade go faster.
If you decide to upgrade the server as part of the SAP upgrade, you have the
following two options:
Migrate to the new server before performing the upgrade.
Migrate to the newserver as part of the upgrade. Formore information, see
“Replacement Server” on page 33.
Note that sizing a server also covers some of the other items in this section,
such as CPU, memory, and disk I/O.
CPU
The Central Processing Unit (CPU) or Processor is the brains of the server.
The CPU is a component of the sizing exercise above.
The speed and number of processors in the server has an effect on the
upgrade run time. Having additional CPUs in the server allows more parallel
processing to occur, speeding up the upgrade process.
31
Memory
Memory refers to the volatile memory know as Random Access Memory
(RAM). It does not refer to the amount of storage space on the disks.
Memory is a component of the sizing exercise above.
The SAP system and the upgrade make use of buffers to speed processing.
These buffers typically run in RAM.When enough memory is not available to
hold the buffers, the buffers are stored on disk.When the system needs to
read data from disk instead of memory, the accessing of that data on disk is
much slower than memory.
In addition to SAP, the database and operating system make use of memory
for buffers and swap files. If there is not enough memory for these, they will
be swapped to disk, again decreasing performance.
Disk I/O
Disk Input/Output (Disk I/O) is the physical writing to or reading from the
disk. Disk I/O, being physical rather than electronic, is the slowest thing that
can happen on the server.
Disk I/O is a component of the sizing exercise above.
Because of the large number of writes to the database, any bottleneck in disk
I/O will slow down the upgrade. RAID5 (stripe plus parity) is typically
slower than RAID1 (mirror) or RAID 0+1 (mirrored stripe). To reduce head
contention, the more spindles (disks) the data is spread over, the faster the
write.
The mistake that is often made is maximum utilization of disk space. This is
translated as use all available disk space, don’t waste space. However, there may
be cases where a single file has so much disk access, that it may justify being
on a drive by itself, because the accessing anything else on that drive will
impact the accessing of that file.
Copy Upgrade CDs to Disk
Copy the upgrade CDs to disk. This involves copying all of the upgrade CDs
to disk on the server to be upgraded.
The upgrade will be faster for the following reasons:
Reading from disk is much faster than reading from CD.
You may not have the required number of CD drives on the R/3 server.
Therefore, additional CD drives must be mounted on the network. You
would then have network traffic to contend with, in addition to slower
reading from CD.
You do not lose time manually changing the CDs.
Note
Head contention is not a new problem.
This problem existed fromthe early days of
disk drives on computers. The only
difference now is the drives are bigger.
Example
The system writes to the database log file
before the database is updated. Every
write to the database requires a write to the
log file. For applications with constant
order processing, such as large volume of
sales, the log file is active constantly. The
writing and reading of additional files to the
drive containing the log file will slow down
the updating of the database, impacting
performance.
32 SAP Upgrade Guide | Simplifying Your Upgrade
Requirement for copying the upgrade CDs:
You need sufficient free space on the server for the disk images.
Alternatively, you can copy the CDs to disk on a file server that has a fast
network connection to the SAP server being upgraded. Map or mount the
copies of the CD so you can access them from the SAP server to be upgraded.
The file server should be connected to the SAP servers to be upgraded by
100baseT (or faster) network.
Archiving
Archiving is the removal of old data from the live database to an archival
system.
Archiving old data can decrease the upgrade processing time. If there is less
data in the system to upgrade, the upgrade process will run faster. This is
especially true when major structural changes have been made. In this case,
the upgrade process converts the data in the old structure to the new
structure. Having less data to upgrade pays off, allowing the conversion to
run much faster.
A problem to consider is that the decision to archive before upgrading
depends upon what SAP release you are upgrading from. The archiving tools
have improved in later releases. There may be a business case for archiving
after upgrading rather than before upgrading.
Support Packages and Service Release
Support Packages for the Target Release. There are two phases to
installing Support Packages during an upgrade.
First, install the Support Packages for the target release as part of the upgrade,
rather than as a separate process after the upgrade. As of SAP R/3 4.6,
Support Packages can be installed as part of the upgrade process, saving time
after the upgrade. The upgrade time increases because of the additional time
33
to install the Support Packages, but the overall time decreases because the
Support Packages are installed faster during the upgrade than when done
separately after the upgrade.
If you will be installing the Support Packages as part of the upgrade, you
must have the Support Package files available during the PREPARE phase.
Second, towards the end of the learning upgrade, consider installing the latest
Support Package that have been released since the start of the learning
upgrade. Installing the latest Support Packages is especially beneficial if a
long period of time has passed since the start of the learning upgrade and
many more Support Packages have been released.
Then, perform a combined QA test of the learning upgrade and the Support
Packages.
In the validation upgrade and later upgrades, install up to the last Support
Package installed as a part of the upgrade.
Service Release. There is a free performance improvement that all
customers should use, that upgrades to the latest Service Release of the target
release. For example, when upgrading to SAP R/3 4.6C, upgrade to 4.6CService
Release 2 (4.6C-SR2), rather than the base SAP R/3 4.6C.
The Service Releases have the Support Packages integrated into the upgrade,
which saves on the additional time required to import and activate the
support packages separately. For example, this step could take as much as
eight hours versus 4.6C-SR2,which contains Support Packages up through 15.
This amount of time will only increase as the number and size of the Support
Packages increase.
Replacement Server
If you will be replacing your production server with new hardware, you have
another alternative.
Perform a system copy of the old production server to the new production
server, and perform the upgrade on the new production server. The process is
basically as follows:
Restore the production server onto the new server.
Take the old server offline.
Upgrade the new server to the target release.
Put the new server online.
34 SAP Upgrade Guide | Simplifying Your Upgrade
This gives you the following advantages:
The old production server and database is still intact.
• The pre-upgrade backup time is no longer critical.
• If you have to abort the upgrade, the old server with the pre-upgrade
system is immediately available. You do not have to restore the
system.
The upgrade can begin faster
• As you have the old production system intact, the length of time it
takes to run the pre-upgrade backup is no longer critical. It is done
independent of the upgrade.
You do not have to migrate to the new server as a separate task before the
upgrade.
You can practice the upgrade on the actual production server, to get
accurate timings.
Options to Reduce Backup Time
A critical part of the upgrade process is backing up the system before starting
the upgrade and after the upgrade is completed. The time it takes to perform
the backup increases the overall time to complete the upgrade.
There are several options to reduce backup time, including backing up:
To a second server, and from that server backup on tape
The backup of the data on the second server does not affect the upgrade
on the SAP server. You will need a fast network connection to backup the
database to the other server.
To multiple fast tape drives in parallel
The database to disk on the R/3 server
If possible, back up the database in parallel.
35
From a broken mirror
As part of various high-availability configurations, such as triple mirror,
the backup is almost instant to the SAP system. The actual backup ismade
off the broken mirror by another system, and thus does not affect the SAP
system. However, as the method and technique is very specific to the
vendor and product, we do not discuss the details in this document. If
you have a high availability environment, check with your vendor for a
way to reduce the SAP downtime during database backup.
The cost of backing up from a broken mirror is when you reattach the
broken mirror to the mirrored set. There will be a significant performance
impact as the broken mirror is synchronized to the current data.
Customer-Based Upgrade (CBU)
There is another option, which has the potential of significant reduction in the
upgrade run time. This is the Customer-Based Upgrade (CBU).
However, the CBU is a very different process and requires SAP Basis
consultants who have been trained in performing a CBU. The CBU upgrade
landscape is also very different from a traditional upgrade landscape.
A CBU is a special upgrade procedure that aims to significantly reduce
downtime when upgrading a production system. The downtime reduction is
achieved by creating an export at the customer site, which replaces the
substitution set imported in the EU-IMPORT phases. This export already
contains all customer-specific adjustments to the repository, which are
normally made during the upgrade. The customer-specific export removes
the need for performing several tasks on the production system when you use
a CBU.
As can be seen in the diagram, the CBU is a different process than the
standard upgrade.
36 SAP Upgrade Guide | Simplifying Your Upgrade
Prerequisites
You must meet the following requirements before you can perform a CBU:
Must be able to make a quick copy of the production system
After the first copy of the production system ismade, the repository of the
production system must be frozen.Any transports and corrections that are
made in the production systemafter the copy ismadewill be lost, and need
to be repeated after the upgrade.
The hardware you use to upgrade the secondcopymust be the same as the
hardware of the production system. This is the only way you can reliably
estimate the downtime needed for the (platform-specific) load generation.
For more information on CBUs, go to http://service.sap.com/upgrade and then
select Customer-Based Upgrade.
For more information, contact SAP consulting.
New Technology and Methods
SAP is constantly working on techniques and methods to decrease the time
that it takes to upgrade an SAP system. Check the SAP upgrade web page at
http://service.sap.com/upgrade for new methods that were released after this
guide was written.
SAP Upgrade Services
SAP has several services that are available to assist customers in doing an
upgrade. These are:
Upgrade Angel Program
GoingLive Functional Upgrade Check
Remote Upgrade
As an SAP customer, you should take advantage of these services, especially
the Upgrade Angel program and the GoingLive Functional Upgrade check,
available free of cost. Please check with your SAP account manager for
specifics of your contract.
Please also check with your SAP technical account manager for any other
upgrade services that are available from SAP.
37
Upgrade Angel Program
This service is included as part of your annual maintenance fee. It facilitates
problem resolution and escalation for customers for the upgrade of the
production system. It is offered by SAP America Customer Support.
A Customer Support angel will be assigned to your account to do the
following:
Monitor critical SAP customer messages daily
Provide you with weekly status updates for each issue
Communicate escalation issues
This gives you a single point contact for support and service issues.
See SAP Notes 161919 and 30068.
Note 161919; description of GoingLive/Upgrade Angel Support Program
Note 30068; registration form for the GoingLive/Upgrade Angel program
GoingLive Functional Upgrade Check
This service is included as part of your annual maintenance fee.
The underlying concept of the SAP GoingLive Functional Upgrade Check is
to ensure smooth operation of your mySAP.com solution by taking action
proactively, before severe technical problems occur.
The GoingLive Functional Upgrade Check is made up of three sessions
(Planning, Analysis and Verification)—two sessions (Planning and Analysis)
before the upgrade and the other (Verification) after the upgrade.
Planning Session: This session should be performed as much in advance as
possible when the upgrade is first being considered.
Analyses compatibility for the target release with regards to connected
systems in the Solution Landscape, OS version, DB version, installed Add-
Ons, Plug-ins, Country Versions, and so on.
Analysis Session: It is generally performed two months before the
production upgrade (consider lead time for hardware procurement).
The focus is on resource planning and system configuration.
There is a high-level hardware plausibility check (this is not a hardware
sizing exercise).
Potential resource bottlenecks are identified.
Necessary changes will be recommended to prepare the system for the
productive use of the new release.
38 SAP Upgrade Guide | Simplifying Your Upgrade
Verification Session: Generally performed four to six weeks after the
production upgrade, and the recommendation from the analysis session
implemented.
Comparison of performance with results prior to upgrade
Recommendations on configuration and optimization
More information and ordering . For more information, see the GoingLive
Functional Upgrade Check web page at:
http://service.sap.com/goinglive-fu
To order a GoingLive Functional Upgrade Check, contact SAP Customer Care
Center at least eight weeks prior to the planned upgrade of your production
system.
For customers of value-added resellers (VARs) such as CBS customers in the
US, special conditions apply. Contact your VAR.
Remote Upgrade Service
Remote Upgrade Service is a technical upgrade that is performed by SAP
remote consultants. Pricing is based on the complexity of the customer’s
environment.
SAP performs the technical upgrade of your system, allowing you to focus on
the functional and training side of the upgrade. You are still responsible for
resolving object conflicts.
See SAP Notes 106447 and 84044.
The Remote Upgrade Service is an attractive option for CBS sized customers
with small or non-existent mySAP Technology group.
For more information see the Remote Upgrade Service web page at:
http://service.sap.com/remoteupgrade
Resources
The following list shows some of the resources you can use as you prepare for
your upgrade of SAP. These resources include:
Your installation partner
Customers and others you have networked with at customer functions and
conferences such as:
• ASUG
39
• TechEd
• SAP training classes
SAP Service Marketplace, at http://service.sap.com
Other web sites, news groups, and lists
• http://www.sapassist.com
• http://www.sapclub.com
• http://www.sapfans.com
• http://www.SAPpro.com
Other consultants
The ASAP for Upgrade
• ASAP for Upgrade Roadmap
• ASAP for Upgrade Project Plan
• Installation manuals
Tools CD from the U.S. Upgrade Competency Center.
These are made available to your SAP America technology consultants.
Installation manuals
• Printed from the CD or
• Downloaded from SAP Service Marketplace at
http://service.sap.com/instguides
40 SAP Upgrade Guide | Simplifying Your Upgrade
SAP Customer Service
• Upgrade Angel Program (SAP America)
• Upgrade Going Live Functional Upgrade check
• RemoteUpgradeService
Relevant SAP web page aliases
Entered as http://service.sap.com/, for example
http://service.sap.com/upgrade
Bibliography
The Essential Guide to SAP R/3 Upgrades, SAP Professional Journal,
http://www.SAPpro.com
upgrade Upgrading SAP systems
goinglive-fu Going Live Functional Upgrade
Check
instguides Installation and upgrade guides
notes SAP Notes
noteassistant Note Assistant
ocs Online Correction Support
ocs-download Online Correction Support,
downloads
releasestrategy Contains matrix of R/3 release
from/to upgrade paths
remoteupgrade Remote upgrade service
sizing Sizing information and QuickSizer
tool
supportservices
41
Appendix
Excerpts from an Upgrade Script
The following excerpt shows you some of the items you might find in an
upgrade script. Note that this example is just a sample to show you what a
script looks like and how parts of the script can be constructed. A full script is
very long.
Task Person Responsible Time Completed
Preparation
Environment
Apply NT service pack XX Gary
Apply SQL server, service pack
XX
Gary
Check and clear required drive
space
Gary
Create directory \usr\sap\put Gary
sappad.exe should be in the
executables directory
Gary
Identify customer changes
Code: Collect and identify changes Sheryl
Code: Identify which code
might/will be required to be
reapplied
Sheryl
Configuration
Upgrade GUI Claudia
Upgrade team
Server
Test users
All users
Upgrade workstations
Test access to Upgrade Assistant:
from desktop
Test access to Upgrade Assistant:
From phone dial-up through
firewall
R/3 Preparation
42 SAP Upgrade Guide | Simplifying Your Upgrade
Update the kernel Gary
Download and unpack kernel
from SAPSERV
Back up existing kernel
Stop R/3 services
Existing file xxxxx must be
renamed before the copy
Copy new kernel to the kernel
directory
Restart R/3 services
Update SPAM Gary
Update tp.exe Gary
Install sw for Upgrade Assistant
PREPARE phase
Run PREPARE program
Document and resolve problems
pointed out by the PREPARE
program
Upgrade phase
Preparation for upgrade
Security
Lock out all users not on the
upgrade team
Gary
Remove “everyone” permission
from directories:
Sapr3e (documentation)
SAP share (for outbound extract
files)
Tax (tax program)
Back up the system
Database (2 hrs)
Operating system files (30 min)
CONTINGENCY: Backups must
be successful
Shut down
Task Person Responsible Time Completed
43
Shutdown, cancel, or reschedule
all background jobs scheduled
during the upgrade period
Sheryl
Execute upgrade
Monitor upgrade process Gary, Sheryl
CONTINGENCY: If there is a
hardware failure during the
upgrade, initiate recovery process
After upgrade program completed
Back up the system
Database (2 hrs)
Operating System files (30 min)
Import upgrade transports
generated from earlier upgrade
Apply support packs
Back up the system
Database (2 hrs)
Operating System files (30 min)
Post-upgrade
Unlock user access for regression
testers
Gary
Regression/Acceptance test
Regression test is performed on
the test systems, the acceptance
test is performed on the dress
rehearsal upgrade and the
production system upgrade.
Functional team execute scripted
tests
Review of tests and sign-off by
functional owners
Claudia, Mark, Andrew, Todd
CONTINGENCY: If acceptance
test fails, initiate recovery process
Recovery will take 5 hours
from the point of decision to
initiate recovery.
Task Person Responsible Time Completed
44 SAP Upgrade Guide | Simplifying Your Upgrade
Inserted note on the
production system, depending
on when the acceptance test
is done and the size of the
database, this recovery may
extend into the expected
workday.
Post-acceptance test
Reschedule background jobs that
were cancelled or rescheduled
before the upgrade.
Create system message
announcing the upgrade.
Send e-mails to people on the
notification list for a successful
upgrade.
Unlock user access for all users
Contingency
Prepare
Gather all material required to
perform a recovery
Evaluate
Present reason for potential
upgrade failure
Team members evaluate
Team members decide if a failure
decision is to be made
If required contact appropriate
functional manager(s)
Obtain management concurrence
to restore
Walt
Notify
Contact all functional owners and
managers on abort notification list
If the recovery is as a result of a
nonacceptance from the
regression test, the recovery may
extend into the expected workday.
The appropriate people need to be
notified why the system is not up.
Task Person Responsible Time Completed
45
Change Documentation
What. When making a change to standard SAP programs, we recommend
that you document the changes in theABAP code itself. In addition you
should have the following:
Change document; describing the change,what it is, why itwas made, any
other programs and/or objects which were changed as a part of the
change. This document should allow you to recreate the change in its
entirety.
QA document, especially important for controlled environments such as
aerospace industries, defense contractors, pharmaceuticals, and so on.
Why. The reason for making this documentation in the code is that paper can
get lost. If this information is entered into the code, along with the changes, it
will not get lost. If you have the code, then you also have the documentation.
The documentation provides –when you upgrade and the PREPARE
program identifies an object conflict – the ability to identify why the
change exists in the system. From this you can determine if the change
either:
• Is a part of the upgrade, and the object can revert to SAP standard.
• Is not a part of the upgrade, and needs to be reapplied, and a
transport generated.
As a general rule under time pressure, documentation gets the last
priority. In many cases, the management tells the programmers to fix the
problem and document it later. However, later never comes, as there is
always something more important to do.
Memory is not perfect. In a few months, the programmer may not be able
to remember the details of the change. This situation can become worse if
the programmer was a consultant and has now left your engagement, or
was an employee that has left your company. You may have a difficult
time finding that programmer again.
Send e-mail to people on the
upgrade-aborted distribution list.
Recover
Expected time to restore database
and operating system files to prior
release is 5 hrs.
Execute system recovery process
including OS files.
A recovery script is referenced
Task Person Responsible Time Completed
If the information is not
available, you could easily
spend a man-week (or
more) investigating a single
undocumented change. The
following questions arise:
What is the change?
Why is the change there?
Is there an SAP Note that
was the source of the
change?
What other program(s)were
affected?
Is the change implemented
in the upgrade?
If there are many such
undocumented changes, the
amount of time these
investigations could take would
require the upgrade be
rescheduled, and the cost of your
upgrade would be increased by
the effort of the investigation and
the delays.
46 SAP Upgrade Guide | Simplifying Your Upgrade
How. When making a change to standard SAP programs, we recommend
that you document the following in the ABAP code itself:
Date the change was made
Who made the change
The SAP Note number that specified the change
Your internal change document number, see below
Your internal QA document number that you use to document changes
made to your system
If the change is being made for reasons other than an SAP Note, then create
the design documents and the reason that the change is being made.
A new alternative is the Note Assistant that eliminates manually applying
a note. See the Note Assistant section below.
When. The documentation in the code should be the first thing that is done to
the code.
New Information
Note Assistant
The Note Assistant is a new tool for implementing and handling SAP
Notes. It is available for SAP R/3 Releases 4.5B, 4.6B, 4.6C. The Note
Assistant eliminatesmanually entering a note, and the error that can occur.
The Note Assistant determines the appropriate correction instruction for
that version of your SAP solution and issues a go-ahead for you to proceed
with implementing the correction.
One of the most important capabilities of the Note Assistant is its ability to
recognize dependencies on Support Packages, upgrades, and SAP Notes
that have already been implemented.
The Note Assistant is closely integrated with the Modification Assistant.
After you implement a Support Package, for example, any corrections
indicated in SAP Notes are displayed separately from your own
modifications, which makes the adjustment much more efficient.
For more information and to download the Note Assistant, see
http://service.sap.com/noteassistant
|
|
|
|
|
Responses
|
| Author: soumik roy 12 Aug 2008 | Member Level: Silver | Rating:  Points: 0 | Its a good one to know about SAP upgrade
upgrade_guide_v2.pdf |
| Post Reply |
|
|
|
 | | This thread is locked for new responses. Please post your comments and questions as a separate thread.
If required, refer to the URL of this page in your new post. |
|
|
|
|
Watch TV Channels
|