s4hana · ewm · change management · automotive · migration · 2026
Why S/4HANA Migrations Stall
S/4HANA migrations often turn into pure technical lifts. Here's what happens when the business side gets left behind — from real automotive rollouts.
Most S/4HANA migrations I'm watching right now aren't failing because of technology — they're stalling because no one told the warehouse what's actually changing.
I'm knee-deep in EWM rollouts at German automotive plants, and the pattern is clear: IT pushes the migration timeline, consultants rebuild configurations in S/4, and the people scanning parts in the warehouse find out two weeks before go-live that their screens look different. Then everyone acts surprised when adoption is slow.
The Technical Lift vs. The Business Reality
Here's what a typical timeline looks like from where I'm sitting:
- Month 1–6: Infrastructure teams migrate systems, consultants rebuild custom code
- Month 7–8: Integration testing between EWM, MES, TMS — finding gaps no one documented
- Month 9: First time anyone asks "so what changes for the warehouse staff?"
- Month 10: Panic training sessions and a go-live that technically works but operationally limps
The S/4HANA migration itself usually goes fine. The EWM module comes up, stock balances transfer, outbound deliveries process. But the business process that was supposed to improve? That part often gets dropped entirely.
I just read this piece on SAP Insider about S/4HANA migration strategy, and it lines up with what I'm seeing — the technical migration is table stakes. The real work is changing how people operate afterward.
Where It Falls Apart in Logistics
In warehouse management specifically, here's where I keep seeing the disconnect:
Custom RF transactions that nobody documented. The old WM system had 15 custom Z-transactions for material staging. In S/4HANA EWM, those need to be rebuilt or replaced with standard /SCWM/* transactions. But no one mapped which custom process served which business need — so we rebuild them all, even the ones that were workarounds for a problem that no longer exists.
Training that shows screens, not decisions. Warehouse staff get a two-hour session showing them where buttons moved. What they don't get: why we're now using wave management instead of manual picking, or what the new exception-handling process is when a storage bin is blocked. Then they hit the first real exception on go-live and fall back to the old workaround — which doesn't exist anymore.
Integration blind spots between EWM and production. MES sends a staging request to EWM, EWM creates a warehouse task, but the priority logic changed in S/4 and now urgent production orders wait behind standard replenishment. This isn't an EWM bug — it's a business rule that no one revisited during migration because IT handled EWM and Operations handled MES and they only talk when something breaks.
What Actually Moves the Needle
The projects that don't stall have a few things in common:
Someone from the business side owns the "why" before technical design starts. Not a consultant explaining SAP Best Practices — an actual logistics manager saying "we're doing this because our current pick path wastes 40 minutes per shift and S/4 can optimize it." When warehouse staff understand the business driver, they tolerate the learning curve.
Integration workshops happen with both IT and operations in the room. The EWM consultant, the MES consultant, and the shift supervisor who actually stages material all sit down and walk through one real end-to-end scenario. Not a happy-path demo — a real "this pallet is damaged and this bin is full, now what?" scenario.
Training covers the first exception, not just the first transaction. Show people the standard process, then show them what to do when it breaks. In EWM, that often means: here's how to create an ad-hoc warehouse task, here's how to check why a task is stuck, here's who to call if the integration to SAP TM times out.
The Part No One Wants to Hear
Doing this right takes longer and costs more than the pure technical lift. You need more workshops, more documentation of current-state processes, more time with business users who are already stretched thin on daily operations.
But the alternative is what I keep seeing: a technically successful migration that delivers zero operational improvement, followed by six months of "stabilization" where we fix the process gaps we should have addressed up front.
If you're planning an S/4HANA migration that touches logistics — EWM, TM, YL, whatever — don't let it turn into a pure IT project. Get the warehouse involved early, map the real business processes (not just the SAP transactions), and plan for the fact that people need to change how they work, not just where they click.
Happy to compare notes if you're in the middle of one of these — markus-mildner.com or find me on LinkedIn.