Although migrations are not popular with financial professionals, they are often unavoidable. Migrating can have a significant impact on the general ledger, as the load of GL accounts may share a common structure across various entities, but with slight variations, such as the link to alternative accounts. Fortunately, SAP's Migration Cockpit makes your life a lot easier. In this blog, I will explain how to maximise the use of the Migration Object Modeler to ease your migration process.
Migration Cockpit
In the SAP S/4HANA environment, one of the most common solutions for master data migration and load – both for new implementations and conversions – is the SAP HANA Migration Cockpit, also called Landscape Transformation Migration Cockpit or LTMC.
LTMC facilitates the migration of data import through predefined templates in a file-based approach. The cockpit is based on a systematic data control approach that ensures data quality through system-based data duplicates and pre-existence checking.
Are you operating in an international environment? Then the migration process will probably be split into different waves, with phased deployments per country. Let’s assume that all the different entities across your international environment share a common Chart of Account and different country/local charts of account.
Data-update-driven object
The automatic duplicate/pre-existence check performed by the migration cockpit can prevent the load of your master data GL account at company code level if the set of GL accounts is identified as already existing.
To bypass this, the Migration Object Modeler Tool (LTMOM) provided by SAP can be used to transform standard migration objects into data-update driven objects. The tool offers you a wide range of possibilities. For this blog we’ll focus on two main elements:
- copying an existing migration object
- field mapping – action for data record transition from ‘import’ to ‘update’ type
Before you start
Prerequisites for this approach are:
- the migration project has already been created
- standard migration objects have already been defined within this project
Here is how the process goes
1. Create a copy of an existing object
The first step is to create a copy of an existing migration object. The copied version must remain an object specifically dedicated to a file/table-based migration. The newly created object is not subject to a specific naming convention and, in most case scenarios, follows the migration project logic. You can even turn the newly created object into another migration project.
2. Field Mapping: change the object set up from ‘Import’ to ‘Update’ parameter in the following fields
Once you have created the extended version of the standard object, you can access the field mapping of the newly created version and start applying new mapping rules and action records.
In this scenario, we’ll transform our GL_Account (extended) object so that it no longer fulfils a sole importing purpose but also an updating one. As such, we’ll swap the parameter value of the action data record of the four following elements from I-type (import) to U-type (update):
- Chart of Accounts << General Data
- Descriptions << Account Names
- Key Word << Account keywords
- Controlling Area << General data
3. Save and generate the new/extended object
Result
The result is that a new object will be created, oriented on the update of system values, not on the import. This new object will allow you to proceed with your file-based import without further duplicate checks.
Attention points on data over-write priority
With the method, the risk remains that master data will be overwritten, such as GL account master data at the company level for other company codes. This is because the migration template no longer performs a pre-existence check. It may force the new values for all entities at the general data level, such as GL account group. Please be aware of this.
Recommendations
Migration is an important phase in any implementation or conversion project, which often involves specific planning. Will identical objects need to be loaded at different times for different entities? Then consider standard migration objects and systematic checking for duplicates and pre-existence. This will help you avoid problems with future loads.
A good understanding of the LTMOM tool and the possibilities of object extension for update purposes is beneficial. The use of LTMOM is not restricted to the change of action for data record. It also covers various other needs, such as the definition of specific mapping for standard and custom objects.
It’s also important to remember that working with data-update-driven objects may affect the data already stored in the system. If you are planning to use this method to load additional accounts to other foreign entities, then be aware that part of the GL account data set may be modified if your load file is not perfectly aligned with your target system.
More information
I hope you found this blog helpful. For more information, please look into SAP S/4HANA Migration Cockpit SAP S/4HANA 2020 FPS02 or SAP S/4Hana Migration Object Modeler – Files/staging Tables.
Or ask your question via SAP Q&A.