LTMOM reste la transaction de référence pour modeler les migration objects sous S/4HANA on-premise, mais depuis le passage de LTMC à l’app Fiori « Migrate Your Data » à partir de S/4HANA 2020, son périmètre s’est resserré sur des cas précis. Si vous arrivez sur un projet S/4HANA en 2026, la première question n’est plus « comment configurer LTMOM » mais « ai-je vraiment besoin de LTMOM pour ce flux ». Cet article répond à cette question, puis explique la mécanique de l’outil pour les cas où la réponse est oui.
LTMOMsert à modeler les migration objects queLTMCexécute. C’est un outil de design, pas d’exécution.- Sur S/4HANA Cloud Public, LTMOM n’existe plus en tant que transaction. L’équivalent est la tuile Fiori « Model Migration Objects – Migration Object Modeler ».
- Le cas d’usage légitime principal : étendre un migration object standard avec des Z fields (extensions custom) que le template SAP ne couvre pas.
- Workflow en 4 phases : Source Structure, Target Structure, Field Mapping, génération du Runtime Object.
- Quand passer son chemin : si le template standard couvre 100 % des champs, ou si la logique de transformation source-cible dépasse 5 à 6 règles par champ. Dans ce cas, un ETL externe est plus pertinent.
LTMOM vs LTMC vs Migrate Your Data : qui fait quoi en 2026
La confusion entre ces trois outils est constante sur les projets, parce que chacun a remplacé ou complété le précédent à des moments différents. Voici la stack actuelle, sans approximation.
LTMC (Legacy Transfer Migration Cockpit) est l’outil de chargement officiel SAP depuis S/4HANA 1610. Il pilote l’exécution des migrations : upload des fichiers source, contrôle de la qualité des données, lancement des chargements. En 2026, sur S/4HANA on-premise, il est toujours disponible. Sur S/4HANA Cloud, il a été remplacé par « Migrate Your Data » à partir de la version 2008 comme détaillé dans le guide de migration SAP S/4HANA.
LTMOM (Migration Object Modeler) est le complément de design. Quand un projet a besoin d’adapter un migration object standard, par exemple ajouter des Z fields ou modifier le mapping vers un BAPI custom, LTMOM est l’outil. Il ne lance jamais de chargement lui-même, il prépare seulement la structure que LTMC utilisera ensuite.
Migrate Your Data est l’application Fiori unifiée qui, dans les versions récentes, intègre les deux fonctions. Elle expose l’exécution (équivalent LTMC) et le modeling (équivalent LTMOM) dans la même interface. Sur S/4HANA Cloud Public, c’est l’unique point d’entrée.
La conséquence pratique : un consultant qui change de projet doit savoir où il atterrit. Sur un système S/4HANA 1809 ou 1909 encore en production, LTMOM et LTMC en transactions GUI restent la norme. Sur un projet S/4HANA Cloud Public récent, plus aucune trace de transaction LTMC ni LTMOM dans SE93, tout passe par Fiori.
Matrice de décision : LTMOM ou alternative
La vraie valeur d’un consultant senior en 2026 sur le sujet migration n’est pas de connaître les écrans LTMOM par cœur. C’est de savoir quand l’outil est pertinent et quand il ne l’est pas. Voici la grille que j’applique.
| Contexte | Type de données | Outil recommandé | Pourquoi |
|---|---|---|---|
| S/4HANA on-premise + Z fields | Master data avec extensions custom | LTMOM + LTMC | Cas d’usage canonique. LTMOM permet d’étendre le template standard sans perdre la maintenance SAP. |
| S/4HANA Cloud Public | Master data standard | Fiori « Migrate Your Data » | LTMOM n’existe plus en transaction. La Fiori app porte les deux fonctions. |
| Toutes éditions | Master data standard sans extension | LTMC ou Migrate Your Data direct | Pas besoin de LTMOM si le template SAP couvre 100 % du besoin. Économie de complexité. |
| S/4HANA on-premise | Transactionnel gros volume custom | Batch input via SHDB | LTMOM mal taillé pour les flux transactionnels. Batch input + SHDB couvrent ce besoin avec moins de risques. |
| Toutes éditions | Transformation lourde source-cible | ETL externe (SNP, Syniti, Datavard) | Si la logique dépasse 5 à 6 règles de mapping par champ, sortir de LTMOM. Outil prévu pour des transformations légères. |
Le réflexe : commencer par le standard. N’aller dans LTMOM que si le template SAP est insuffisant, et n’aller dans un ETL externe que si LTMOM est insuffisant. Chaque marche ajoute de la complexité opérationnelle, du coût projet, et un point de défaillance supplémentaire au moment du Go-Live.
Workflow LTMOM en 4 phases concrètes
Une fois la décision prise d’utiliser LTMOM, le workflow est toujours le même. Quatre phases, chacune avec ses propres pièges.
- 1Source Structure
C’est la définition du fichier d’entrée (Excel, XML, ou staging table). On part du template standard fourni par SAP pour l’objet ciblé (par exemple Material Master), on copie l’objet pour ne pas casser le standard, et on ajoute les champs Z manquants. Chaque colonne ajoutée dans la source structure devient une colonne dans le template Excel téléchargeable par le métier.
- 2Target Structure
C’est la cible technique côté SAP (BAPI standard, IDoc, ou table métier). En général on garde la cible standard SAP, sauf si le projet nécessite un BAPI custom ou un wrapper RFC dédié. Modifier la target structure casse souvent l’upgrade S/4HANA suivant, à éviter sauf justification métier explicite.
- 3Field Mapping
C’est la phase la plus chronophage. Pour chaque champ source, on définit la règle de transformation vers le champ cible : copie directe, conversion de format, value mapping (par exemple ABC client devient X12 SAP), ou règle ABAP custom. Drag and drop entre la source et la cible dans l’écran central de LTMOM. Garder les règles simples : si une règle nécessite plus de 5 ou 6 conditions, c’est probablement un signal pour sortir vers un ETL externe.
- 4Génération du Runtime Object
Bouton « Generate Runtime Object » en haut à gauche, ou raccourci
ALT+F1. SAP compile la structure modélisée en un objet exécutable que LTMC ou Migrate Your Data peut consommer. Statut passe à Generated. À regénérer après chaque modification, sinon le template Excel téléchargé ne reflète pas les changements de mapping.
Le piège classique sur la phase 4 : modifier la source structure, télécharger un nouveau template Excel, et oublier de regénérer le runtime object. Le métier remplit la nouvelle colonne, lance le chargement via LTMC, et SAP ignore silencieusement le nouveau champ parce que le mapping n’a pas été régénéré. Trois heures de debug pour comprendre.
Cas concret : ajouter un Z field à un migration object standard
Le scénario le plus fréquent que je vois en mission : le template Material Master couvre la majorité des champs, le client a deux ou trois Z fields qu’il a ajoutés dans MM02 pour des besoins spécifiques (numéro de série fournisseur, code logistique interne, indicateur réglementaire), et ces Z fields ne sont pas dans le template standard LTMC. Voici la procédure complète, étape par étape.
- 1Copier le migration object standard
Ouvrir LTMOM, sélectionner le projet de migration. Localiser l’objet standard Material Master, faire un clic droit, copier vers un objet Z (par exemple
Z_MATERIAL_M01). Ne jamais modifier le standard, c’est la garantie de pouvoir absorber les mises à jour SAP sans douleur. - 2Étendre la Source Structure
Sur l’objet copié, activer le mode Change, et ajouter les Z fields dans la Source Structure via le bouton Add Field. Renommer proprement (par exemple
ZZSERIAL_VENDOR) pour rester compatible avec les conventions de nommage du client. - 3Vérifier la Target Structure
Contrôler que la Target Structure (en général un BAPI Material) expose bien les Z fields côté SAP. Si non, prévoir un développement ABAP léger pour étendre le BAPI ou ajouter un user-exit.
- 4Configurer le Field Mapping
Drag and drop entre chaque Z field source et son équivalent target dans l’écran central de Field Mapping. Pour chaque rule, vérifier le type de transformation appliqué (direct copy, value mapping, ou règle custom).
- 5Générer le Runtime Object et tester
Bouton Generate Runtime Object. Statut passe à Generated. Tester sur un sous-ensemble de 5 à 10 matériels via LTMC avant le chargement massif. Documenter dans une requête de transport pour propager DEV vers QAS et PROD.
Ce qui casse si mal fait : staging tables corrompues, perte du mapping après le prochain upgrade S/4HANA, ou pire, chargement silencieux d’une partie seulement des champs sans erreur visible. La règle de base : toujours tester sur un sous-ensemble représentatif et toujours documenter dans une requête de transport pour propager du DEV vers QAS et PROD.
S/4HANA Cloud Public : la rupture Migrate Your Data
Sur S/4HANA Cloud Public Edition, la transaction LTMOM n’existe plus dans SE93. SAP a remplacé l’accès GUI par une tuile Fiori dédiée : « Model Migration Objects – Migration Object Modeler », accessible via le launchpad Fiori d’administration.
La logique métier reste la même : Source Structure, Target Structure, Field Mapping, Runtime Object. Mais la navigation change radicalement. Plus de SAP GUI, plus de raccourcis clavier classiques. Tout passe par l’interface Fiori avec ses propres mécanismes (panneaux, drawers, autorisations Fiori catalog).
Pour un consultant qui passe d’un projet S/4HANA on-premise à un projet S/4HANA Cloud Public, deux points d’attention :
- Courbe d’apprentissage limitée sur la logique. Si vous maîtrisez LTMOM en GUI, vous reconnaîtrez immédiatement les étapes. Seul le wrapper change.
- Extensibilité plus restreinte. Sur Cloud Public, l’extensibilité du modèle de données est encadrée (Key User Extensibility, Custom Fields and Logic). Vous ne pouvez pas ajouter n’importe quel Z field, vous devez passer par les outils Cloud d’extensibilité. Ces limitations propres au Cloud Public sont détaillées chez SAP Press.
Sur S/4HANA Cloud Private Edition, en revanche, vous retrouvez la transaction LTMOM classique, parce que techniquement c’est un système on-premise hébergé chez SAP. La séparation Cloud Public vs Private est ici structurante.
La règle absolue avec LTMOM : on copie le standard vers un objet Z, on modifie la copie. Toucher au standard signifie casser la maintenance SAP sur cet objet, perdre les mises à jour SAP Note et bloquer les upgrades. Cette règle s’applique en on-premise comme en Cloud Private. Sur Cloud Public, l’outil ne permet de toute façon pas la modification du standard.
Pièges récurrents et limites
Quatre pièges sortent du lot dans les retours de mission.
- Performance dégradée après modification du mapping. Si le Runtime Object n’est pas regénéré après modification de la source ou du field mapping, le chargement utilise la version compilée précédente. Symptômes : champs ignorés, erreurs silencieuses, données partiellement chargées. Toujours regénérer.
- Conflits lors d’un upgrade S/4HANA. Si vous avez modifié le migration object standard (au lieu de copier), l’upgrade écrasera vos modifications. Si vous avez copié proprement, les nouveaux champs ajoutés par SAP dans le standard ne sont pas automatiquement propagés dans votre copie. Audit obligatoire après chaque upgrade.
- Limite sur les transformations lourdes. LTMOM gère des règles de mapping simples : copie, conversion de format, lookup dans une table de référence. Pour de la logique métier complexe (calculs multi-champs, agrégations, dédoublonnages avec règles), sortir vers un ETL externe ou un programme ABAP dédié. Forcer LTMOM sur ces cas crée des migration objects illisibles et fragiles.
- Pas de gestion des dépendances inter-objets. LTMOM ne sait pas qu’il faut charger les BOM avant les Production Versions. Le séquencement des migrations doit être géré au niveau du projet (planning, scripts d’orchestration, ou manuel). Sur des migrations complexes type rollout multi-pays, c’est un point de coordination clé. Voir notre guide du rollout SAP pour l’approche globale.
Sur mes projets industriels, LTMOM est rarement le sujet le plus complexe d’une migration S/4HANA. Le vrai sujet, c’est de savoir si on en a besoin, et de bien séquencer les chargements. Le reste suit naturellement.
Pierre Balbinot, consultant SAP PP / EAM
Questions fréquentes sur SAP LTMOM
LTMOM est-il toujours utilisé en S/4HANA 2023 on-premise ?
Oui. Sur S/4HANA on-premise et Cloud Private, LTMOM reste la transaction de référence pour modeler les migration objects. La fonctionnalité a évolué dans le détail entre les releases (par exemple ajout de migration objects standards supplémentaires), mais le principe et l’interface restent inchangés. Sur S/4HANA Cloud Public seulement, l’accès est exclusivement via la tuile Fiori.
Quelle différence entre LTMOM et LSMW ?
LSMW (Legacy System Migration Workbench) est l’outil de l’époque ECC. SAP recommande de ne plus l’utiliser sur S/4HANA. LTMOM est son successeur officiel sur S/4HANA, intégré au Migration Cockpit LTMC. La logique est globalement similaire, mais LTMOM s’appuie sur les BAPI et structures S/4HANA modernes, et bénéficie de l’intégration native avec LTMC et Migrate Your Data.
Peut-on migrer des données transactionnelles via LTMOM ?
Oui mais avec parcimonie. LTMOM gère certains objets transactionnels (open items comptables, stocks d’inventaire), mais sa puissance reste sur le master data. Pour les flux transactionnels de gros volume ou complexes, le batch input via SHDB ou un BAPI dédié sont plus pertinents. Tout dépend du volume et de la complexité du mapping.
Faut-il un développeur ABAP pour utiliser LTMOM ?
Non pour la majorité des flux. La configuration des Source Structures, du Field Mapping standard et de la génération du Runtime Object se fait via l’interface, sans ligne de code. Un développeur ABAP devient utile dans deux cas : extension du BAPI cible (Target Structure custom) ou règles de transformation complexes (function modules custom appelés en field mapping).
LTMOM est-il disponible en S/4HANA Cloud Public ?
Pas en transaction. La transaction LTMOM n’existe pas dans SE93 sur S/4HANA Cloud Public Edition. L’équivalent fonctionnel est la tuile Fiori « Model Migration Objects – Migration Object Modeler », accessible via le launchpad Fiori d’administration. La logique de modeling reste la même, seul l’accès change.
En résumé : LTMOM, outil de design ciblé en 2026
LTMOM n’est plus un outil que l’on active par défaut sur tous les projets migration. Il intervient quand le template standard SAP ne couvre pas les Z fields ou que la cible nécessite un BAPI custom. Sur S/4HANA Cloud Public, la transaction disparaît au profit de la tuile Fiori « Model Migration Objects ». Le réflexe senior en 2026 consiste à valider trois choses avant d’ouvrir LTMOM : le template standard est-il vraiment insuffisant, l’écart justifie-t-il le coût opérationnel d’un objet Z maintenu, et la logique de transformation reste-t-elle dans le périmètre raisonnable de l’outil. Si oui aux trois, LTMOM délivre. Si non, mieux vaut rester sur le standard, ou sortir vers un ETL externe.
À lire ensuite
Spécification fonctionnelle SAP : la trame d’une FS qui tient en projet (WRICEF, validation, pièges)
Guide consultant pour structurer une FS SAP par catégorie WRICEF, valider avec le client et éviter les 7 pièges qui font dériver un développement.
Pierre B.
Rollout SAP : la méthode pratique pour piloter un déploiement multi-sites (SAP Activate, template, cutover)
Comment cadrer un rollout SAP multi-sites : phases SAP Activate, choix big bang vs phased, core template, cutover et hypercare. Pour praticiens chefs de projet.
Pierre B.
Gestion des lots SAP : guide débutant (MM, PP, QM)
Comprenez la gestion des lots dans SAP : à quoi ça sert, comment activer le batch management dans MM, PP, QM, et créer un lot avec MSC1N. Guide pas à...
Pierre B.
SAP Batch Determination : guide configuration et pièges réels
Tu paramètres la batch determination SAP ? Les 6 étapes (COB1, OPL8, condition tables) plus les pièges qu'on rencontre en prod, par un consultant terrain.
Pierre B.