MIGRATION - Upgrade of HCM from one release to other release using transport of copies mechanism
This document is based on a customer specific requirement which was undertaken in a project. It describes the method for migrating HR configuration entries, master data and payroll clusters from earlier release to new release. This explains the migration strategy and the procedure to be followed for migrating the configuration entries and the master data.
Note: This document does not discuss the technical upgradation that forms part of basis activities.
This can be considered if the following are applicable:
- Modules like FI, P2P, and SD are going through the Reimplementation cycle from earlier release to new release. How ever HR goes through an upgrade only. The reason being, in case of pure technical upgrade of entire system from one release to other release, all the modules configuration entries and master data will get upgraded.
- Functional upgrade happens for selective modules of HCM post the migration of configuration entries, Master data, Transactional data (Payroll clusters) from earlier release to new release.
Note: Post the upgrade the configuration entries and master data from earlier release to new release is ready to use for the functional upgrade
This document explains the step by step approach of migrating configuration entries, master data and payroll clusters from release like 4.7 to release of ECC 6.0.
3. Overall Approach
3.1 Migration Process: Process flow
High Level Process steps are as below
3.2 Step By step Process flow
Process Step #
Process Step Description
Migration of Configuration
Migrating the configuration from earlier release to new release using RFC
Migration of Custom Objects
Movement of Custom objects from one release to another release using transport of copies
Migration of Master data
Migrating master data using transport of copies from old release to new release
Migration of Cluster data
Migrating Cluster data using transport of copies from old release to new release
Configuration of new enterprise structure
This is applicable in the scenarios where the Enterprise structure changes in new release.
Mapping of master data with new enterprise structure
Master data to be mapped as per the new enterprise structure in new release
3.2.1 Migration of the configuration:
The configuration entries to be migrated first the reason being this serves as foundation for other objects to move.
- Identify the standard objects to be migrated
- Arrive at the sequence of migration
- An RFC connection to be established between the earlier release and new release. Use transaction SM59 by taking help of basis consultant
Note: It is recommended to use production system of earlier release. The reason being the production system has the updated entries
- The migrated entries will have to undergo testing and quality checks before moving it to the new release production system
Configuration entries in the view tables are to be migrated in the identified order. We could use either IMG or transaction SM30.
Note: It is recommended to use IMG. Using transaction SM30 is error prone. The reason being, we make fewer mistakes in following the sequential order.
The following is the step by step procedure to migrate configuration. All the steps have to be carried out in the new release.
- Go to IMG and open the node to view the configuration entries
- Configuration entries in the view tables has to be migrated in the identified order
- Select the node that has to be migrated
- Go to Utilities --------> select Adjustment. Below screen will be displayed
- This will populate a window to select the source system
select the source system like 4.70 Production system in the above selection
- You would now see the overview of the table entries from the source system to target entries
- The table entries that need to be adjusted can be selected. If all the entries are needed then “select all” option from Edit menu. This method will not delete or over write the existing entries in the target/source system. It is possible to differentiate the entries between the target and source system with different colors.
- Source system: entries with green.
- Target system: entries with orange.
- After the necessary selections execute the “adjust” button. This action will bring you the following screen.
- Execute the push button “copy all” which copies all the entries that are selected from source system to target system.
- Now we can able to view the entries that are adjusted.
188.8.131.52 Draw backs of configuration migration:
- This method of adjustment does not support configuration entries that are related to creation of Personnel subarea, wagetypes, absences, work schedule rules
3.2.2 Work Around
In the views for Personnel subarea creation, wagetypes, Work schedules the option of adjust is not available hence the table entries can be migrated by using some workaround.
The table entries related to creation of personnel subarea, wagetypes and work schedules has to be locked in a request and to be transported to the target system.
The detailed methodology is as follows:
- Execute transaction SE10 and select create option. This pops up a window as shown below
- Create the request by selecting transport of copies as specified in the above screen
- The below screen shows that the request has been created
Double click on the request created. This Pops up the request properties, contents and Documentation tabs. Select the contents tab and enter the tables names to be migrated
Note: The program ID should be R3TR and the Object ID differs based on the object.
Eg: If we need to transport the table with contents use the ID ‘TABU’. If the table with the contents to be transported and use the ID ‘VDAT’ for views.
Draw back: If the structure of the tables has been changed from earlier release to new release then the entries has to be created manually in the new release.
3.3 Migration of Custom objects
- Customized Developments and the objects have to be migrated by transporting the customized package and the developments in specified sequence using a transport request from existing production system to ECC 6.0 Development system.
3.3.2 Drawbacks of migration the custom objects:
- During Migration of custom objects from one release to another release there would be Unicode conversion related issues
- This will have to be addressed by the development team by changing the attributes of each object
3.4 Mapping of screens from old release to new release
It is a good practice to do the screen checks. It is strongly recommended to compare the screens of infotypes that are used between old and new version. Any errors omissions can be trapped at this point of time. Of both the versions. Table T588M could be used for this.
3.5 Migration of Master Data
Master data can be migrated from one version to other version by creating a transport request in old version for each database table in required sequence and transported to new version.
- Ø Execute the transaction SE10 and create a request for transport of copies as specified in the earlier section.
- Ø After the request is created. Double click on the request
- Ø As specified earlier the program and object types should be R3TR TABU respectively. Select the function and specify the table keys as ‘*'
Note: Table keys should be * so that all the entries can be migrated to the target system
- Ø It is mandatory to select the target system in properties tab.
- Ø Once the above settings are done we can view the transport request with the tables and table entries
The above request has to be transported to the target system so that the table entries can be viewed in the target system
3.7 Migration of Cluster data:
There are two options for migration of cluster data:
- Option A : Custom program
- Option B: Transport request.
Custom program could be written in ECC 6.0. The high level specification for custom program is as below
Point 1: Create a BDC in the target system.
Point 2: This program will call for required employee numbers in XL sheet
Point 3: Copy the entire cluster from earlier version to new version by using RFC.
Create a transport request for the cluster data in the source system and transport to the target system
It is recommended to use Option B the reason being all the entries will be moved sequentially. Option A is error prone.
- Create a transport request with transport of copies option for cluster table PCL2. This is similar to the one described above for master data migration.
3.7.1 Errors and solutions:
Migration of master data and cluster data may crop up few of the following issues.
The Issues with the solutions are as below
Error 1: Master data – Data may not be displayed in Overview option of the infotypes in the transactions PA30 or PA20
Report ‘RPUEVSUP’ to be executed by specifying employee number and country grouping in the selection screen.
Error 2: Actions can’t be performed in PA40 or PA30 transactions. Error will be “Organization reassignment not permitted”.
Report RPUPAV00 to be executed by passing the parameters of PERNR and MOLGA in the selection criteria. This will update the field VIEKN in PA0003 (Payroll status). Configure feature IVWID accordingly. This will resolve the issue of organization reassignment not permitted.
- i) After migration of master and cluster data the payroll postings may not be initialized.
Usually this happens after any upgrade. Report ‘RPU46CX_CENTRAL_PERSON_ONLINE’ has to be executed for the employee numbers. This program creates Object central person (CP) for employee data, for respective object Person (P).
Errors while importing the custom infotypes
- ii) Dump in the payroll driver and the other include objects.
The entries in the table T596F were not transported from old release to new release. This is because of the absence of the above table in IMG. Hence all the entries of this table have to be locked in a request using transport of copies methodology.
- iii) The PA and the payroll features were not functioning properly.
All the features that were transported needs to be activated again as the status in feature will be ‘save’ instead of ‘active’.
- iv) The table maintenance dialogue wont be appearing for the custom tables
This can be addressed by generating the maintenance dialogue explicitly for each custom table.
- v) Absence of SAP Script forms
Even though the custom packages are migrated there may be chances of unavailability of SAP scripts in new release. Hence all SAP scripts to be locked in a separate request and to be imported to new release.
3.8 New Enterprise Structure
This has to be followed only when there are changes to the enterprise structure in new release
The existing enterprise structure to be mapped with the new enterprise structure which will be designed based on the various ELCM processes. The new structure has to be configured in the new release.
3.9 Upload employee master with new enterprise structure
Changes in the configuration due to the additional processes as part of the project will have an impact on the data. Therefore the data related to the configuration changes are mapped and a program/LSMW is built. This program will create an action in PA40 screen, as ‘Go-Live’ which will update the new Enterprise structure, personnel structure, and the Organization structure in respective infotypes by changing the corresponding master data based on the mapping template.
The following are the impacts due to the changes in enterprise structure:
- Payroll process
- Payroll posting
- Custom reports
184.108.40.206 Impact on payroll process
Changes in enterprise structure may have an impact on payroll. The impact will be with respect to retroactive accounting as the old company code/Personnel Area may not be needed in the new environment. This can be addressed by enhancing the include RPCGET00_FUWPBP in HINCALC0 program. The enhancement should have the logic of converting old Company code to new one.
220.127.116.11 Impact on payroll posting
Payroll postings will have an impact in case of retroactive accounting and this can be addressed by using the enhancements in RPCIPE00.
18.104.22.168 Custom Reports
Due to the changes in the enterprise structure the existing custom reports has to be changed based on the input and out put considerations
- The configuration data can be moved easily
- Flexibility to change configuration after migration
- Its easy and adaptable process
- Master data is moved easily because it is copy of AS-IS. Hence chances of errors can be reduced
- Payroll cluster (transaction data) can be moved with one single transport request hence the mismatch in the sequential numbers can be avoided.
- The other modules can be Re implemented with out any integration issues.
The following are the results from this Research.
- Movement of the configuration entries and developments from one version to other version using transport of copies.
- Migration of the master data and the cluster data.
- Set up new enterprise structure.
SAP‘S Upgrade and migration concepts are used to upgrade the system. However technical upgrade is not fruitful in the cases like reimplementation of other modules and change in the enterprise and organization structures. In this case it’s always time consuming. Migration can be executed better, cheaper and faster than a technical upgradation.
When determining the right solution for the operations it’s important to consider the master data, transaction data and reimplementation considerations.