LSMW in SAP and S/4HANA

The Legacy System Migration Workbench, LSMW, is the SAP tool that moved data into R/3 and ECC for two decades. It still opens in S/4HANA on-premise. Whether it still does what you need depends entirely on the object you are loading and the method the object was built on, and that is the question most people arrive here with.

This guide covers what LSMW is, how it is organised, the four import methods, the 14 LSMW steps in SAP in order, what changed in S/4HANA and what specifically breaks, and where it still fits. If you are here because a recording that worked in ECC fails in S/4HANA, the section on what breaks is written for you.

What the Legacy System Migration Workbench is

LSMW is a workbench, not a single program. It packages the work of getting external data into SAP into a fixed sequence of numbered steps, each with its own screen, so that a functional consultant can build a repeatable load without writing a program from scratch.

It arrived with R/3 as a tool for cutover projects, which is where the name comes from: the legacy system was whatever the customer was leaving, and the workbench was the bench you did the migration on. That framing matters, because it explains both its strengths and the way it is treated in S/4HANA. It was designed to be run by a project team, a limited number of times, against a defined set of objects, and to be put away when go-live was done.

The tool's real value was never the loading itself. It was the four steps in the middle, where source fields are mapped to SAP fields, conversion rules are attached, and value translations are held in tables the consultant maintains rather than in code. That mapping layer is what made LSMW usable by people who were not ABAP developers, and it is the part that every migration tool since has copied in one form or another. The SAP Migration Cockpit has the same shape, with a different engine underneath.

People search for it under several names. LSMW, SAP LSMW, the SAP migration workbench, the SAP data migration workbench, and the full Legacy System Migration Workbench all mean the same transaction. The S/4HANA question arrives spelled several ways too: LSMW in S4 HANA, LSMW S4HANA, LSMW in SAP HANA. They all mean the same tool in the same system, and the answer is in the S/4HANA sections below.

How LSMW is organised: project, subproject, object

Everything in LSMW lives in a three level hierarchy, and the first screen asks you to pick or create all three before you see a single step.

Project is the top level, usually one per migration or one per functional area. A project called ECC_TO_S4 or FI_CUTOVER is typical.

Subproject groups objects that belong together. Master data in one subproject, open items in another, or one subproject per SAP module.

Object is the thing you are actually loading. A material master object, a customer master object, a GL open items object. Each object carries its own source structures, its own mapping and its own files. The 14 steps happen at object level.

The practical consequence is that an LSMW object is portable. It can be exported from one system and imported into another as a text file, which is how objects moved between development, quality and production during a cutover, and how consultancies carried their libraries from one client to the next. It is also how a lot of LSMW objects arrived in S/4HANA systems unchanged from ECC, which is where the trouble in the later sections starts.

The four LSMW import methods

Step 1 of any object asks you to choose an import method, and the choice decides what the last few steps look like, which fields you map to, and, in S/4HANA, whether the object works at all.

Methods 3 and 4 share their final steps, since both produce IDocs. Methods 1 and 2 produce a batch input session, which runs in transaction SM35. That distinction is why the 14 step list below is written for the recording method, which is the sequence people mean when they say "the 14 LSMW steps", and why the last two steps are marked as changing by method.

The 14 LSMW steps in SAP, step by step

Every LSMW object walks the same numbered list. The workbench shows the list on one screen, with a radio button beside each step, and you execute them in order. Steps you have completed get a status flag. The list below gives each step, what happens on it, and the decision you are making, so it works as an LSMW step by step manual for the recording method. The walkthrough follows a material master object, since LSMW in SAP MM is the example most people learn on, and describes the S/4HANA on-premise screens as they are today. The LSMW steps in SAP MM, SD, FI or PP are the same 14; only the target object and the mapping change. To create an LSMW in SAP from nothing, start at the project, subproject and object screen described above, then take the steps in this order.

1. 1

   Step 1. Maintain Object Attributes

   Give the object a description and choose the import method: standard batch or direct input, batch input recording, business object, or IDoc. For a recording, this is also where you select which recording to use, or create a new one. The method chosen here is not easily changed later, because it determines the target structure every later step maps to.

2. 2

   Step 2. Maintain Source Structures

   Define the structure of your incoming file. For a flat file, one source structure. For a header and item file, two, with the item structure defined as subordinate to the header. The names you give here are your own; they are how LSMW refers to your data from now on.

3. 3

   Step 3. Maintain Source Fields

   List the fields in each source structure, with a type and length. This is the column list of your spreadsheet, declared to LSMW. There is a table maintenance option that lets you paste the whole list at once rather than adding fields one by one, which is worth knowing about on a 60 column file.

4. 4

   Step 4. Maintain Structure Relations

   Connect each source structure to the target structure it feeds. For a recording, the target is the recording itself. For a BAPI or IDoc, the target is the segment hierarchy of the message. A header source feeds a header segment, an item source feeds an item segment.

5. 5

   Step 5. Maintain Field Mapping and Conversion Rules

   The core of the object. Every target field is listed, and for each one you say where the value comes from: a source field, a constant, a translation table, or a routine. The Auto Field Mapping function proposes matches by name, which handles the obvious ones. Everything with a conversion behind it, a date format, a code mapping, a concatenation, is set here.

6. 6

   Step 6. Maintain Fixed Values, Translations, User-Defined Routines

   Where the reusable conversion assets live. A fixed value is a constant with a name, so it can be changed once. A translation is a value mapping table, legacy code in, SAP code out. A user-defined routine is a small ABAP form for anything beyond what the first two express. Objects in the same project can share these, which is why they sit outside the field mapping.

7. 7

   Step 7. Specify Files

   Tell LSMW where the source file is and how it is laid out: delimiter, whether the first row is a header, code page, and whether the file sits on your PC or on the application server. Files on the application server are the reliable choice for anything large, because a frontend upload of a big file is slow and can time out.

8. 8

   Step 8. Assign Files

   Connect each file from step 7 to a source structure from step 2. With one file and one structure this is a single line. With header and item files it is where you say which is which.

9. 9

   Step 9. Read Data

   LSMW reads the file into its own internal storage. You can restrict the read to a range of records, which is how you test with the first 50 rows before committing to 50,000. The read step does not touch SAP master data or documents; it only stages your file.

10. 10

    Step 10. Display Read Data

    Look at what was read, record by record, in the source structure layout. If a column is shifted, a delimiter is wrong, or the header row was read as data, you see it here, before any conversion has run.

11. 11

    Step 11. Convert Data

    Apply the mapping and conversion rules from steps 5 and 6 to the read data, producing records in the target structure layout. Like step 9, this can be restricted to a range of records, and like step 9 it writes nothing to SAP.

12. 12

    Step 12. Display Converted Data

    The converted records, in the shape the target expects. This is the last look before anything is created. A translation that did not fire, a date that came out in the wrong format, or a constant that was left blank shows up here as an empty or wrong target field.

13. 13

    Step 13. Create Batch Input Session

    For recording and standard batch input objects, LSMW generates a batch input session from the converted data. The session is a queued set of transactions, one per record, that has not yet run. For BAPI and IDoc objects this step is instead Start IDoc Generation, and the following steps become IDoc processing and follow-up rather than a session.

14. 14

    Step 14. Run Batch Input Session

    Execute the session, in the foreground to watch each screen, or in the background for volume. This is transaction SM35, reached from inside LSMW. Errors stop the transaction they occurred in and leave the rest of the session to continue, so the result is a session log with one line per record and a count of what posted. For BAPI and IDoc objects, this is Start IDoc Processing, and the result is read from the IDoc status rather than a session log.

Does LSMW still work in S/4HANA?

Yes, with conditions, and the conditions are what matter.

LSMW in S/4HANA on-premise is present and opens normally, under the same transaction code. SAP's position, stated in SAP Note 2287723, is that the tool is still available but is not recommended, that it receives no functional development, and that it is listed on the S/4HANA simplification list. SAP's recommended tool for data migration into S/4HANA is the Migration Cockpit, which arrived with S/4HANA and is where SAP's migration content and updates now go.

LSMW is not available in SAP S/4HANA Cloud, public edition. The Migration Cockpit is the only migration tool in that environment.

So the honest answer to "does LSMW still work in S/4HANA" is: the transaction works, and an object works if the thing it was built on still exists and still behaves the same way. That is true for a lot of objects and false for a specific set, and the next section is the list.

What breaks when LSMW objects move from ECC to S/4HANA

Most of what breaks traces back to one cause. LSMW objects built on the batch input recording method depend on the exact screen sequence of the transaction they recorded, and S/4HANA changed a number of those screens or replaced the transactions entirely. Objects built on BAPIs are largely unaffected, because a BAPI is a stable published interface and does not have screens.

The practical rule that falls out of this: an LSMW object migrated from ECC is not a working object until it has been run against S/4HANA and its output checked field by field. Recording-based objects need the most scrutiny. BAPI-based objects need the least, and if you are choosing a method for something new in S/4HANA, the business object method is the one that will not surprise you later.

LSMW, the Migration Cockpit, and what comes after go-live

The comparison people usually want is LSMW against the Migration Cockpit, and it is worth being precise about what each was designed to do rather than scoring them against each other.

LSMW was built for R/3 and ECC cutovers. It is flexible, it can be pointed at almost any transaction through a recording, and its mapping layer is genuinely good. It is in maintenance mode in S/4HANA and absent from the public cloud.

The Migration Cockpit was built for S/4HANA cutovers. It ships with predefined migration objects, three transfer options including staging tables and direct transfer from a source system, and it is where SAP's investment now goes. It is the right tool for the initial load into a new S/4HANA system, and SAP designed it for exactly that. The full guide to the Migration Cockpit covers its objects, staging tables and load sequencing.

What neither tool was designed for is the work that continues after go-live. The loads do not stop at cutover. Master data corrections, price updates, cost centre restructures, opening balances for a new company code, documents that failed validation and need reposting, all of it keeps arriving, and it arrives at finance and master data teams rather than at the project. Migration tooling is usually decommissioned or handed back by then, and the people doing the work are not the people who built the LSMW objects.

The guide to the loads that continue after go-live covers delta loads, hypercare corrections and the recurring work that follows.

That recurring, operational load is a different problem from cutover, and it is the one PostNow is built for. It is an Excel add-in and a web portal. A user opens the sheet they already have, PostNow validates every row against the live SAP system, and posts through the same standard BAPIs that LSMW's business object method used, under the user's own SAP login and authorisations. Nothing is recorded, so there are no screens to break. Nothing is transported, so there is no development request. The mapping done once during a migration carries into business as usual, and the person who owns the data can run the load themselves.

Where LSMW still fits

None of the above means LSMW should be deleted from your list.

It still fits when you are on ECC, where it remains the standard tool. It fits for an S/4HANA on-premise object built on the BAPI method, which will keep working. It fits for a one-time load of an object the Migration Cockpit does not cover, provided the recording is made fresh in S/4HANA rather than imported from ECC. And it fits when the team already knows it, the object is small, and the alternative is a development request.

Where it no longer fits is the recurring case, the Fiori case, the Business Partner case, and anything in the public cloud. For the ECC to S/4HANA migration itself, the Migration Cockpit is the tool SAP built for the job. For the master data loads that follow, and for the mass changes that never stop, the question is who has to run the load and how often, and that usually points somewhere else.

If you are working from Excel, the free SAP upload templates cover the same objects LSMW was most often used for, with the BAPI structure and field named for every column. The master data set is the natural place to start, since that is where most LSMW objects lived.

Frequently asked questions