Migrating from WM to EWM: 6 lessons nobody warns you about
SAP WM → EWM (Embedded) in a complex manufacturing environment
When a "simple" upgrade stops being simple
They say SAP Extended Warehouse Management (EWM) is the successor to Warehouse Management (WM) and that migrating is a natural step forward. And that's essentially true — EWM brings richer functionality, better monitoring, more sophisticated control of warehouse processes, and finally a proper overview of what's happening on the floor, without having to call every shift supervisor. Then comes the reality check.
The project I'm writing about was an SAP S/4HANA implementation with Embedded EWM for a large industrial manufacturer — a Tier 1 supplier in the automotive industry. It was a company with several managed warehouses covering receiving, production, shipping, and inter-warehouse transfers, where each warehouse had dozens to hundreds of storage types. The total number of storage types across the company exceeded several hundred. Complex putaway and picking strategies were attached to these types, many of which existed only in the heads of experienced users and in comments inside ABAP code nobody had read in a decade. The original WM had been heavily modified over the years — we're talking about dozens of custom transactions and a range of Z-tables driving process configuration. In short: this wasn't greenfield. It was brownfield with layers of paint, and nobody quite knew what was under the third layer. And yet — the project succeeded. Here are six things I learned along the way.
Six lessons from the migration
The problem, the reality, and the recommendation from each one
Lesson 1: Org structure — dive in, but don't overdo it
The original idea: let's tidy up along the way. While planning the migration, a logical idea came up: since we're changing the system anyway, why not do more than a technical move and also straighten out the organizational structure? Merge storage types that serve the same purpose across warehouses (why have eight variants of a "rack storage area"?), unify naming conventions, rationalize storage zones… On paper it looked great.
Reality. SAP provides migration tools for moving from WM to EWM. These tools work on a 1:1 mapping principle — Storage Type in WM = Storage Type in EWM. Trying to remap the organizational structure in the middle of a migration is like trying to rebuild a house's foundation while you're still living in it and moving furniture around. Manually configuring several warehouses and hundreds of storage types is extremely time-consuming. And that's before you factor in that every mapping change propagates into the stock migration — and stock in a complex manufacturing environment is not something you joke around with.
Recommendation. Carry the existing organizational structure over 1:1. It's safe, predictable, and the mapping tools are built for it. What is perfectly fine — and what we recommend — is renaming according to EWM conventions, as long as you keep the naming logic from WM. For example, Z01 → Z001 is a cosmetic change that also brings your system in line with EWM conventions. A large reorganization? Save it for later — for a "phase two" that will almost certainly never happen, because you'll remember phase one for a long time.
Lesson 2: HU Type — align it early, or you'll regret it
A problem that looks like a detail. In EWM, the Handling Unit (HU) Type is in many cases derived directly from the packaging material. One packaging material = one HU Type. This is standard logic and, at first glance, nothing dramatic. It starts getting dramatic when you discover that the same physical container (say, a 600×400 plastic bin) was recorded under different HU Types across different managed warehouses. Why? Because over the years each warehouse did its own thing, nobody enforced it centrally, and WM tolerated it. In WM, the HU Type was a loose concept — in EWM, it's a hard constraint.
In the project I'm describing, WM originally had several hundred HU Types. Some were duplicates or differed only by naming convention. Putaway strategies, capacity parameters, and RF processes were all attached to these types. Consolidating them required analysis, remapping, and several rounds of testing.
The takeaway. This was one of the biggest "surprise" workloads of the project from the customer's side. Underestimate it and you'll be chasing inconsistencies well into hypercare, which — as you'll see in Lesson 6 — is not a kind of fun anyone wants.
What to do:
Inventory packaging materials and HU Types as the first step of the analysis phase, not the last
Build validation tools to check consistency across warehouses
Establish clear governance: who approves changes to HU Types?
Simply put: don't underestimate this. It's the quiet risk in every WM-to-EWM migration at scale.
Lesson 3: Integration with existing processes — EWM is only part of the story
What's "out of EWM scope" — but not out of project scope. EWM controls the warehouse. What happens outside the warehouse — backflush from production (MFBF), movements in IM (Inventory Management) — is technically out of scope for EWM. But "out of scope" doesn't mean the customer stops needing those processes the moment Go-Live happens.
The project had to cover a whole range of processes that the existing WM solution had historically handled "on the side" — through user exits, custom report programs, or informal workarounds.
Lesson learned. Start analyzing these "outside-EWM" processes as early as possible after the blueprint phase closes. The longer you wait, the higher the risk that the Go-Live date arrives before the implementation is finished. Practically speaking: map all existing WM user exits, custom programs, and informal processes as part of the analysis phase. Each one is a potential functional gap in EWM.
Lesson 4: EWM looks like WM — but it isn't WM
The biggest mistake experienced users make. Paradoxically, the biggest risk to EWM adoption doesn't come from users who don't know SAP. It comes from users who know SAP very well — and have ten years of WM experience. These people arrive with deeply ingrained habits. They know how to navigate LT0A, what a Transfer Order is, how HUMO works. And that very knowledge becomes a brake, because EWM works differently.
The most frequently repeated message on this project was: "ERP HU and EWM HU are two different things." We communicated this from the very first demo session, through training, all the way to hypercare support.
What to do about it:
Emphasize the differences from day one — don't say "EWM works similarly to WM." Say specifically: "In EWM you have a Warehouse Task instead of a Transfer Order. Reports like LT0A or LX03 live in the /SCWM/MON warehouse monitor. HUs in EWM are a different entity than HUs in HUMO."
Show the benefits immediately — /SCWM/MON isn't a replacement for one transaction, it's a single place to see and run the whole warehouse. Let users get their hands on it early — enthusiasm is the best motivator for changing habits
Communicate repeatedly — one training session isn't enough. Key messages need to land multiple times, in different contexts
Prepare cheat sheets — a printed "WM transaction → EWM transaction" mapping posted next to every RF scanner saved more than one shift
Lesson 5: Migration — easy in training, hard in battle (this time it's literal)
The destructive nature of migration. Migrating from WM to EWM is a destructive operation in a specific sense: once you post stock through the interim warehouse, the way back is very complicated. It's not like Ctrl+Z. It's more like moving furniture from an apartment into a new house — if you find out the table doesn't fit through the door, there's a solution, but it's going to hurt. So this rule holds without exception: every scenario that can happen in production must be tested first. Then tested again. And then once more.
Batch the migration. If you're migrating thousands of storage units and handling units at once, it's strongly recommended to split the migration into smaller batches. The reason is simple: if the import crashes partway through, the blast radius is directly proportional to the batch size.
This isn't theory. On the project, there was a situation where a Saturday evening migration run crashed — due to a circumstance no migration plan can foresee: the finance department was clearing an invoice against a purchase order — on a Saturday night, late, on a system that was supposed to be locked for the duration of the migration. The result: blocked material caused the import to fail. Instead of the planned 60 minutes, the team spent from 11 PM rolling stock back, identifying the problem record, resolving it, and re-running the import. The whole thing took several hours.
Lesson learned: migration is a team discipline — it involves not just IT and consultants, but also finance, procurement, and logistics, who need clearly defined activity freezes for the duration of the migration window. This has to be formally approved and communicated.
Practical rules:
Test migrations (at least 2–3 cycles) in a test system using production data
Batching — prefer smaller groups of records with checkpoints
Rollback plan — it must exist, be tested, and everyone must know where it's stored
System freeze — in writing, with sign-off from the business side
Lesson 6: Nothing prepares you for Hypercare
What Hypercare is. Hypercare is the period immediately after Go-Live when the consulting team is available to support users. On the project plan, it looks like a reasonable time buffer for mopping up loose ends. In practice, it's a survival challenge.
Users who spent months in training saying "yes, we understand" suddenly discover that SAP in production is different from SAP in training. Processes that worked fine in the test system behave differently in production — because production data is different, production volume is different, and the users' stress level is different. Tickets arrive in waves. Some are trivial, others are urgent and require immediate analysis. Telling a system bug apart from a user error is an art in itself.
What this means for you. Nothing you read in this article will fully prepare you for Hypercare. It has to be experienced. What does help:
Robust monitoring — /SCWM/MON, a custom alert monitor, qRFC monitoring — all of it must be set up, functional, and watched
A clear escalation path — who handles what, where critical issues get reported
Documentation for key users — internal "quick reference" cards for the most common scenarios
Patience — you can't configure that in SPRO
And to close with full honesty: Hypercare is the phase where you find out what the project was really worth. A well-prepared system, well-trained users, and well-designed processes survive this phase. Everyone else... survives it too, but with a scar.
Summary: 6 lessons at a glance
| # | Lesson | Key message |
|---|---|---|
| 1 | Org structure | Migrate 1:1, rename to convention, save big changes for later |
| 2 | Aligning HU Types | Inventory packaging materials first, build validation mechanisms |
| 3 | Process integration | Analyze "outside-EWM" processes early, don't delay development |
| 4 | EWM ≠ WM | Emphasize the differences repeatedly, show EWM's benefits from day one |
| 5 | Migration | Destructive, batch it, test it, freeze the system — formally |
| 6 | Hypercare | Can't be taught, only survived. Prepare monitoring and nerves |
Frequently asked questions about WM to EWM migration
Is migrating from WM to EWM just a technical upgrade?
No. Although EWM is the successor to WM, it isn't a simple upgrade. EWM works differently (Warehouse Task instead of Transfer Order, different HU logic, stricter rules for handling unit types), and in a complex brownfield environment you have to plan for process analysis, master data consolidation and extensive testing.
Should I clean up the organizational structure during a WM to EWM migration?
We recommend migrating the organizational structure 1:1. SAP migration tools work on a Storage Type WM = Storage Type EWM mapping, and large reorganizations mid-migration are risky and time-consuming. Renaming to EWM conventions is fine if you keep the original naming logic; leave big changes for a separate project.
Why is unifying handling unit (HU) types so important?
In EWM the handling unit type is often derived directly from the packaging material and it's a hard constraint, whereas WM was more lenient. If the same physical packaging was recorded under different types across warehouses, you must unify them before migrating. Put a packaging material inventory as the first step of the analysis, not the last.
How do I prepare for the hypercare phase after go-live?
Hypercare can't be fully simulated, but robust monitoring (/SCWM/MON, qRFC, custom alerts), a clear escalation path, quick-reference documentation for key users and WM-to-EWM transaction cheat sheets all help. It's also essential to batch the migration, have a tested rollback plan and a written, business-approved freeze of the systems for the migration window.
