You Should Know Before Upgrading To SAP ECC 6.0

You Should Know Before Upgrading To SAP ECC 6.0

If you are considering making the investment to upgrade your SAP environment, there are a number
of things you will need to know, including:
• What kinds of errors you are likely to experience
• What steps you can take to avoid or fix those errors
• What parts of the system will require the most rigorous testing
• What are among the top overall risks

With careful planning, you can save time, money, and employee‐ and business down time by having a
good idea what to expect during your SAP upgrade. Over the last several years, MyITgroup has very
successfully upgraded and implemented SAP systems for numerous customers in varying industries.  Our
goal is to deliver each upgrade successfully while mitigating risk factors to existing functionality, content,
and customized objects.  While every case is of course different, here are a few things that our
experience has taught us you will need to address.

1. Updating the new GUI release
To begin with, you should get your Desktop Support Group’s involvement. No one knows your
company’s personal computers and their applications better than them. They may have good ideas, and
should take the lead on how to package and deploy this upgrade to your user base.
Second, identify which SAP GUI components are needed (SAP has a 7.1 GUI installation guide available
for download) and determine which components which are needed now, and within the next three
years. It’s easier to push the update out all at once than to try to make additions later.
Third, you should make a plan for the technical packaging and deployment. This can be the most
challenging part of this upgrade. You need to consider:
• Your capability to build an upgrade package. 
• How you deploy the package. 
• Your network’s capability to handle these deployments.
• Your ability monitor statistics of your user base, particularly who is upgraded and who is not.
Then you need to decide on your rollout approach. Plan on rolling out to several small test groups to
start, and allow time for issues to surface and be reported. Don’t assume that if you don’t hear about
issues immediately that your first rollout went smoothly. Also, you should decide how you will support
your rollout. Make sure your help desk resources are prepared with solutions to all issues that came out
of the first rounds of testing, and plan to document and communicate new fixes that you uncover during
your rollouts.
Your business processes and customized SAP functionality should be tested thoroughly with the
upgraded gui before rolling out to any sites. Do not rush this process, as you may inadvertently disable a
large number of your SAP users, and overextend your budget to hire resources to fix.    

2. Know that your security will be affected during the upgrade
All SAP security will be affected during the upgrade regardless of source and target version of SAP. The
underlying USOB* tables will change. The changes to the Authorization Objects in the underlying USOB*
tables will affect the authorizations in the current Job Roles for those changed Authorization Objects. As
a result, current authorizations can and will be overwritten by new authorizations with different values.
New authorizations will also be added that did not exist before. All of these changes will need to be
adjusted and thoroughly tested.
We recommend executing the Security Upgrade process (transaction SU25) as soon as an upgraded
system is available. This process will identify all Job Roles that have been affected by the upgrade. At this
point, the security team will be able to get a good idea of the workload ahead to adjust and test
security. The security team can then develop a detailed project plan that will fit into the overall upgrade
project plan.
Then compare your affected source release Job Roles to the target release job role and implement
changes based on the initial security assessment.  Once this is complete, the adjusted and recreated Job
Roles can be generated and tested individually.

3. Do not rush out and pay to have your landscape capacity sized for your upgrade
Most hardware vendors are more than happy to provide this service to introduce your company to their
hardware. You should do this sizing as preparation for determining whether you need to procure any
new hardware. Large hardware vendors such as HP or IBM will be happy to assist upfront.   Both have
competency centers that specialize in sizing SAP clients.  
When performing an SAP upgrade, there may be a number of different upgrades you will need to do in
conjunction, including hardware, platform, or software releases. The best approach is to analyze each
upgrade separately and add the resulting requirements, if necessary. Hardware and platform vendors
provide their own upgrade information, and SAP performs regression testing of their standard business
test cases (about one hundred top transactions) and sums it up in notes that describe the influence of
the upgrade on CPU, disk, memory, and front‐end network in a hardware‐independent format. If you
have implemented the new release on your own hardware, you can quantify the influences much better
by benchmarking your key transactions in both releases as described above. Also, we recommend not
using the Quick Sizer tool, because your installed data is much more meaningful. 

4. Understand the transition path from SAP R/3 to SAP ERP

Thanks to proven standard tools available, the technical upgrade procedure has been significantly
improved. Based on customer and partner experience, upgrading from SAP R/3 to SAP ERP is simpler in
comparison to earlier SAP R/3 release upgrades. For the transition from SAP R/3 to SAP ERP, you may
want to consider the following.
Conversion of License Contract
All customers who previously signed SAP R/3 contracts must convert their contracts in order to use SAP
ERP and the supporting components. Of course, if you have already converted your SAP R/3 contract to
a contract for SAP ERP or SAP Business Suite applications (formerly called “mySAP.com” contract),
contract conversion is not required. To best evaluate your situation, you should contact your SAP
representative, who can provide you with all relevant information on your contract.
Scope and Procedure of the Upgrade Project(s)
Successfully executing an upgrade to SAP ERP 6.0 requires a well‐defined upgrade strategy that includes
an approach and project scope based on the circumstances and aims of your organization. The project
strategy has a great effect not only on project duration and effort but also on the immediate return on
investment of the upgrade. The upgrade strategy usually consists of several stages that progressively
expand functionality, increase business value, and prepare the organization for the transition to
enterprise SOA while minimizing risk. This process typically lasts three to five years and consists of three
distinct phases: the technical upgrade, functional enhancements, and strategic enhancements.

5. Estimating the effort of a Unicode conversion

Prior to adopting the universal character set standard ‘Unicode’ SAP installations were language‐
dependent. i.e. there were versions of SAP for every language and character set it supported. Further,
some character sets required more space to store each ‘letter’ and symbol in its alphabet, e.g. Kanji,
which lead not only to different character set representations but differing underlying language
structures as well.
This caused problems for multi‐national corporations where more than one language was required. It
also caused support problems because the SAP executable programs were language‐dependent. During
system‐to‐system data exchange, the possibility for corruption is also high. This is important not only
when multiple SAP systems‐sites are involved, but also when non‐Unicode SAP ABAP systems are
exchanging data with SAP Java systems. Java is a Unicode‐compliant language and is built on the
Unicode system. So there is a potential for error when non‐Unicode SAP ABAP Systems are exchanging
data with Unicode SAP Java Systems. To alleviate these and other issues, SAP has adopted the Unicode
standard for its applications built on ABAP.
The Unicode character set includes the alphabets and symbols of virtually all languages. Thus, Unicode
changes the need for differing installations based on a specific language by providing a common
character set for all installations.
Note: While SAP is adopting the Unicode standard, it is not immediately planning the end of
support for non‐Unicode Systems. i.e. both Unicode and non‐Unicode SAP Systems will be
supported in the immediate future. However, many of the NetWeaver applications rely heavily
on SAP’s Java applications to display data. Thus, even if you are not running multiple languages,
if you plan to use Java functionality in the immediate future, we recommend converting your
underlying ABAP systems to Unicode.
To estimate the level of programming effort required to ensure all of your SAP ABAP code is Unicode
compliant, one may calculate the development efforts for Unicode ‐ enabling a software component
roughly as follows:
a.) Based on the amount of numbers of average SAP programs that can be made Unicode compliant per
Person Day:
33 average SAP programs per Person Day or nearly 10.000 lines of coding per Person Day
b.) Based on the amount of Unicode ‐ based errors that can be corrected per Person Day:
6 Unicode ‐ based errors per Person Day
This should be used as a base start because every environment has different levels of complexity.    
The Unicode enabling process can be summarized roughly with two major steps:
Step 1 (This step can be executed in a non‐unicode system)
• Adapt all ABAP programs to restricted unicode syntax and semantics
• Set the Unicode flag for all programs (reports, function pools, classes, interfaces, type pools)
o Permission to run on a unicode system
o Additional restrictions at compile and at run time (in unicode systems as well as in non‐
unicode systems)
o Check for remaining static errors
Step 2
• Set up real unicode system
o Unicode kernel + unicode database
o Only ABAP programs with unicode attribute are executable
ƒ Execute final runtime tests in unicode system
ƒ Detect dynamic errors