SAP Data Migration â The Data Migration Plan (Part 2)
Before you embark on your projectâs first data migration test cycle, your data migration plan will probably start out as a simple list of preparation steps, data load dependencies, and cleanup steps. As you progress through your several data migration test cycles, your plan should evolve into a rather complex list containing load methods, responsible persons, historical data volumes, historical execution times, steps that need to be modified and additional steps that need to be added.
The Data Migration Preparation Phase
Before you actually start the data migration main course, you will probably want to execute a series of preparation steps. Some of these preparation steps may have a significant lead time; while others may require a system reboot to take effect. Make sure that you carefully plan accordingly. Here are some data migration preparation steps that I have found useful:
The BASIS team may want to configure the data migration target client to have less dialog processes and more background and update processes. This configuration can significantly improve data migration performance, especially if you have the opportunity to parallel process IDOCs. In a Virtual Machine environment, the infrastructure team can even provision additional processors and memory. You may also need additional disk space to handle large upload files, and any intermediate files that a load program might need to create.
-
Configuration for IDOC processing
If a data migration process involves creating and processing IDOCs, you may need to configure the ports, partner profiles, message types, and processing modules. My preference for IDOC triggering is by using the ABAP program RBDAPP01 rather than immediate triggering. This allows me to exercise the most scheduling control over the background processing options.
-
Change Pointers
During a data migration turn off change pointers. Creating what could potentially be hundreds of thousands of change pointer records that are never going to be processed is an overhead burden on system performance and disk space that you do not need. If the migrated data needs to be sent to external systems, manually send the data after the data migration is complete.
-
Set the Correct Open Posting Period
Some of the transactional data will want to post into an open financial or manufacturing posting period. You will want someone from the business to make sure that the correct posting periods are open for business.
-
Configuration Settings
Sometimes, special temporary functional configuration settings are made to facilitate the data migration process. Several functional analysts may be responsible identifying and setting these prior to the start of data migration. As these are temporary configuration settings, it is expected that they will be set to their production values after the data migration is complete.
-
Basic Setup Data
Some data migration objects are dependent on reference data â a template from which new data migration objects can obtain some of their default values. You will want to make sure that those who are responsible for setting up this reference data have completed their task before you start the actual data migration. Sometimes this data is moved from the Golden Client into the target client via ALE, so you may need to set up RFC destinations, ports, distribution models, etc.
-
General user lockout
All users except for the data migration user should be locked out of the data migration client during the actual data migration activity. It is impossible to verify that we moved exactly $15,386,254.23 in inventory from the source system to the target system if users are performing material movements in either system during the conversion.
-
Connections to External Systems
Depending on what connections to external systems are doing, you may want to make sure that they are disconnected prior to the start of data migration. This will ensure that inbound interfaces, which may either modify existing migrated data or add new data, are disabled.
The Data Migration Phase
Automated data migration tasks for a single object (e.g. customer master data) usually include some or all of the following:
- Creation of an upload file from the source system
- Technical validation of the upload file
- Functional validation of the upload file
- Execution of a technical object to load the data into the target system
- Technical validation of the migrated data
- Functional validation of the migrated data
- Collection and reporting of load statistics
- Analyzing the fallout
- Correcting the fallout
- Reprocessing the fallout
Checkpoints
Backup or Restore Points
Another activity that you should judiciously sprinkle into the plan is several backup or restore points. It is very painful to have successfully navigated seventy-five percent of the data migration plan, only to have the next load create a huge and unrecoverable mess in the target system. Without a backup or restore point available, you may have to wipe the slate clean and restart the entire data migration process again.
Depending on the target system and the facilities available, the backup or restore point could be a full system backup, a client copy, or a virtual machine snapshot. Whatever the means, make sure it is a part of your plan. Itâs really great if you donât need it. Itâs also really great to have if you do need it!
The Data Migration Cleanup Phase
When the data migration loads are finally complete, itâs time to exercise a series of cleanup steps. This is where we:
An Example Data Migration Plan
Click on the link below to access an example data migration plan. This plan is not a complete data migration plan, but is intended to demonstrate format and content.
Stay tuned!
In part 3 of this series on Data Migration, I will be discussing how to deal with fallout from automated data loads.
About The Author
Related Posts
- SAP ABAP/PI Developer Position January 26, 2015
- SAP IDOCs for Customer Number with different Sales Organizations to different External Partnerships February 7, 2012
- SAP EDI EDPAR Table Walkthrough â How to Cross Reference External Customer Number to SAP Customer Number (Part 2) February 1, 2012
- SAP EDI EDPAR Table Walkthrough â How to Cross Reference SAP Customer Number to External Customer Number (Part 1) January 26, 2012
6 Comments
Can you share the data migration plan for the user side not the consultant side as Iâm from user side and responsible for data migration?
I dont really much understand this data? I have some idea, but it was most helpful to everyone if it can explain it further. For us to learned more about this database. Right?
Thanks for sharing your experience and all the information. Not able to open the sample plan. Can you please email me the same.
hi. Thanks for the interesting articles! Could you please repair link to âSample Data Migration Planâ?
Thanks again, Ju
The link has been repaired. All you need to do is resubmit your information in the form.
Hi Good Day, I am new to DATA Migration using ASAP methodology. I am into a project for migration of data from non-SAP to SAP system. I need help for project preparation which is phase 1 in ASAP methodology. Please anybody share some .doc or .pdf about project preparation. Thank you.
Leave a reply Cancel reply
Looking for something in particular?
Categories
New Series: ABAP Tricks
Check out our newest blog series - ABAP Tricks and learn something new!
Other articles you may be interested inâ¦
DataXstream Workflow Troubleshooting Guide
What Does a Software Provider Need to Know Before Beginning the Product Certification Process with SAP?
CA Technologies Integrates Workload Automation for SAP Business Warehouse to Unify Visibility and Improve Business Process Monitoring