People in the finance industry dislike immigration. But you are unable to stop it. The general ledger is significantly impacted because your GL accounts’ load may have a uniform structure across all of your organisations, but it may also have modest differences due to things like links to alternative accounts. SAP considerably eases your life with the Migration Cockpit. I’ll outline/show examples of how to use the Migration Object Modeler to its fullest potential in this blog post to streamline your migration process.

Migration Cockpit

The SAP HANA Migration Cockpit, also known as the Landscape Transformation Migration Cockpit or LTMC, is one of the most popular solutions for master data migration and load in the SAP S/4HANA environment, both for new instals and conversions.

Through the use of pre-made templates and a file-based methodology, LTMC streamlines the migration of data import. The cockpit is built on a methodical approach to data control that ensures data quality through system-based data duplication checks and preexistence checking.

Are you engaged in foreign business? The migration process will then likely be divided into various waves, with phased deployments for each nation. Assume that the various entities in your global environment all share a single chart of accounts in addition to several national and local charts of accounts.

Data-update-driven object

If the set of GL accounts is found to be duplicates or preexisting, the automatic duplicate/preexistence check run by the migration cockpit can stop the loading of your master data GL account at the business code level.

To get around this, conventional migration objects can be changed into data-update driven objects using the SAP supplied Migration Object Modeler Tool (LTMOM). You have access to a variety of options thanks to the tool. In this article, we’ll concentrate our attention on these two key components:

  • 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 is already created;
  • standard migration objects are already defined within this project.

Here is how the process goes

  1. Create a copy of an existing object

Making a copy of a migration object that already exists is the first step. A copy that is especially intended for a file- or table-based migration must continue to be an object. In most cases, the newly generated object is following the logic of the migration project and is not bound by a particular naming pattern. The newly formed item can even be created in another migration project.

2. Field Mapping – Change the object set up from “Import” to “update” parameter on the following fields

The field mapping of the newly produced version of the standard object can be accessed after you have built the extended version to begin implementing new mapping rules and action records.

In this case, we’ll change our GL Account (extended) object such that it serves both updating and importing purposes in addition to just importing. In order to do this, we’ll switch the parameter value of the action data record of the following four items 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


As a result, a new object will be formed that is focused on updating system variables rather than importing data. You can continue with your file-based import after creating this new object without performing any more duplicate checks.

Attention points on data over-write priority

Also, with this way of working, the risk remains that master data, such as GL account master data at company level for other company codes, will still be overwritten. This is because the migration template no longer performs a preexistence 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.


Any installation or conversion project must include a migration phase, which frequently requires careful planning. Will distinct entities require the same object to be loaded at various times? Consider standard migration objects after that, along with thorough duplication and preexistence checks. By doing so, you steer clear of load issues in the future.

Therefore, it is advantageous to have a thorough understanding of the LTMOM tool and the potential for object extension for update purposes. LTMOM can be used for more than just changing how data is recorded. It also addresses a number of other requirements, such as the definition of particular object mapping for both generic and specific objects.

Remember that dealing with objects that are driven by data updates may have an impact on the data that is already stored in the system. Do you intend to add more accounts to other foreign entities using that method? Then, if your load file is not precisely aligned with your target system, be aware that some of the GL account data set may be updated.