Early in most WM migrations someone says "let's just move what we have." Within a week someone else says "if we are spending this money, we should fix everything." Both sentences sound like prudence. Both, taken literally, produce a bad programme, and the scope document tends to be written in the gap between them without either being tested against the floor. The brownfield position we hold is that a migration should not import the legacy system's habits. That is easy to say and hard to apply, so here is how we apply it.
Two ways this fails.
The pure technical lift.
The programme treats the job as data and code movement. Storage bins, stock and product data go across, the Z programmes get rewritten to run against the new structures, the RF screens are rebuilt to look as close to the old ones as EWM allows. On the day of go-live the business has paid for a new system and got its old warehouse back, with the same workarounds now living in a product SAP is actively developing. Every hack that WM tolerated is now inside a framework that was designed to make it unnecessary, and it fights the standard every time SAP delivers something new.
The redesign of everything.
The opposite programme uses the migration as licence to change every process at once: putaway logic, picking method, replenishment, counting, the lot. It looks good in workshops. On the floor it means every operator, every supervisor and every carrier interface changes on the same weekend, and nobody can tell whether a problem on Monday is the new design, the new system or the new people. A live operation cannot absorb that much change in one move. It goes down, or it survives by quietly rebuilding the old ways underneath the new screens, which is the technical lift again by another route.
Why like-for-like is never literal.
There is an honest reason the first position cannot be delivered even if you want it. WM works in transfer requirements and transfer orders. EWM works in warehouse requests, warehouse tasks and warehouse orders, with handling units at the centre, and it adds process-oriented and layout-oriented storage control, activity areas, warehouse process types, resource and queue management and its own RF framework. SAP's migration tooling moves warehouse product data, storage bins and stock, and the migration runs per warehouse number, so you can go warehouse by warehouse. But customising is not copied across. Storage types, activity areas, warehouse process types and storage control are designed in EWM, not translated one to one.
So the question was never "do we redesign?" Someone designs the EWM structures, whatever the scope says. The question is how far from the current operation that design is allowed to move, and who decides. If nobody decides, the configuration consultant decides, one storage type at a time, and you find out at user testing.
Three buckets, and a rule for each.
We sort every process into one of three buckets. The sorting is done with the people who run the process, on the floor, not in a meeting room. (The gap between what the system says and what the floor does is the whole subject of the four moments where system and reality part company, and it is where the sorting starts.)
Lift it: keep the process, rebuild it in standard.
A process goes in this bucket when it already runs on standard WM behaviour, the floor trusts it, and it is not costing labour through re-handling, searching or double keying. Nobody argues about it. Ask the shift supervisors which processes they never think about; that list is usually your lift list. The work is to design the EWM equivalent so operators meet something familiar, and to resist the urge to improve it while you are there.
Redesign it: the process was bent to fit WM.
A process goes here when it depends on custom code, a spreadsheet beside the system, or a place where operators route around the transaction. Those are the fingerprints of a requirement WM could not meet. The custom code is the obvious one, and the case against defaulting to Z code applies with more force on a migration, because you are about to pay to rewrite it. Ask what the code is for. Often EWM covers the requirement in standard and the rewrite is money spent to keep a habit.
Defer it: a nice-to-have goes after go-live.
Some ideas are good and still do not belong in the first release. A new slotting approach, a different replenishment trigger, a dashboard nobody has today. If the operation runs safely without it, park it on a written list and take it into continuous improvement once the floor has settled. Deferring is a decision with an owner and a list, not a polite way of dropping the idea.
A decision rule per process.
For each process in scope, three questions, in order.
First: does it run on standard behaviour today, with no custom code and no workaround beside it? If yes, and the floor trusts it and it is not eating labour, lift it. If any of those three conditions fails, go to the next question.
Second: does it depend on custom code, an off-system spreadsheet, or operators skipping a step? If yes, redesign it towards standard EWM, and make the person who wants to keep the custom version argue for it against what standard now offers. Where the custom logic really does encode something the business needs, keep it, but as a named exception with an owner.
Third: if the process is neither broken nor bent, only improvable, defer it. The test is whether the operation can run safely on day one without the change. If it can, it waits.
The rule will not sort everything cleanly. A process that half works, with a spreadsheet used by one team and ignored by another, needs someone to stand there and watch it for a shift. That is the judgement call, and it is worth paying for.
Why the migration is your one chance.
It is tempting to defer everything difficult, because a live floor is fragile. Resist that for the redesign bucket in particular. A migration is often the only point at which the budget, the executive attention, the testing effort and the floor's tolerance for change all exist together. Once the programme closes, nobody funds a project to remove Z code that works, or to retire a spreadsheet that people are used to. The bent parts of WM become the bent parts of EWM, and the licence is paid twice for one old habit.
The same reasoning is why the redesign bucket has to stay small. Fixing what was bent is a funded, testable piece of work. Redesigning what was working is a way of spending the one chance on the wrong things.
Lifting everything buys you the old warehouse in a new system. Redesigning everything buys you a warehouse nobody can run on Monday. The work is telling the two apart, process by process.
What a live floor costs.
We are cautious about drawing straight lines from a case study to a scoping argument, but one is worth reading with this in mind. In our EWM rescue, a national operation had gone live on EWM with another team and could not scan. We stabilised it in 90 days, and scalability improved by roughly 70 per cent. The causes were on the floor, not in the configuration: the wrong barcode symbology, scanners that did not suit how operators move, labels that would not read. Scope and design decisions made on the floor, before build, are the cheapest place to catch that kind of problem.
How Luminar approaches the scope.
We are independent and we do not sell the build, so we have no configuration to protect and no reason to inflate the redesign bucket. A senior consultant spends time on your floor before the scope is written, watches the processes the WM super-users describe and the ones they forget to mention, and returns three lists: what lifts, what is redesigned and why, and what waits. Each item has a name against it. The programme can then argue about the lists, which is a much better argument than the one it started with.