Skip to Content

Important points for planning R/3 Upgrade project

As the mainstream support for SAP R/3 4.6C is over by Dec 2006 and the extended maintenance will also be over by Dec 2007, it’s important or in a way imperative to upgrade from R/3 4.6. The version we upgrade depends on lot of factors and is entirely driven by Organization’s need. This blow highlights some of the critical factors that affect the success of the upgrade project. This is more from project planning point and has minimal technical contents.

1) Technical or functional

The scope of an upgrade project is determined on the basis that is it a pure technical upgrade or a functional upgrade is also combined. In technical upgrade it’s mainly the system upgrade and no new functionality is implemented. More or less following teams are involved in an upgrade project. The task list is not complete; it’s just to give an idea about the nature of work various teams will be involved in.

 

Sr. no Teams Tasks
1 a)      Unix b)      Basis c)       DBA Disk Space, Kernel upgrade, table space etc.
2 Technical SPDD, SPAU, cloned program and Transport sequence
3 a)      Functional b)      Business community   Unit testing and Integration testing  

Also check for SAP GUI version compatible for the upgraded SAP version.

 

2) System landscape.

The system landscape design will depend on the project plan. To increase the availability of system for production support and new developments following dual system landscape helps.

Before Upgrade

image

After Upgrade

image

Retaining older version system after the upgrade for about 2-3 months helps in resolving post-upgrade issues. The objective should be to minimize dual maintenance window.

3) Dependent SAP systems (BW, SRM,)

The success of the upgrade project depends on the dependent SAP systems like SRM, BW and HR In some cases you might have to upgrade other SAP systems also if the compatibility is an issue. e.g. SRM 3.5 is has compatibility issues with ECC 5.0 .

Also a thought should be given on the sequence of the upgrade of these systems. R/3 should be the last one to be upgrade.

4) Dependent Non-SAP systems

The Non SAP system like Manujistic, Taxware, and Hyperion etc. also plays major role and it could spoil the whole upgrade experience. They are also critical because of the differences in Vendor there might be more time lag to find out the exact version or proper support on time.

5) Transport Sequence

Transport sequence is very important. If the changes had been done to the objects changed by SPAU or SPDD those requests should be the transported after the SPAU/SPDD transport requests.

Also important care should be taken after upgrade, that no request of old version should be moved in upgraded system like request created in 4.6 C be transported in ECC 5.0 (This causes dumps where we move transport which contains objects that have dictionary table changes)

6) Cloned program

Cloned programs are customer programs copied from Standard programs and then made to work for a customer. Cloned program are coded by copying the standard program to a Z-program, having the standard includes or standard function modules.

This causes issues after the upgrade as the standard includes or functional modules might not work with our custom code.

So make a list, before upgrade, of your entire cloned program and change the same and include them in the test plans.

7) Unicode compliance and Obsolete ABAP statements

The amount of ABAP rework depends on if we are complying with Unicode. The switch to Unicode affects all statements where an explicit or implicit assumption is made about the internal length of a character in custom programs.

Also couple of ABAP statement / tables has become obsolete or more severe check is done during syntax check. E.g.

a)      STOP statement in methods

b)      Table M_VMVLA is replaced with SHP_IDX_GDSI and M_VMVLB is replaced with SHP_IDX_PICK

c)      Usage of Message number 000.

There could be much more example and is customer specific.

8) Test plan

Through test plan should be prepared both for functional Users and for Key Business Users both after development and test environment upgrade. If possible a tool (e.g. RBE – Reverse Business engineering) should be used which will give you an idea of the important transactions based on number of times it is used or the transaction run during month end or fiscal year end. These transaction should be a part of testing plan.

9) Post-upgrade activity

After the upgrade following points should be planned

a)Job release Strategy

b) Security Roles 

There could be more points to upgrade planning but I hope above points will help in better upgrade planning.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Raj Sam
    Hi Amit,

    We are doing 4.7 Upgrade. Your blog points out tricky issues during upgrade. Thanks for sharing your experience..

    After upgrade Production server would be part of 4.7 Transport domain. How to view 4.6 – old transport logs. Should the Transport dir to be merged ?

    Thanks,
    Raj Sam

    (0) 
  2. Rafal Drezek
    Hi,
    Information published in this blog is interesting, but are you going to continue with it? For me it seems to be the first page in the long story.
    For the unicode part I will add that if MDMP is used then Unicode conversion is mandatory and Upgrade to ERP 6.0 (mySAP 5.0) has to be done in two steps: system upgrade and unicode conversion

    cheers
    Rafal

    (0) 

Leave a Reply