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
After Upgrade
Retaining older version system after the upgrade for about 2-3 months helps in resolving post-upgrade issues. The objective should be to minimize dual maintenance window.
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.
😎 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.
4 Comments
