Because the mainstream support for SAP R/3 4.6C ended in Dec 2006 and the extended maintenance will end in December 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 the organization's need. This blog highlights some of the critical factors that affect the success of anyupgrade project. This is more from project planning point and has minimal technical content.
1) Technical or functional
The scope of an upgrade project is determined by whether it is a purely technical upgrade or also a functional upgrade. In a technical upgrade, it's mainly the system upgrade and no new functionality is implemented. More or less, the 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) &...
To continue reading for free, register below or login
To read more you must become a member of SearchSAP.com
nbsp; 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 a 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 the older version system after the upgrade for two to three 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 .
Some thought should be given to the sequence of the upgrade of these systems. R/3 should be the last one to be upgraded.
4) Dependent non-SAP systems
The non-SAP systems like Manujistic, Taxware and Hyperion etc. also play major role and could spoil the whole upgrade experience. They are critical because due to 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.
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 programs
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, because the standard includes or functional modules might not work with our custom code.
So make a list, before upgrading, 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 whether 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
A thorough 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 that will give you an idea of the important transactions based on the 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, the following points should be planned
a)Job release strategy
b)Security roles
There could be more points to upgrade planning, but I hope the above points will help in better upgrade planning.
Amit Jain is a SAP technical consultant for Wipro Technologies.
This content is reposted from the SAP Developer Network.
Copyright 2007, SAP Developer Network
SAP Developer Network (SDN) is an active online community where ABAP, Java, .NET, and other cutting-edge technologies converge to form a resource and collaboration channel for SAP developers, consultants, integrators, and business analysts. SDN hosts a technical library, expert blogs, exclusive downloads and code samples, an extensive eLearning catalog, and active, moderated discussion forums. SDN membership is free.
Want to read more from this author? Click here to read Amit Jain's Weblog. Click here to read more about ABAP on SDN.
