A site that has run classic WM for fifteen years has a system that describes a warehouse. Whether it describes the warehouse standing on the concrete today is a separate question, and it is the one a migration quietly depends on. This note is part of the series that hangs off our brownfield EWM service, and it covers the data: what SAP's tooling will move, and the long list of things it will not fix for you.
What the SAP tooling actually moves.
SAP publishes a migration guide for going from ERP LE-WM, or from S/4HANA Stock Room Management, to EWM on S/4HANA. The migration runs per warehouse number, which matters: a business with several sites can move them one warehouse at a time rather than in a single event. The tools cover warehouse product data, storage bins and stock. Since S/4HANA 2023 FPS1 there are also migration objects, loaded through staging tables, for storage bins, bin sorting, fixed bin assignments and warehouse stock. EWM master data and customising can be moved with the SAP S/4HANA Migration Cockpit.
That is a useful toolset and nobody should hand-key forty thousand bins. But read the list again. Every item on it is a thing that exists in the system. The tools have no view of the building.
What it leaves to you.
Everything that follows is a case of the system and the floor disagreeing. None of it stops a load from succeeding. It just arrives in EWM, where it does more damage than it did in WM.
Bins that are no longer there.
Racking gets reconfigured. A run of pick faces is pulled out to make room for a returns bay, a mezzanine goes in, an aisle is widened for a reach truck. The bins in the system often outlive the steel. Migrate them and EWM will happily offer put-away into a location that is now a piece of painted floor. Someone has to walk the aisles, or at minimum compare the bin master against a current layout drawing, before the load file is built.
Stock the system believes in.
Every long-running WM site carries some quantity that exists only on paper: a pallet consumed without a posting, a short-pick nobody corrected, a difference that has sat in a clearing bin for years. The migration will bring it across as stock. Then EWM will try to allocate it to an outbound order and a picker will stand in front of an empty bay holding a task.
Dead products and fixed bins nobody uses.
Warehouse product data tends to accumulate. Products discontinued years ago, one-off promotional lines, materials extended to a warehouse number for a project that ended. Fixed bin assignments are the same story: a pick face assigned to a product the site stopped stocking, still reserved, still blocking a location. A migration is the cheapest moment you will ever get to prune these, because after go-live every dead record is one more thing a planner has to explain.
Dimensions, weights and packaging.
WM could get away with thin product data. Plenty of sites ran it for years with missing or approximate dimensions because the system never really asked. EWM leans on them much harder: for put-away, for capacity checks on storage bins, and later for slotting and cartonisation if you license and switch those on. Wrong or blank dimensions and weights do not fail loudly. They produce put-away that looks plausible and wastes space, or capacity checks that block a bin a pallet fits in. Fixing the master data after go-live means fixing it while the floor is running against it.
Handling units WM never managed.
Handling units are central in EWM. Many WM sites tracked stock by quantity and bin, with pallets existing only as a physical fact. There is no handling unit to migrate, so someone has to decide how stock will be represented from day one, and what a scanner does when it meets a pallet that the system has never heard of. Our note on master data for a new warehouse covers the product side of this in more detail; the same disciplines apply on a migration, with the extra burden that the old data has habits.
Clean before you move.
The order matters. Clean the source, then extract, then load. The opposite order, which is to migrate and then tidy in EWM, means you are correcting data in a new system with new users who have no way of telling an error from a rule. It also means the first weeks of hypercare are spent on data questions when they should go on the floor.
In practice this is a set of unglamorous lists. Bins in the system with no physical location. Products with no movement in a period the business agrees is long enough. Products with a zero, a blank or an implausible dimension or weight. Fixed bins whose product has not been picked from them in living memory. Each list goes to a named person with authority to say delete, keep or correct.
Count the stock, and finish the open work.
Reconcile system stock against a physical count before the freeze, not after. If you migrate first and count later, every difference becomes a stock adjustment in a brand new system, with a financial posting, on a floor that is still learning how to use it. Counted and corrected in WM, the migration carries a number you already trust.
Open transfer orders are the other half. SAP's guidance is to finish or cancel them before the freeze rather than count on them to migrate. WM works in transfer requirements and transfer orders; EWM works in warehouse requests, warehouse tasks and warehouse orders. They are different objects with different logic, and a half-confirmed movement is the hardest thing in the building to translate. Set a cut-off, let the floor work the queue down to nothing, and cancel what is left on purpose.
A migration does not clean your data. It makes your data permanent in a new system, at exactly the moment the floor has the least attention to spare for it.
Owners, rehearsals and reconciliation.
Each data object needs a named owner who signs it off. Not the integrator and not the IT team: the person who would be in trouble if it were wrong. The inventory controller owns stock. Someone from operations owns the bin structure, because they know which aisles were rebuilt. Someone in product or purchasing owns dimensions and packaging. When a load throws a query at two in the afternoon, there should be a name attached to the answer.
Then rehearse. Load the data into a test system more than once, and after each rehearsal reconcile it: bin counts against the source, stock quantities against the source, a sample of products checked against the shelf. The first rehearsal finds the surprises. The later ones prove the fixes held. A single dress rehearsal the week before the freeze is a test of nerve, not of the data. How the load fits inside the weekend is a separate subject, and we cover it in cutting over a live warehouse.
Customising is designed, not copied.
The Migration Cockpit can carry EWM master data and customising, but customising is not a one-to-one copy of your WM set-up. EWM structures (storage types, activity areas, warehouse process types, process-oriented storage control) are designed, not translated. There is no field in WM that becomes a warehouse process type by conversion. Someone has to decide what the processes are.
That decision is where the like-for-like conversation begins. Reproducing the old set-up exactly is one answer and sometimes the right one. Rethinking it is another. Which one you choose changes how much data work is mechanical and how much is design, and we take it up in like-for-like or redesign.
How Luminar approaches the data.
We are independent and we do not sell the build, so we have no load tool to justify. A senior consultant spends time on the floor with the bin master in one hand and a layout in the other, because that is where the discrepancies show up. The output is a short list of what to clean, who owns each object, and what the reconciliation after each rehearsal should look like. If you have run a migration of this kind before and want a second pair of eyes, or if you have not and want to know what you are walking into, that is the conversation to have before the freeze date is set.