Skip to Content

LSMW.  I wonder where that 4 letter acronym ranks in terms of frequency of use here on SCN.  I’m sure it’s in the top 10 even with stiff competition from SAP, ERP, BAPI, ABAP, and some others.

Why is that?  Well, it’s a very useful tool and comes up frequently in the functional forums.  I remember when I got an email from a fellow SAP colleague introducing me to it.  That was back sometime in the fall of 1999 but I know version 1.0 came out a year earlier and was supported as far back as R/3 3.0F.  I dove into it and the guide that SAP had published and it was really great.  I could see immediately that for basic data conversions, I could handle the entire conversion process without the help of a developer.  Back in 1998, that was a fairly big deal and one that I’m sure the ABAPers had no problem ceding territory in.

Just a year earlier I was using CATT to do legacy conversion.  It had a similar transaction code based recording mechanism, a way to define import parameters, and a loading mechanism to map a .txt file to those parameters.  But CATT was not designed specifically for data conversion so it could be a pain to deal with.  In particular, tracking load errors was very tedious which required you to do a large number of mock loads on your data to ensure that it was perfect.

My History with LSMW

Back in 1999, it was obvious to me that LSMW was a big improvement over CATT for a few reasons:

  • I could incorporate standard load programs and BAPIs. Using screen recordings was no longer the only way to load data.  I hate screen recordings.  They eventually break and you have to handle them with kid gloves at times… you have to trick them into handling certain OK codes or work around validations/substitutions.
  • LSMW allowed you to use screen recordings as a way to define your target structures.  I love screen recordings!  Why?  Because, as a last resort, they let me change any record in the system using an SAP supported dialog process.  If you can get to it manually at a transaction code for a single record, than you can create/change/delete that same data in batch using a custom screen recording.
  • I could do the transformation within SAP rather in Excel.  That saved a lot of time especially if I had certain transformations (i.e., a cost center lookup) that were used in different loads.  Define once, use multiple times.
  • I could load multiple structures of data.  Again, this saved time because I didn’t have to rearrange the data in Excel to force it into a particular structure format which might contain numerous fields that I had no interest in populating.  That left my source Excel file relatively clean which was far easier to manage.
  • Organization.  LSMW had a way to categorize each load by Project, Sub-Project, and Object.
  • No more developers!  While the tool allows you to insert custom logic, it’s not required to do so.  If you know your data well enough and you have a typical legacy source file, there’s no reason why a functional person such as myself can’t load everything on his own.

Once word spread about LSMW inside SAP, it seemed that every functional consultant I worked with was using it.  Eventually we started using it for purposes other than legacy data conversion.  Mass changes, mass creation of new data that wasn’t legacy related, etc.  Other non-functional areas used it too; I’ve seen security teams upload mass changes to userID records.

This is how I Really Feel

But… I didn’t write this to praise LSMW.  Now, in the year 2014, I can’t stand working with it.  It’s limitations have been bugging me for years and SAP hasn’t done anything to improve it.  My gripes:

  1. Poor organization.  The simple Project / Sub-Project / Object classification is too limiting.  It seems to be a quasi hierarchy of the individual LSMW objects… but why not release a fully functional hierarchy?  If we had a real hierarchy we could use multiple levels, parent-child relationships, drag-n-drop, etc.  There are some customers that don’t use it that much and may only need a single level deep hierarchy.  Others might need 5 or more.  Either party is currently forced into using the existing 2 deep classification of Project / Sub-Project.  What I most often see is a horrible organization of the underlying LSMW objects.  That fault lies with the customers for not enforcing and administering this hierarchy.  But if the tool made it easier to classify and organize the various scripts, maybe it wouldn’t be as messy as I’ve come to expect.
  2. The prompts are inconsistent. This is a minor gripe but the function keys are different per screen.  To read/convert your data file you navigate to a selection screen (a very limited one) and press F8 to execute.  To read the contents of those data files within SAP, you get a pop-up window and have to hit Enter to execute it.  No one limits the reading to a selection of records (or, very rarely do they) so I could do away with that prompt entirely.
  3. Another personal gripe but I’m so tired of the constant Read Data, Convert Data, Load Data…  Whoops!  Error!  Change in Excel, save to .txt, Read Data, Convert Data, etc.  The process has too many steps and I have to flip between SAP, Excel, my text editor, and my file manager (Directory Opus).  Or, why can’t I link directly to my Excel file and view it within SAP?
  4. There isn’t a good way to quickly test or validate some basics of the data.  I get that each area and load mechanism is different (i.e., BAPI versus screen recording) but there should be a quick way within the tool to better validate the data in a test format so that we know right away if the first 10 records are OK.
  5. Speed.  I had some tweets with Tammy Powlas this past weekend.  She used RDS for an upload (Initial Data Migration Over, The Fun Has Just Begun).  The upload of 600k records took an hour but I highly doubt that LSMW could beat that.
  6. The solution was great back in 1998 for the reasons I noted above.  Back then I would happily double click between my source and target fields, assign rules, create lookup tables, etc.  But it’s 2014.  I’d rather use a Visio type of tool to maintain my data relationships.
  7. Lack of Development.  Here’s the version we are running at my customer.  2004…  seriously?  No changes in 10 years?  I recall the early versions of LSMW… v1, v1.6, v1.7… but I don’t remember there being a v2 or v3.  So how did we jump from v1.7 to v4 and what are the delta changes?  Seems like some upper management mandated creative version management to me.  My guess is that LSMW has been upgraded based on changes to WAS and to keep it along with ERP 5.0 to 6.0…but the product itself hasn’t changed in terms of functionality.  LSMW still feels like a v2 product to me.

screenshot - 2014.11.12 - 08.31.12.png

My Biggest Gripe

But my biggest gripe isn’t with the tool.  It’s how it’s used by the SAP community.

It seems that every consultant I know uses LSMW as their go-to source for all data changes.  I’ve walked into customers that have been using an LSMW to maintain some object for 10+ years!!!!  How the heck can something like that happen?  This is an area where LSMW’s flexibility works against it… or rather, works against the customer’s long term success with SAP.  The problem here is that it allows us functional folks to quickly develop a ‘tool’ to maintain data.  It’s the quickest way to develop a solution on the Excel-to-SAP highway that accountants et al. need throughout the year.  For a truly ad-hoc requirement to do just about any process in SAP based on data in Excel, it works fine.  I don’t have an issue with that and would recommend LSMW in those appropriate cases.  But it’s not a long term solution.  Period, end of story.

Other Solutions

Mass Maintenance Tool

If you have a recurring need to mass change master data, you should be using the mass maintenance tool.  Just about every module has developed a solution using this tool to change the most important master data records in the system.

screenshot - 2014.11.12 - 08.56.29.png

Be Friendly to your ABAPer

Anyone heard of a BAPI?  If you have a recurring need to upload transaction data or make changes to certain POs, sales orders, etc, or have a master record not in the list above, there is a BAPI that will do that for you.  Get with your ABAPer, develop a suitable selection screen, get a test-run parameter on there, get a nice ALV based output report, and then get the tcode created.  Done…  that’s a good solution using an SAP supported protocol that is far better, safer, consistent, and easier to work with than a screen based recording that dumps your data into BDC.  In my opinion, if part of your solution has the letters ‘SM35’ in it, you’ve done something wrong.

Why would anyone recommend to a customer that they should use this crummy process (read data, convert data, display converted data…) as the long term solution for making changes like this?  That’s not a solution, it’s a lame recommendation.



Final Word

LSMW and other similar screen based recording tools (Winrunner et al.) are flexible and it’s tempting for people… and I’m talking primarily to the consultants out there that over-use and over-recommend LSMW… to keep going back to it.  It’s a useful tool but there are problems when you don’t have enough tools in your toolbox to use… you’re limited in options and you keep going back to what you know.

Have you heard of the phrase “When you have a hammer, everything looks like a nail”.  It came from noted psychologist Abraham H. Maslow in his 1966 book The Psychology of Science.

Maslow quote.png

His quote is also part of something called the Law of the Instrument.  A related concept of this is the notion of the Golden Hammer which was written about in AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis: William J. Brown, Raphael C. Malveau, Hays W.…  The book covers the factors that come up repeatedly in bad software projects.  Among them is what they call the Golden Hammer which is “a single technology that is used for every conceivable programming problem”.

LSMW’s time as my hammer of choice passed a long time ago.  It’s a useful tool and should be in everyone’s toolbox but we shouldn’t use it unless there is an actual nail sticking out.

Golden_Hammer_April_2014.png

UPDATE as of August 30th, 2016

Per OSS 2287723: 

“As of S/4HANA 1511 (and higher)… The LSMW (Legacy System Migration Workbench) function is still available within SAP S/4HANA (on-premise edition) but not considered as the migration tool.  LSMW might propose incorrect migration interfaces that cannot be used in SAP S/4HANA.”

… and…

“The Legacy System Migration Workbench (LSMW) can only be considered as a migration tool for SAP S/4HANA using workarounds and careful testing for each and every object.  The use of LSMW for data load to SAP S/4HANA is not recommended and at the customer’s own risk.

To report this post you need to login first.

20 Comments

You must be Logged on to comment or reply to a post.

  1. Jรผrgen L

    Great summary, Nathan.

    I certainly support what you said, it shouldn’t be used for everything even it is handy, but sometimes we are forced to this step, but more later.

    Is the version info worth a penny?

    As you showed it stays already for a long time, but LSMW had actually changed between basis release 700 and 731.

    The radio buttons got replaced

    LSMWoldnew2.PNG

    the appearance of the read and converted data is different:

    LSMWoldnew1.PNG

    This did not really make a big difference, but the big difference is in the field mapping coding part, unfortunately it became worse. To make a minority of blind LSMW developers happy the coding became hidden after 16 lines: see my discussion LSMW – not all lines are displayed

    I am not so sure if a fancy drag and drop tool would make me really happy. My grandpa was a blacksmith, so I am used to old hammers, and some already  100 years old, they better than new hammers from the depot around the corner.

    This does not necessarily mean that I love to work with old fashioned tools. But it means that I’d rather abandon a new LSMW version if I could get more SAP delivered BAPI methods that could be used in LSMW. E.g. vendor and customer master are still without BAPI. For many transactions we do not have anything  like customer info records.

    But many times we restrict ourselves.

    Already long time ago I had seen nice browser based SAP applications, even for the Logistics modules. But they never made it into our company. We still have to use our SAP Gui. In the meantime we have got the SolMan Charm process, this is browser based, this is awful, nobody was able to get through all the steps without a handout on his desk for weeks. So even new and modern looking applications are not really as nice as Google and Amazon users expect them to be.

    Mass maintenance, I loved it, before the compliance guys restricted it. The ABAP formula must not be used. Instead I have to write an ABAP. Makes sense?

    Winshuttle – everyone wants it – nobody gets it – again the compliance hammer, nope, no Gui scripting allowed.

    I am at the very beginning to look into direction of RDS, saw the video already a few times, read the blogs more than once. It looks interesting, still I am under the impression it has more steps than LSMW and may not be suitable replacement for all my LSMWs. And it looks for me much more technical and overloaded than the old LSMW but this is impression is probably gone quickly after I get a chance to test it.

    A long way to go from here, through all our instances to get this downloaded and installed and released to be used. I have already headaches  when thinking about the trouble with the roles that I need to get this running. A project for itself.

    (0) 
    1. Nathan Genez Post author

      I thought twice about my Visio comment.  I’m working with a large BAPI (33 structures) and I don’t want to work with tiny scroll bars so maybe a Visio/Access like interface would not be suitable here.  Not sure.

      (0) 
  2. Jelena Perfiljeva

    Was actually hoping this is an announcement for some revolutionary new tool. Oh well… ๐Ÿ™‚

    It’s a good blog, Nathan, but you might be preaching to the converted.

    Mass maintenance tool does not handle all the changes and its UI was obviously designed by Spanish Inquisition (or Jive?). ABAP reports – well, I spend my days fixing barcodes in SAPScripts instead of replacing an 8-year old CATT. And it’s not like there is a BAPI for everything in SAP or that they actually work.

    Using an LSMW for something that MASS can do easily is obviously just stupid, but I’m afraid that we’re pretty much stuck with what we have until we switch to some kind of cloud- suite-on-HANA (whatever it ends up being called). I’m curious what tools await us there, although am skeptical at the same time, knowing SAP’s history.

    Couldn’t agree more that there should be some simple built-in tool to put data from Excel into SAP. By the same measure, there should be some kind of a wizard for simple ALV reports. Will we ever see this in SAP? Place your bets now! ๐Ÿ™‚

    (0) 
    1. Nathan Genez Post author

      I’ve been praying for a new report writer in ERP.  I don’t want BW, portals, or web interfaces and I don’t want a bunch of reporting tools for each functional area.  I want a single cross-app reporting tool directly in ERP that can generate nice structure and ALV list reports.  But that’s not going to happen.

      (0) 
      1. Jelena Perfiljeva

        Hear-hear, on my wish list would also be a single output functionality. Or how about a single standard for the whole system and something that actually works? That would be neat. ๐Ÿ™‚

        (0) 
  3. Alejandro Jacard Plubins

    Mass data loading? sure, LSMW is a tool that can do that, but i strongly suggest you also review SAP BODS.

    Mass data change? mmhh, here the requirement can get tricky because most of the time, business needs also require that any changes are made through the usual screens, assuming each of those has its own “custom” business logic added to the standard one.

    There is no tool to cover 100% of the cases in such scenarios, even eCATT has some nuisances……therefore LSMW will be around for a long time, what needs to change in the minds of the consultants is their absolute faith on the tool, there are other options on the market today.

    (0) 
    1. Nathan Genez Post author

      Yes… focusing on the issue of “how do I mass <insert requirement> for my <insert object>” it can be tricky.  And I’m willing to cede that a screen based tool has it’s merits in certain situations.  But I disagree that a single tool can’t do it.  This doesn’t seem like that hard of a problem if SAP put some development muscle behind it.  I like how LSMW adopts both ABAP objects and screen recordings… I just think the management of the data relationships and the pulling in of the data could be improved. 

      I think MASS uses a dialogue process so any validation/substitution or transaction variants are in effect.  I could be mistaken though.

      (0) 
  4. Sammar Razdhan

    Hi Nathan,

    Couldn’t agree more with you.. Even I feel we need to move on from LSMW and make some intelligent uploading tools with quicker error handling and processing of data.

    I think we do have some improvements in loading master data into SAP using MDM for mass upload of Material Master and GL profit/cost centers etc..

    Hope SAP does brings some changes to LSMW as well.. ๐Ÿ™‚

    Cheers

    Sammar

    (0) 
  5. Shreekar Ranade

    Fully agree with you – the gripe section in your blog is actually relevant to almost all SAP areas – in my 13 years of SAP – I have never seen any major improvements to so many areas now including LSMW, CCA, PCA, Payments, Assets, IDOCS and the list goes on and on and on.

    It is also intriguing that there is no major tool out there from a 3rd party that may help speed up the process – a tool on the lines of WinShuttle etc may be what the user community and the Functional community are waiting for!

    (0) 
    1. Nathan Genez Post author

      ZOption is a third party with a series of Excel based upload tools.  I think they have one to upload FI postings, budgets and some other scenarios.

      But neither Zoption or WinShuttle are the solution.  WinShuttle / WinRunner are just another screen recorder and since they’re non-native to SAP, I find that it performs worse.  Plus, not everyone has them.

      (0) 
      1. Clinton Jones

        I think it should be clear that there are many options available and while third party applications that connect over RFC are not necessarily the ideal method for mass actions in SAP, the other options tend to be either very technical or very limited.

        LSMW is as you rightly point out, quite frankly a sorely abused tool that auditors complain vociferously about. IT has no business messing with data in productive systems and business users have no business having access to LSMW.

        The mass transactions and even BAPIs on offer in SAP natively, even the newer and revised ones, lag behind the capabilities of the configured or customized transactions in ERP itself and often never get configured or modified to align with what the business needs so they simply never catch up or align.

        Others have proposed add-on solutions like BODI/BODS but then this quickly falls into the realm of heavy technical lifting and architecting and configuring a complex solution with a long tail of deployment before the business can actually get going with the solution. If in the interceding period the business pivots or changes direction, how quickly do these solutions re-align with the requirements of the business – experience shows that they take a long time and maintaining them comes at a tremendous technical and operational expense.

        In the absence of something better, you’re back to an agile solution that can quickly connect to the configured transaction (like MM01/MM02) over RFC and fill the screen fields in the background (BDC) or interactively (GUI Scripting).

        Performance and throughput hinges heavily on several factors but not least of these is the way the relative positioning and resources that application connects through.

        Experience also shows that the closer the client is to the SAP applications, the faster the throughput (you’re then not dealing with network latency as a degrading factor). Also consider running these sessions against a batch server rather than just any old application server on the front end. If the BDC over RFC process has to compete with regular dialog users in daily work then someone or something is going to have a bad performance experience.

        The selected scripted method also has a tremendous impact – if you use GUI scripting then yes, this is going to be dog slow as each screen gets painted and each field filled – this classic screen scraping should be avoided as much as possible. While BDC over RFC is not as high performance as LSMW you reap benefits in other ways, the user who owns the data gets to load the data ( not usually an option with LSMW) and the errors (if any) show up in the excel workbook or access database in line with the records you are trying to change or create – using other methods you often have to convert the data to CSV or text and load a text or CSV file and then try to reconcile the items to the log – not pretty and also pretty painful.

        Finally I will add that abuse of these third party tools is also often a challenge seen in the field, consider where they are positioned. They are not recommended for the millions of records data sets, do they get used for them? Sure, but should they – probably not. My experience is that once you hit about 100,000 rows of data, the question becomes one of, how long are you prepared to wait for this job to run? With throughput of around 30 fully loaded materials per minute using a single BDC session on a small ECC box can you afford almost 5 days of load time?

        Lean on an ABAP developer by all means but consider how long you can wait before a solution can be delivered for sustained productive use.

        (0) 
  6. Kenneth Moore

    That tool (LSMW) is pretty slick, but I usually use batch sessions to load mass data (t-code SM35).  I think the actual recording t-code is SM36.

    (0) 
  7. Ryan Fleischmann

    Nice retrospective on LSMW. I don’t think we’ll ever get an alternative to it in the SAP GUI. However, as more SAP applications move to HANA S4, I think there’s a very good chance you’ll get far better options there (if there aren’t any already available)

    (0) 
  8. Corina Smith

    Great document.  I just recently used MM17 and the upload from spreadsheet function to create and update materials for a recent conversion and it worked great.

    (0) 
  9. Jรผrgen L

    I attended a data migration webinar for S4HANA on promise yesterday and the outcome was pretty clear: LSMW got moved into the death chamber. The transaction is still there but of less use

    Reasons: with S4HANA many transactions will be replaced with Fiori Apps which do not allow recording.

    Content in LSMW will not be adjusted, which means you still see the same objects when you do F4 in the LSMW step 1 to select a desired import program as it is today, but these programs may not work on S4HANA. Example: vendor and customers will be replaced by SAP Business Partners function. Neither the old batch input nor the IDoc is able to support this, BAPI method for those 2 objects had never been around.

    It was clearly said that we shall not just use the old LSMW objects after the upgrade to S4HANA and redevelop them.

    (0) 
    1. Nathan Genez Post author

      Interesting… but does it help prove my point and will stop people from (mis)using LSMW for simple batch / script recordings when they should be developing a fuller featured BAPI-based solution?  That’s good news.

      (0) 
  10. Nathan Genez Post author

    I’ve been working on S4HANA 1511 and recently stumbled upon OSS 2287723.  I’ve added a closing note at the end of the blog with some excerpts from the note.

    (0) 

Leave a Reply