Type LSMW into an SAP S/4HANA on-premise system in 2026 and the workbench opens normally: all fourteen steps are there, and so are your old projects. Yet the Simplification List of that very system tells you to stop using it.
SAP still ships the tool but no longer wants you to use it. That paradox deserves more than a one-line answer: here is what still works with LSMW, what structurally breaks in S/4HANA, and the cases where the workbench remains a defensible choice.
- LSMW still exists in S/4HANA on-premise, but with restricted use (SAP Note 2287723, Simplification List): not recommended, zero further development.
- What breaks: batch input recording on Fiori screens and the customer and vendor transactions replaced by the Business Partner model (CVI).
- What ages well: the BAPI and IDoc methods, which go through interfaces rather than screens.
- On ECC, LSMW remains fully legitimate for data loads and mass maintenance.
- The official successor for S/4HANA is the Migration Cockpit (Migrate Your Data Fiori app), extended through
LTMOM.
LSMW in two minutes: read, convert, import
LSMW, short for Legacy System Migration Workbench, is SAP’s historical data migration workbench. The principle fits in three phases: read the data from an external source (the legacy system, often plain files extracted from Excel or an old ERP), convert it through mapping rules, then import it into the target SAP database.
The tool is meant for consultants and technical teams, not end users: it writes directly into the database, and a poorly prepared load can damage critical data. Its very power is what demands caution.
On ECC projects, LSMW was the workhorse of mass data loads for two decades: creating materials in bulk, updating vendor master records, injecting routings. Its reputation for complexity fades fast: once you have absorbed the process, the workbench is repetitive and predictable.
Is LSMW still supported? The official 2026 status in S/4HANA
Here is what the 2021 version of this article could not tell you yet: SAP has formalized the strategic retirement of LSMW in S/4HANA. The transaction still physically exists in on-premise systems, but it sits on the S/4HANA Simplification List, and SAP Note 2287723 frames its use: restricted, not recommended, at the user’s own responsibility.
The nuance matters: LSMW is deprecated, not deleted or blocked. It still ships, and it still works for part of the cases. But it receives no functional development whatsoever, and SAP will not fix the incompatibilities that pile up release after release. Building a new recurring load on LSMW in S/4HANA means building on a tool SAP has stopped maintaining.
The official successor is the SAP Migration Cockpit and its Migrate Your Data Fiori app, whose lineage and inner workings are covered in our guide to SAP LTMC and Migrate Your Data.
The 14 process steps, from Define Object Attributes to Run Batch Input Session
The main LSMW screen lists fourteen sequential steps. Rather than reciting them, let’s read them in logical blocks, because that is how you actually run them.
The first block models the object. Define Object Attributes sets the import method (this is where the choice between the four methods happens, more on that below). Define Source Structures and Define Source Fields describe the shape of your source data, and Define Structure Relations links those structures to the target SAP structures.
The second block carries the craft: Define Field Mapping and Conversion Rules pairs each source field with its SAP field, and Define Fixed Values, Translations, User-Defined Routines hosts the fixed values and the reusable conversion rules.
The third block handles files: Specify Files declares where the source data lives, Assign Files links the files to the structures.
The last block executes: Read Data and Display Read Data load and check the raw data, Convert Data and Display Converted Data apply the rules and show the result, then Create Batch Input Session and Run Batch Input Session push the data into the system. That batch input session mechanism is then audited in SM35, like any load of this type.
The 4 import methods and their life expectancy in S/4HANA
At the Define Object Attributes step, LSMW offers four import methods, and they do not all age the same way.
Standard batch input or direct input relies on standard programs delivered by SAP for classic objects. Robust, but dependent on those programs being maintained, which varies by object in S/4HANA.
Batch input recording replays a recorded transaction, exactly the mechanics of the SHDB transaction recorder. It is the most accessible method and the most fragile: the recording reproduces frozen screens, and the slightest screen change breaks it. The output feeds a batch input session managed in SM35.
The BAPI and IDoc methods go through documented standard interfaces rather than screens. They are the ones that age best: a BAPI maintained by SAP keeps working even when the user interface changes radically.
The viability ranking in S/4HANA follows: BAPI and IDoc first, standard programs depending on the object, recording last. And recording is what carried the majority of real-world LSMW objects.
What actually breaks in S/4HANA
Three structural breaks, all documented in Note 2287723 and in the official LSMW vs Migration Cockpit comparison, condemn part of the existing estate.
The first: recording does not work on Fiori screens. Every Fiori app that replaces a GUI transaction takes territory away from recording. A recording built on the old transaction sometimes keeps running, until the release that removes it.
S/4HANA enforces the Business Partner model with its CVI integration: the historical customer master and vendor master transactions are no longer usable. Any LSMW object built on a recording of those transactions died with the conversion. Inventory those loads first: rebuilding them goes through the Business Partner, either in the Migration Cockpit or through interfaces.
The third break is more diffuse: some standard interfaces changed behavior or structure between ECC and S/4HANA. An LSMW load that ran for years can throw brand new errors after the conversion, without a single mapping rule having moved.
When LSMW is still a legitimate choice
The picture is not all dark, and technical honesty demands the counterpoint.
On ECC, LSMW is fully at home. No restriction, and proven tooling that teams know inside out: as long as your system of record is an ECC, there is no reason to deny yourself the workbench for your data loads and mass maintenance.
In S/4HANA, defensible residual cases remain: a one-off update of simple data through a BAPI or IDoc method, on an object whose interface has not changed, run by a team that knows the tool. The risk is documented and accepted: no support, no further development. What is no longer defensible is industrializing a new recurring load on LSMW in an S/4HANA system when the Migration Cockpit covers the need with maintained objects.
LSMW vs Migration Cockpit: the decision tree
The decision boils down to four questions: which target system, which object type, how recurring the load is, and which skills are available.
| Situation | Recommended tool | Why |
|---|---|---|
| Target system is ECC | LSMW | Fully supported, proven tooling, no restriction |
| S/4HANA, standard object covered | Migration Cockpit (Migrate Your Data) | Maintained migration objects, built-in checks, the tool SAP invests in |
| S/4HANA, custom object or specific field | Migration Cockpit + LTMOM | The Migration Object Modeler takes over the role of manual LSMW mappings |
| S/4HANA, one-off need outside migration objects | Batch input (SM35) | Targeted, controlled and auditable load |
| S/4HANA, customer or vendor data | Migration Cockpit (Business Partner) | BP/CVI model mandatory, historical transactions unusable |
| S/4HANA, simple maintenance via existing BAPI/IDoc | LSMW tolerated | Defensible residual case, risk documented and accepted |
ECC system: LSMW without a second thought. S/4HANA system with a standard object covered by a migration object: Migration Cockpit, no debate, it is the maintained tool and it is where SAP puts its money. Custom object or specific field: the cockpit extends through the LTMOM Migration Object Modeler, which takes over precisely the role your manual LSMW mappings used to play. One-off need outside the scope of migration objects: classic batch input, properly controlled.
A word on debt: if your S/4HANA conversion project is approaching, inventory your LSMW estate now. Identify the recurring loads, qualify their method (recording, BAPI, IDoc), and plan the rebuild of the most critical ones in the Migration Cockpit before the cutover, not after.
Transferring LSMW projects between systems
As long as LSMW lives in your environment, its project export and import function keeps all its value. It carries the structures, relations, mappings and conversion rules from one system to another, typically from development to quality and then to production.
The good practice has not changed: build and test the project in development, replay it in quality on representative volumes, and only run it in production once the conversion has been validated end to end. Export and import spare you from reconfiguring in every environment, and they double as an archive: an exported project documents your conversion rules, which is worth gold the day you have to rebuild them in the Migration Cockpit.
LSMW is no longer the future of SAP data migration, but it has not vanished either: it survives as a legacy tool, legitimate on ECC, tolerated at the margins in S/4HANA, doomed in the long run. The decision that matters is not whether you like it, it is knowing precisely which of your loads need to move, and when. For the logical next step, our guide to SAP LTMC and Migrate Your Data covers the tool that takes over.
FAQ: your questions about LSMW
Does LSMW still exist in SAP S/4HANA?
Yes, the LSMW transaction still ships with S/4HANA on-premise and it opens normally. But it sits on the Simplification List: restricted use (SAP Note 2287723), not recommended, with zero functional development. It is deprecated, not removed.
Why is LSMW not recommended in S/4HANA?
Because its mechanics rely on screens and interfaces that change in S/4HANA: recording does not work on Fiori screens, customer and vendor transactions are replaced by the Business Partner model, and some standard interfaces changed structure. SAP concentrates its investment on the Migration Cockpit.
What is the difference between LSMW and the Migration Cockpit (LTMC)?
LSMW is the historical ECC workbench, based on manual mapping and four import methods (batch input, recording, BAPI, IDoc). The Migration Cockpit is its S/4HANA successor, based on pre-modeled migration objects and the Migrate Your Data Fiori app. The LTMC transaction itself has been deprecated since S/4HANA 2020 in favor of the Fiori app.
Why does LSMW no longer work for customers and vendors in S/4HANA?
S/4HANA enforces the Business Partner model with CVI integration: the historical transactions for creating and changing customer and vendor master records are no longer usable. An LSMW recording built on those transactions can no longer be replayed. Migrating that data goes through the Business Partner, via the Migration Cockpit or interfaces.
What are the 4 import methods in LSMW?
Standard batch or direct input (standard SAP programs), batch input recording (replaying a recorded transaction), BAPI and IDoc. In S/4HANA, BAPI and IDoc age best because they go through documented interfaces rather than screens.
How do you transfer an LSMW project from one SAP system to another?
Through LSMW’s standard project export and import function. It carries structures, relations, mappings and conversion rules, typically from the development system to quality and then production, with no manual reconfiguration.
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.
SAP SD Pricing Determination: The Condition Technique
Sooner or later, on a project, a user shows you a sales order and asks why the displayed price is not the one they expected. You open the line, you...
Michael A.
SAP ECC vs S/4HANA: the key differences for your SAP career
If you look into SAP for your career, two acronyms keep coming up: ECC and S/4HANA. One is the older generation of SAP's ERP, the other is the current version....
Michael A.