LTMOM is still the reference transaction for modeling migration objects on S/4HANA on-premise, but ever since the shift from LTMC to the Fiori app “Migrate Your Data” starting with S/4HANA 2020, its scope has narrowed to specific cases. If you join an S/4HANA project in 2026, the first question is no longer “how do I configure LTMOM” but “do I really need LTMOM for this flow”. This article answers that question, then explains how the tool works for the cases where the answer is yes.
LTMOMis used to model the migration objects thatLTMCexecutes. It is a design tool, not an execution tool.- On S/4HANA Cloud Public, LTMOM no longer exists as a transaction. The equivalent is the Fiori tile “Model Migration Objects – Migration Object Modeler”.
- The main legitimate use case: extending a standard migration object with Z fields (custom extensions) that the SAP template does not cover.
- Workflow in 4 phases: Source Structure, Target Structure, Field Mapping, Runtime Object generation.
- When to skip it: if the standard template covers 100% of the fields, or if the source-to-target transformation logic exceeds 5 to 6 rules per field. In that case, an external ETL is more relevant.
LTMOM vs LTMC vs Migrate Your Data: who does what in 2026
Confusion between these three tools is constant on projects, because each one replaced or complemented the previous one at different points in time. Here is the current stack, with no approximation.
LTMC (Legacy Transfer Migration Cockpit) has been SAP’s official loading tool since S/4HANA 1610. It drives migration execution: uploading source files, checking data quality, launching loads. In 2026, on S/4HANA on-premise, it is still available. On S/4HANA Cloud, it was replaced by “Migrate Your Data” starting with version 2008 as detailed in the SAP S/4HANA migration guide.
LTMOM (Migration Object Modeler) is the design counterpart. When a project needs to adapt a standard migration object, for example adding Z fields or changing the mapping to a custom BAPI, LTMOM is the tool. It never launches a load itself, it only prepares the structure that LTMC will use afterwards.
Migrate Your Data is the unified Fiori application that, in recent versions, integrates both functions. It exposes execution (LTMC equivalent) and modeling (LTMOM equivalent) in the same interface. On S/4HANA Cloud Public, it is the single entry point.
The practical consequence: a consultant who moves to a new project needs to know where they land. On an S/4HANA 1809 or 1909 system still in production, LTMOM and LTMC as GUI transactions remain the norm. On a recent S/4HANA Cloud Public project, there is no longer any trace of the LTMC or LTMOM transaction in SE93, everything goes through Fiori.
Decision matrix: LTMOM or an alternative
The real value of a senior consultant in 2026 on the migration topic is not knowing the LTMOM screens by heart. It is knowing when the tool is relevant and when it is not. Here is the grid I apply.
| Context | Data type | Recommended tool | Why |
|---|---|---|---|
| S/4HANA on-premise + Z fields | Master data with custom extensions | LTMOM + LTMC | Canonical use case. LTMOM lets you extend the standard template without losing SAP maintenance. |
| S/4HANA Cloud Public | Standard master data | Fiori “Migrate Your Data” | LTMOM no longer exists as a transaction. The Fiori app carries both functions. |
| All editions | Standard master data without extension | LTMC or Migrate Your Data directly | No need for LTMOM if the SAP template covers 100% of the need. Less complexity. |
| S/4HANA on-premise | High-volume custom transactional data | Batch input via SHDB | LTMOM is poorly suited to transactional flows. Batch input + SHDB cover this need with fewer risks. |
| All editions | Heavy source-to-target transformation | External ETL (SNP, Syniti, Datavard) | If the logic exceeds 5 to 6 mapping rules per field, move out of LTMOM. The tool is designed for light transformations. |
The reflex: start with the standard. Only go into LTMOM if the SAP template is insufficient, and only go into an external ETL if LTMOM is insufficient. Each step adds operational complexity, project cost, and one more point of failure at Go-Live time.
LTMOM workflow in 4 concrete phases
Once the decision to use LTMOM has been made, the workflow is always the same. Four phases, each with its own pitfalls.
- 1Source Structure
This is the definition of the input file (Excel, XML, or staging table). You start from the standard template provided by SAP for the targeted object (for example Material Master), you copy the object so as not to break the standard, and you add the missing Z fields. Each column added in the source structure becomes a column in the Excel template that the business can download.
- 2Target Structure
This is the technical target on the SAP side (standard BAPI, IDoc, or business table). In general you keep the standard SAP target, unless the project requires a custom BAPI or a dedicated RFC wrapper. Changing the target structure often breaks the next S/4HANA upgrade, so avoid it unless there is an explicit business justification.
- 3Field Mapping
This is the most time-consuming phase. For each source field, you define the transformation rule to the target field: direct copy, format conversion, value mapping (for example a customer’s ABC becomes SAP’s X12), or a custom ABAP rule. Drag and drop between the source and the target in the central LTMOM screen. Keep the rules simple: if a rule requires more than 5 or 6 conditions, that is probably a signal to move out to an external ETL.
- 4Runtime Object generation
The “Generate Runtime Object” button at the top left, or the shortcut
ALT+F1. SAP compiles the modeled structure into an executable object that LTMC or Migrate Your Data can consume. The status changes to Generated. Regenerate after every change, otherwise the downloaded Excel template does not reflect the mapping changes.
The classic pitfall in phase 4: changing the source structure, downloading a new Excel template, and forgetting to regenerate the runtime object. The business fills in the new column, launches the load via LTMC, and SAP silently ignores the new field because the mapping was not regenerated. Three hours of debugging to figure it out.
Concrete case: adding a Z field to a standard migration object
The most frequent scenario I see on assignments: the Material Master template covers most of the fields, the customer has two or three Z fields they added in MM02 for specific needs (vendor serial number, internal logistics code, regulatory indicator), and these Z fields are not in the standard LTMC template. Here is the complete procedure, step by step.
- 1Copy the standard migration object
Open LTMOM, select the migration project. Locate the standard Material Master object, right-click, copy it to a Z object (for example
Z_MATERIAL_M01). Never change the standard, this is your guarantee of being able to absorb SAP updates painlessly. - 2Extend the Source Structure
On the copied object, switch to Change mode, and add the Z fields in the Source Structure via the Add Field button. Name them cleanly (for example
ZZSERIAL_VENDOR) to stay compatible with the customer’s naming conventions. - 3Check the Target Structure
Verify that the Target Structure (usually a Material BAPI) does expose the Z fields on the SAP side. If not, plan for a light ABAP development to extend the BAPI or add a user-exit.
- 4Configure the Field Mapping
Drag and drop between each source Z field and its target equivalent in the central Field Mapping screen. For each rule, check the type of transformation applied (direct copy, value mapping, or custom rule).
- 5Generate the Runtime Object and test
The Generate Runtime Object button. The status changes to Generated. Test on a subset of 5 to 10 materials via LTMC before the mass load. Document in a transport request to propagate DEV to QAS and PROD.
What breaks when done badly: corrupted staging tables, loss of the mapping after the next S/4HANA upgrade, or worse, a silent load of only some of the fields with no visible error. The basic rule: always test on a representative subset and always document in a transport request to propagate from DEV to QAS and PROD.
S/4HANA Cloud Public: the Migrate Your Data break
On S/4HANA Cloud Public Edition, the transaction LTMOM no longer exists in SE93. SAP replaced GUI access with a dedicated Fiori tile: “Model Migration Objects – Migration Object Modeler”, accessible via the administration Fiori launchpad.
The business logic stays the same: Source Structure, Target Structure, Field Mapping, Runtime Object. But navigation changes radically. No more SAP GUI, no more classic keyboard shortcuts. Everything goes through the Fiori interface with its own mechanisms (panels, drawers, Fiori catalog authorizations).
For a consultant moving from an S/4HANA on-premise project to an S/4HANA Cloud Public project, two points of attention:
- Limited learning curve on the logic. If you have mastered LTMOM in the GUI, you will immediately recognize the steps. Only the wrapper changes.
- More restricted extensibility. On Cloud Public, data model extensibility is governed (Key User Extensibility, Custom Fields and Logic). You cannot add just any Z field, you have to go through the Cloud extensibility tools. The SAP Press documentation details the limitations specific to Cloud Public.
On S/4HANA Cloud Private Edition, on the other hand, you find the classic LTMOM transaction again, because technically it is an on-premise system hosted by SAP. The Cloud Public vs Private split is a defining factor here.
The absolute rule with LTMOM: you copy the standard to a Z object, you modify the copy. Touching the standard means breaking SAP maintenance on that object, losing SAP Note updates, and blocking upgrades. This rule applies on-premise as well as on Cloud Private. On Cloud Public, the tool does not allow modifying the standard anyway.
Recurring pitfalls and limits
Four pitfalls stand out in feedback from assignments.
- Degraded performance after a mapping change. If the Runtime Object is not regenerated after changing the source or the field mapping, the load uses the previously compiled version. Symptoms: ignored fields, silent errors, partially loaded data. Always regenerate.
- Conflicts during an S/4HANA upgrade. If you changed the standard migration object (instead of copying it), the upgrade will overwrite your changes. If you copied cleanly, the new fields added by SAP in the standard are not automatically propagated into your copy. A mandatory audit after every upgrade.
- Limit on heavy transformations. LTMOM handles simple mapping rules: copy, format conversion, lookup in a reference table. For complex business logic (multi-field calculations, aggregations, deduplication with rules), move out to an external ETL or a dedicated ABAP program. Forcing LTMOM into these cases creates unreadable and fragile migration objects.
- No management of inter-object dependencies. LTMOM does not know that you have to load BOMs before Production Versions. Migration sequencing must be handled at project level (planning, orchestration scripts, or manual). On complex migrations such as a multi-country rollout, this is a key coordination point. See our SAP rollout guide for the overall approach.
On my industrial projects, LTMOM is rarely the most complex topic of an S/4HANA migration. The real topic is knowing whether you need it, and sequencing the loads properly. The rest follows naturally.
Pierre Balbinot, SAP PP / EAM consultant
Frequently asked questions about SAP LTMOM
Is LTMOM still used on S/4HANA 2023 on-premise?
Yes. On S/4HANA on-premise and Cloud Private, LTMOM remains the reference transaction for modeling migration objects. The functionality has evolved in detail between releases (for example the addition of further standard migration objects), but the principle and the interface stay unchanged. On S/4HANA Cloud Public only, access is exclusively via the Fiori tile.
What is the difference between LTMOM and LSMW?
LSMW (Legacy System Migration Workbench) is the tool from the ECC era. SAP recommends no longer using it on S/4HANA. LTMOM is its official successor on S/4HANA, integrated into the LTMC Migration Cockpit. The logic is broadly similar, but LTMOM relies on modern S/4HANA BAPIs and structures, and benefits from native integration with LTMC and Migrate Your Data.
Can transactional data be migrated via LTMOM?
Yes but sparingly. LTMOM handles certain transactional objects (accounting open items, inventory stocks), but its strength remains master data. For high-volume or complex transactional flows, batch input via SHDB or a dedicated BAPI are more relevant. It all depends on the volume and the complexity of the mapping.
Do you need an ABAP developer to use LTMOM?
No for the majority of flows. Configuring the Source Structures, the standard Field Mapping, and Runtime Object generation is done through the interface, with no line of code. An ABAP developer becomes useful in two cases: extending the target BAPI (custom Target Structure) or complex transformation rules (custom function modules called in field mapping).
Is LTMOM available on S/4HANA Cloud Public?
Not as a transaction. The transaction LTMOM does not exist in SE93 on S/4HANA Cloud Public Edition. The functional equivalent is the Fiori tile “Model Migration Objects – Migration Object Modeler”, accessible via the administration Fiori launchpad. The modeling logic stays the same, only the access changes.
In summary: LTMOM, a targeted design tool in 2026
LTMOM is no longer a tool you turn on by default on every migration project. It comes into play when the standard SAP template does not cover the Z fields or when the target requires a custom BAPI. On S/4HANA Cloud Public, the transaction disappears in favor of the Fiori tile “Model Migration Objects”. The senior reflex in 2026 is to validate three things before opening LTMOM: is the standard template really insufficient, does the gap justify the operational cost of a maintained Z object, and does the transformation logic stay within the tool’s reasonable scope. If yes to all three, LTMOM delivers. If not, it is better to stay on the standard, or move out to an external ETL.
Keep reading
SAP Functional Specification: WRICEF template and pitfalls
Most SAP consultants treat the functional specification as administrative drudgery to dispatch before getting to the real work. Rookie mistake. A well-written FS decides on its own whether the development...
Pierre B.
SAP Rollout guide: multi-site method with SAP Activate
Most project managers running their first SAP rollout discover after a few weeks that they are managing not an IT project but a transformation of the business operations. The technical...
Pierre B.
Beginner's guide to batch management in SAP MM
I have seen consultants tick the "Batch management" box on thousands of materials in a MASS run, without realizing the batch level was still set at client level. A few...
Pierre B.
SAP batch determination and management
You are configuring SAP batch determination and the engine does not kick in. You are picking batches in the wrong order even though the sort rule is correctly set up....
Pierre B.