Loading data into the SAP system is not an instant process. It can be a project by itself that carried out in parallel to the functional implementation. I strongly believe that data Migration and conversion is a critical process during SAP implementation. In the case of legacy systems, the data migration will be an inclusive and intense exercise that must be carried out cautiously.
This blog provides a high-level procedure to transfer data from the legacy system. Designing and Implementing Migration framework, Design of Extract, Transform and Load (ETL) flows, Implementing migration programs, mapping, and cleansing. Data migration includes data definition, conversion, and loading using tools like IDocs, SAP LSMW, and Custom programs.
I also believe that data conversion will become a key component of data migration. Data Conversion process converts the data format that can be used in the SAP system. For example length of Material in the legacy system might be 15 numeric but in SAP it is 18 Alpha Numeric. During the Realization phase of the project, we will identify these outliers to avoid a costly and time-consuming issue at a later phase of the project.
We will follow the following two types of migration:
Manual: For the data complex in nature or very small by volume, the manual load is preferred.
Automated: For a huge volume of data. In this process, data is extracted from the Legacy system, translated and loaded into SAP system using LSMW, BAPIs, IDocs or custom programs.
Like in every other system, in SAP we have 2 types of data:
- SAP Master Data, that is not changed often and
- Transactional data, the data created in SAP (or in the legacy system) as a result of daily business transactions.
Below is the list of key steps along with the owner of those steps are identified.
|Steps||Primary Owner||Secondary Owner||Phase|
|High Level data Migration Plan||Vendor||Client||Prepare|
|Detail Data Migration Plan||Vendor||Client||Explore|
|Approve Data Migration Plan||Client||NA||Explore|
|Data Migration Templates for Master & Transaction Data||Vendor||Client||Realize|
|Identify Data Conversion Fields||Vendor||Client||Realize|
|Gap Analysis (Gap Report)||Vendor||Client||Realize/Deploy|
|Dependency Analysis (Dependency Report)||Vendor||Client||Realize/Deploy|
|Plan to populate Missing Information||Client||Vendor||Realize/Deploy|
|Provide data in the specified format||Client||Vendor||Deploy|
|Mock Data Load||Vendor||Client||Deploy|
|Identify Errors in data load||Vendor||Client||Deploy|
|Fix the errors||Client||Vendor||Deploy|
|Repeat Data Load & error fixing||Respective||Respective||Respective|
|Provide Final Data||Client||Vendor||Run|
|Load Final Data||Vendor||Client||Run|
|Provide Delta Data (in case of the parallel run)||Client||Vendor||Run|
|Load Delta Data (in case of the parallel run)||Vendor||Client||Run|
|Provide data load confirmation||Client||Vendor||Run|
Here is the schematic diagram of the overall data migration & conversion process.
In case of modular approach, the same set of steps will be followed for each module and go-live. The only exception would be for Master Data. All the master data should be migrated to the target system during the first module go-live. Any changes in the master data should be replicated to either system at regular intervals. For example, if a customer contact details are changed in the SAP system, it should be replicated to the legacy system as well. The process of this replication can either be automated or manual depending upon the change volume and the complexity of the change. On the other hand, if an item description is changed in the legacy system that is not yet to go-live in the SAP system, this change can be replicated during the go-live process of the Materials Management.
In conclusion, these steps are mandatory and built upon the previous steps. We should also note that the data migration will make or break the go-live process.