Tapez LSMW dans un système S/4HANA on-premise en 2026 : l’atelier s’ouvre normalement, les quatorze étapes sont là, vos anciens projets aussi. Pourtant, la Simplification List du même système vous dit de ne plus y toucher.
SAP livre encore l’outil, mais ne veut plus que vous l’utilisiez. Ce paradoxe mérite mieux qu’une réponse de principe : voici ce qui marche encore avec LSMW, ce qui casse structurellement dans S/4HANA, et les cas où l’atelier reste un choix défendable.
- LSMW existe toujours dans S/4HANA on-premise, mais en usage restreint (SAP Note 2287723, Simplification List) : non recommandé, zéro évolution.
- Ce qui casse : le recording sur écrans Fiori et les transactions clients/fournisseurs remplacées par le modèle Business Partner (CVI).
- Ce qui vieillit bien : les méthodes BAPI et IDoc, qui passent par des interfaces et non par des écrans.
- Sur ECC, LSMW reste pleinement légitime pour les reprises et maintenances de masse.
- Le successeur officiel pour S/4HANA est le Migration Cockpit (app Fiori Migrate Your Data), étendu via
LTMOM.
LSMW en deux minutes : lecture, conversion, import
LSMW, pour Legacy System Migration Workbench, est l’atelier de reprise de données historique de SAP. Son principe tient en trois phases : lire les données depuis une source externe (le legacy system, souvent de simples fichiers extraits d’Excel ou d’un ancien ERP), les convertir via des règles de mapping, puis les importer dans la base SAP cible.
L’outil s’adresse aux consultants et aux équipes techniques, pas aux utilisateurs finaux : il écrit directement dans la base de données, et une reprise mal préparée peut endommager des données critiques. C’est précisément sa puissance qui impose la prudence.
Sur les projets ECC, LSMW a été pendant deux décennies le cheval de trait des reprises de masse : création d’articles en série, mise à jour de fiches fournisseurs, injection de gammes. Sa réputation de complexité tombe vite : une fois le processus assimilé, l’atelier est répétitif et prévisible.
Statut officiel 2026 : présente dans S/4HANA, mais en usage restreint
Le point que l’article de 2021 ne pouvait pas encore vous dire : SAP a acté le retrait stratégique de LSMW dans S/4HANA. La transaction existe toujours physiquement dans les systèmes on-premise, mais elle figure sur la Simplification List de S/4HANA, et la Note SAP 2287723 encadre son usage : restreint, non recommandé, sous la responsabilité de l’utilisateur.
Il faut bien comprendre la nuance : LSMW n’est ni supprimée ni bloquée. Elle est livrée, et elle fonctionne encore sur une partie des cas. Mais elle ne reçoit plus aucune évolution fonctionnelle, et SAP ne corrigera pas les incompatibilités qui s’accumulent au fil des releases. Construire un nouveau chargement récurrent sur LSMW dans S/4HANA, c’est construire sur un outil que l’éditeur a cessé d’entretenir.
Le successeur officiel est le Migration Cockpit et son app Fiori Migrate Your Data, dont la filiation et le fonctionnement sont détaillés dans notre guide SAP LTMC et Migrate Your Data.
Les 14 process steps, de Define Object Attributes à Run Batch Input Session
L’écran principal de LSMW liste quatorze étapes séquentielles. Plutôt que de les réciter, lisons-les par blocs logiques, c’est ainsi qu’on les exécute réellement.
Le premier bloc modélise l’objet. Define Object Attributes fixe la méthode de reprise (c’est ici que se joue le choix entre les quatre méthodes, on y revient). Define Source Structures et Define Source Fields décrivent la forme de vos données sources, et Define Structure Relations relie ces structures aux structures cibles SAP.
Le deuxième bloc porte le savoir-faire : Define Field Mapping and Conversion Rules associe chaque champ source à son champ SAP, et Define Fixed Values, Translations, User-Defined Routines héberge les valeurs fixes et les règles de conversion réutilisables.
Le troisième bloc gère les fichiers : Specify Files déclare où vivent les données sources, Assign Files les relie aux structures.
Le dernier bloc exécute : Read Data et Display Read Data chargent et contrôlent les données brutes, Convert Data et Display Converted Data appliquent les règles et montrent le résultat, puis Create Batch Input Session et Run Batch Input Session injectent les données dans le système. Cette mécanique de session batch input s’audite ensuite dans SM35, comme pour tout chargement de ce type.
Les 4 méthodes d’import et leur espérance de vie en S/4HANA
À l’étape Define Object Attributes, LSMW propose quatre méthodes de reprise, et toutes ne vieillissent pas de la même façon.
Le standard batch input ou direct input s’appuie sur des programmes standard livrés par SAP pour les objets classiques. Robuste, mais dépendant du maintien de ces programmes, variable selon l’objet dans S/4HANA.
Le batch input recording rejoue un enregistrement de transaction, exactement la mécanique de l’enregistreur de transactions SHDB. C’est la méthode la plus accessible et la plus fragile : l’enregistrement reproduit des écrans figés, et le moindre changement d’écran le casse. Le résultat alimente une session batch input pilotée dans SM35.
Les méthodes BAPI et IDoc passent par des interfaces standard documentées plutôt que par des écrans. Ce sont celles qui vieillissent le mieux : une BAPI maintenue par SAP continue de fonctionner même quand l’interface utilisateur change radicalement.
La hiérarchie de viabilité dans S/4HANA s’en déduit : BAPI et IDoc d’abord, programmes standard selon l’objet, recording en dernier. Et c’est le recording qui portait la majorité des LSMW de terrain.
Ce qui casse concrètement en S/4HANA
Trois ruptures structurelles, toutes documentées dans la Note 2287723 et le comparatif officiel LSMW contre Migration Cockpit, condamnent une partie du parc existant.
La première : le recording ne fonctionne pas sur les écrans Fiori. Chaque application Fiori qui remplace une transaction GUI retire un terrain de jeu au recording. Un enregistrement construit sur l’ancienne transaction continue parfois de tourner, jusqu’à la release qui la supprime.
S/4HANA impose le modèle Business Partner avec son intégration CVI : les transactions historiques de fiche client et de fiche fournisseur ne sont plus utilisables. Toute LSMW construite sur un enregistrement de ces transactions est morte avec la conversion. Inventoriez ces chargements en priorité : leur reconstruction passe par le Business Partner, côté Migration Cockpit ou par interfaces.
La troisième rupture est plus diffuse : des interfaces standard ont changé de comportement ou de structure entre ECC et S/4HANA. Un chargement LSMW qui tournait depuis des années peut produire des erreurs nouvelles après conversion, sans qu’aucune règle de mapping n’ait bougé.
Quand LSMW reste un choix légitime
Le tableau n’est pas tout noir, et l’honnêteté technique impose le contrepoint.
Sur ECC, LSMW reste pleinement à sa place. Aucune restriction, et un outillage éprouvé que les équipes maîtrisent : tant que votre système de référence est un ECC, il n’y a aucune raison de s’interdire l’atelier pour vos reprises et vos maintenances de masse.
Dans S/4HANA, il subsiste des cas résiduels défendables : une mise à jour ponctuelle de données simples via une méthode BAPI ou IDoc, sur un objet dont l’interface n’a pas changé, par une équipe qui connaît l’outil. Le risque est documenté et assumé : pas de support, pas d’évolution. Ce qui n’est plus défendable, c’est d’industrialiser un nouveau chargement récurrent sur LSMW dans un système S/4HANA, alors que le Migration Cockpit couvre le besoin avec des objets maintenus.
LSMW ou Migration Cockpit : l’arbre de décision
L’arbitrage se résume à quatre questions : quel système cible, quel type d’objet, quelle récurrence, quelles compétences disponibles.
| Situation | Outil recommandé | Pourquoi |
|---|---|---|
| Système cible ECC | LSMW | Pleinement supportée, outillage éprouvé, aucune restriction |
| S/4HANA, objet standard couvert | Migration Cockpit (Migrate Your Data) | Objets de migration maintenus, contrôles intégrés, outil investi par SAP |
| S/4HANA, objet custom ou champ spécifique | Migration Cockpit + LTMOM | Le Migration Object Modeler reprend le rôle des mappings manuels LSMW |
| S/4HANA, besoin ponctuel hors objets de migration | Batch input (SM35) | Chargement ciblé, piloté et auditable |
| S/4HANA, données clients ou fournisseurs | Migration Cockpit (Business Partner) | Modèle BP/CVI obligatoire, transactions historiques inutilisables |
| S/4HANA, maintenance simple via BAPI/IDoc existant | LSMW tolérée | Cas résiduel défendable, risque documenté et assumé |
Système ECC : LSMW sans état d’âme. Système S/4HANA et objet standard couvert par un objet de migration : Migration Cockpit, sans débat, c’est l’outil maintenu et c’est là que SAP investit. Objet custom ou champ spécifique : le cockpit s’étend via le Migration Object Modeler LTMOM, qui reprend précisément le rôle que jouaient vos mappings manuels LSMW. Besoin ponctuel hors périmètre des objets de migration : batch input classique, piloté proprement.
Un mot sur la dette : si votre projet de conversion S/4HANA approche, inventoriez votre parc LSMW dès maintenant. Identifiez les chargements récurrents, qualifiez leur méthode (recording, BAPI, IDoc), et planifiez la reconstruction des plus critiques dans le Migration Cockpit avant la bascule, pas après.
Transporter ses projets LSMW entre systèmes
Tant que LSMW vit dans votre paysage, sa fonction d’export et d’import de projets garde toute son utilité. Elle transporte les structures, les relations, les mappings et les règles de conversion d’un système à l’autre, typiquement du développement vers la qualité puis la production.
La bonne pratique n’a pas changé : construire et tester le projet en développement, le rejouer en qualité sur des volumes représentatifs, et ne l’exécuter en production qu’une fois la conversion validée de bout en bout. L’export et l’import évitent de reconfigurer à chaque environnement, et servent aussi d’archive : un projet exporté documente vos règles de conversion, ce qui vaut de l’or le jour où il faut les reconstruire dans le Migration Cockpit.
LSMW n’est plus l’avenir de la reprise de données SAP, mais elle n’a pas disparu pour autant : elle survit comme outil d’héritage, légitime sur ECC, tolérée à la marge dans S/4HANA, condamnée à terme. La décision qui compte n’est pas de l’aimer ou non, c’est de savoir précisément lesquels de vos chargements doivent déménager, et quand. Pour la suite logique, notre guide SAP LTMC et Migrate Your Data détaille l’outil qui prend le relais.
FAQ : vos questions sur LSMW
LSMW existe-t-il encore dans SAP S/4HANA ?
Oui, la transaction LSMW est toujours livrée dans S/4HANA on-premise et elle s’ouvre normalement. Mais elle figure sur la Simplification List : usage restreint (SAP Note 2287723), non recommandé, sans aucune évolution fonctionnelle. Elle est dépréciée, pas supprimée.
Pourquoi SAP déconseille-t-il LSMW dans S/4HANA ?
Parce que ses mécanismes reposent sur des écrans et des interfaces qui changent dans S/4HANA : le recording ne fonctionne pas sur les écrans Fiori, les transactions clients et fournisseurs sont remplacées par le modèle Business Partner, et des interfaces standard ont changé de structure. SAP concentre ses investissements sur le Migration Cockpit.
Quelle est la différence entre LSMW et le Migration Cockpit (LTMC) ?
LSMW est l’atelier historique d’ECC, basé sur le mapping manuel et quatre méthodes d’import (batch input, recording, BAPI, IDoc). Le Migration Cockpit est son successeur S/4HANA, basé sur des objets de migration pré-modélisés et l’app Fiori Migrate Your Data. La transaction LTMC elle-même est dépréciée depuis S/4HANA 2020 au profit de l’app Fiori.
Pourquoi LSMW ne fonctionne plus pour les clients et fournisseurs dans S/4HANA ?
S/4HANA impose le modèle Business Partner avec l’intégration CVI : les transactions historiques de création et modification de fiches clients et fournisseurs ne sont plus utilisables. Un enregistrement LSMW construit sur ces transactions ne peut donc plus se rejouer. La reprise de ces données passe par le Business Partner, via le Migration Cockpit ou des interfaces.
Quelles sont les 4 méthodes d’import de LSMW ?
Le standard batch ou direct input (programmes standard SAP), le batch input recording (rejeu d’un enregistrement de transaction), la BAPI et l’IDoc. Dans S/4HANA, BAPI et IDoc vieillissent le mieux car ils passent par des interfaces documentées et non par des écrans.
Comment transférer un projet LSMW d’un système SAP à un autre ?
Via la fonction standard d’export et d’import de projets de LSMW. Elle transporte structures, relations, mappings et règles de conversion, typiquement du système de développement vers la qualité puis la production, sans reconfiguration manuelle.
À 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.
Déterminer le prix dans SAP SD : la mécanique de la condition technique
Comment SAP détermine le prix d'une ligne de commande SD : schéma de calcul, types de condition, séquence d'accès et enregistrements de condition, expliqués pas à pas pour un consultant...
Michael A.
S/4HANA vs ECC : les différences clés pour votre carrière SAP
Quelle différence entre SAP ECC et S/4HANA ? Les différences clés expliquées simplement, le jargon décodé, la fin de maintenance d'ECC et ce que cela change pour votre carrière SAP.
Michael A.