SAP Mass Upload Without LSMW
Teams asking how to run SAP mass uploads without LSMW usually have one specific problem rather than a general one: a monthly load nobody understands, a broken project, lost skills, or an approaching conversion. The right answer differs in each case, so naming the situation comes before choosing a tool.
- Only one of six situations is a migration problem. The other five are operational, and operational loads were never what LSMW was designed for.
- Try standard mass maintenance first. MM17 and KS12 are free, installed, and adequate where the field is exposed.
- Extract the mapping before decommissioning anything. The project is often the only documentation of what it does.
- Run both routes in parallel for one cycle. The cheapest possible proof that the replacement does what the original did.
- Retire the old project deliberately. Leaving it runnable means it will be run by accident.
Loading SAP data without LSMW
Teams asking how to do mass upload without LSMW usually have one specific problem rather than a general one. A monthly load runs that nobody understands, a project has broken and cannot be fixed, the skills have left, or a conversion is approaching. The right answer differs in each case, which is why naming the situation comes before choosing a tool.
The LSMW alternative guide covers what replaces it across a whole estate. This page is narrower: what to do about the load in front of you.
Which situation are you in
The monthly load nobody understands. The commonest case by some distance. It runs, it works, and the person who built it left three years ago. Nothing is broken yet, and that is exactly why it is worth addressing now rather than when it breaks.
The broken project. A support pack or configuration change has stopped a recording-based step working, and nobody can diagnose it. Reactive, urgent, and often the trigger for finally replacing rather than patching.
The frozen project. It works, but no change to the underlying business process is possible because nobody can modify the load. This blocks more than it appears to: process improvements get abandoned because the load cannot follow.
The approaching conversion. Everything needs rebuilding anyway, so the question is when rather than whether. Doing it deliberately beforehand costs about the same as doing it under go-live pressure.
The new requirement. A load is needed and LSMW is the habit. Worth resisting, because starting a project on it now means building something with a known end date.
Genuine cutover. The one case that points at a migration tool. If the job really is a one-off conversion load, Migration Cockpit is the intended path and this page is not about your problem.
What to use instead
Three routes cover the recurring case, and they are worth trying in order.
Standard mass maintenance first. MM17 for material master, KS12 for cost centres, and their equivalents elsewhere are free, already installed, and adequate for a large share of simple sweeps. Where the field is exposed and the population comes from a selection screen, this is the answer and there is nothing more to do.
An Excel task pane where the population comes from a list. Selection screens are built for criteria rather than for four thousand record numbers supplied by the business. Where the file arrives from finance, procurement or HR, and each record needs a different value, this is the shape that fits.
A custom build where neither reaches. Real, occasionally necessary, and the most expensive of the three to maintain. Worth reaching for only after the first two have genuinely been ruled out.
Replacing a recurring load
Six steps, and two of them are the ones people skip.
Extract the mapping before decommissioning anything. The column-to-field relationships, conversion rules and validation logic inside an LSMW project are frequently the only documentation of what it does. Once the project is gone, so is that knowledge. This is the single most important step on the page.
Run both in parallel for one cycle. Same file, both routes, compare the result. It is the cheapest possible proof that the replacement does what the original did, and it turns a leap of faith into a verification. Teams skip it because it feels like duplicated effort, and it is the step that prevents discovering a difference in production.
The others are straightforward: find out what the project actually loads, check whether a published interface covers the object before assuming it does not, rebuild the mapping rather than the project structure, and retire the old project deliberately so it cannot be run by accident.
Where PostNow fits
PostNow covers the recurring load case
Most LSMW projects still running monthly are doing what a published interface handles directly. PostNow adds a task pane to Excel, signs in with your own credentials, and keeps the mapping where the business can see it.
The mapping lives in the workbook, not inside a project nobody can open.
Published interfaces, so validation and change documents behave normally.
Run by whoever prepares the file, not only by whoever built it.
Remaps at conversion rather than needing a rebuild.
Step by step
Common mistakes
- Treating it as a general problem. Five of the six situations are operational and only one is a migration question.
- Decommissioning before extracting the mapping. The project is often the only documentation of what it did.
- Skipping the parallel run. One cycle of both is the cheapest verification available.
- Assuming no published interface exists. Coverage is better than reputation suggests for high-volume objects.
- Not trying MM17 or KS12 first. Free, installed, and adequate for simple sweeps.
- Leaving the old project runnable. It will be run by accident eventually.
Complete reference
Go deeper
Moving off LSMW
The estate-level view: what replaces LSMW by scenario and how to retire it.
Method comparison
Whether a published interface covers your object, and what to do if not.
SAP mass upload
The pillar guide covering validation, error handling and governance.