SAP MDG data migration – Part 2

[mageshwaran_subramanian]

The first blog in this series lists down the tools and techniques available for MDG data migration.

Various factors will have a say on what tool(s) can be leveraged to perform the Initial data load in MDG

1. Data quality


2. Total number of records


3. Data source: SAP vs Non-SAP


4. Governance solution scope: MDG-M/F/BP(CS)/RFM/EAM


5. SAP MDG landscape: MDG on SAP S/4HANA vs MDG on ECC


6. SAP MDG Implementation: on-premise vs cloud platform


7. Tool limitations

Is it possible to get dirty data into MDG as part of the initial data load? Yes, but it defeats the purpose of having MDG in the first place. Implementing MDG as a master data hub gives the opportunity to start fresh with cleansed data. So give data the respect what it deserves and commit to loading the good data into MDG.

If the data source is a non-SAP system, then a well-considered field mapping from source to MDG data model is required. Field mapping from ECC to MDG can be straight forward with few exceptions (Unsupported fields in BP Data Model)

Keeping the data quality and other factors in mind, let’s review the tools/techniques available to us.

Data Import Framework (DIF)

DIF functionality in MDG is intended for mass upload of data in a smaller volume. The transaction code is DTIMPORT. It accepts the data in idoc based .xml file. Though there’s no inbuilt data cleansing future in DIF, it is possible to let the data load go through the data governance process (marked in yellow in the screenshot below), so the records are checked against the configured business rules. Unchecking the Governance option would directly load the data into the active area.



DIF can be used for a large amount of data, but longer execution time should be considered. In general, real-world MDG implementations involve a large volume of master data records (for example, material master).

Simply put, if you want to load a smaller set of clean data, this is an ideal tool. On the other hand, loading a large amount of data using DIF involves performance considerations and increased effort in terms of getting the data cleaned before initiating the load.

File upload:

File upload is another option to load the data into MDG. It takes .csv files and stores the data into the staging area. The major limitation of this functionality is that you can load only one entity type at a time. In other words, you cannot load multiple entity types (multiple views in case of material master) at the same time in a single file. File upload provides the option to select the fields from the entity type for data load.



As file upload stores the data in the staging area, the change request will be created and follow the governance process.

Although File Upload looks a lot like Data Import framework (DIF), with regards to Initial data load, DIF can be advantageous as it accompanies more features, for example, scheduling, ability to load the data directly into Active Area and the capacity to deal with more records with parallel processing.

Like DIF, File upload supports both flex and reuse entities. MDG-Finance data model 0G uses only flexible entity types. In such cases, you might want to consider either DIF or File upload for the initial data load.

SAP Note 2196009 provides a detailed comparison of DIF, file upload and other techniques.

Part 3 provides details about SAP Data Services and S/4HANA Migration cockpit in terms of MDG data loads

Part 4 explores how next-generation HANA powered tools such as Smart Data Integrator (SDI), Smart Data Quality (SDQ) and SAP Agile Data Preparation (ADP) help in MDG on S/4HANA data migration.

Part 5 explains MDG consolidation data import and traditional data loads methods using back-end functions