Replacing SAP EWM with a local WMS: how the warehouse cutover actually works

Short answer: a warehouse cannot be replaced process by process the way a finance or procurement module can. It switches over as a whole site and inside one window, so the schedule is counted in sites and standstill hours rather than in months of development. Most of the effort goes into getting the accumulated rules out of SAP EWM, putting the new system exactly where EWM sat in the data exchanges, and surviving the first week, when picking slows down.

The general order of a SAP replacement is covered separately, in our staged migration methodology. This piece is about the warehouse, and about the switchover itself.

What “switching over a warehouse” means

A site has one bin topology, one stock figure and one task queue. You cannot run half of it on the new system and half on the old one: a picker who takes a task in one system and puts goods into a bin only the other system knows about breaks both stock figures inside a single shift.

That has a plain consequence for the plan. A network of five warehouses means five switchovers, each with its own standstill, its own stocktake and its own first week. A project that looked like one date on paper turns out to be five different days spread over months.

What has to come out of EWM before the date

This is the most underestimated part of the work. Years of operation leave dozens of rules inside EWM that nobody remembers any more and that work every single day. While the system is alive they can be exported and read. Once it is switched off, all that is left is interviewing pickers and guessing.

What to extract:

• The topology. Zones, bin types, dimensions and weight limits, addresses.
• The strategies. Putaway rules, picking rules, task priorities, the wave structure. Separately, the exceptions set up for particular customers or particular goods.
• Print templates and labels. Barcode formats, sizes, printers, pallet tag layouts. Projects lose a fortnight here, because a label cannot be “approximately reproduced”: a scanner at the customer’s goods-in reads it.
• The interfaces with ERP. Goods receipt against an order, shipment confirmation, internal movements, stocktake discrepancies. Every exchange needs its field list and a real message example, not a description in the documentation.
• Packaging hierarchies and units of measure. Each, case, pallet, conversion factors, weights. A mistake here does not show up at go-live, it shows up a month later, when shipped volumes stop reconciling.
• Roles and permissions. Who can write stock off, who approves a discrepancy, who closes a stocktake.

A good sign that this stage is done: from the documents you have collected, the warehouse can be described to someone who has never seen SAP.

The stocktake and the length of the standstill

A switchover starts by stopping movements and counting. The new system opens with balances counted by hand rather than copied from the old database: moving figures that have already drifted away from the shelf moves the error along with them.

Three things set the length of the window: the number of storage addresses, whether book stock matches physical stock, and what the counting is done with. A small warehouse with handheld terminals fits into one shift. A large one counted manually takes a weekend. If stock in EWM has been running with discrepancies for months, the window grows unpredictably, which is a reason to count one zone a week ahead of the date.

Movement history is not dragged into the new system. It stays in an export for reading: reports on past periods are closed by ERP, not by the warehouse system. How that works in the general case is covered in migrating data from an old system.

The first week after go-live

Picking slows down in the first days, and that belongs in the plan rather than counting as a failure. A picker who knew the site by heart for three years spends a week reading prompts off a terminal.

What follows from it:

The date is not set on a shipping peak. Month end, the week before a holiday and the day a large delivery arrives are not switchover days.

People are added to the first shifts. Not developers: your own pickers from other sites, or temporary staff.

Double-checking at dispatch stays in place until picking errors come back to their usual level. One wrong shipment costs more than an extra person at the gate.

Errors go into a log the same day. Half of them turn out not to be system errors but putaway rules that were carried over literally, although the warehouse had been working around them for years.

On a manual or semi-manual site the usual pace returns within one or two weeks. Where EWM drove warehouse automation, conveyors and sorters, the conversation is different: there the changeover is proved on a live line, and the schedule is set by the exchange with the equipment controllers rather than by the WMS.

How long a rollback stays available

A rollback lives exactly until the first shift of real movements has run on the new system. While EWM is still switched on and its stock matches the shelf, you can go back within an hour. After a shift of picking, receiving and internal movements, going back means a second stocktake, which means another standstill window.

So the rollback criteria are written down as numbers in advance, and a time is named at which the decision is made against them. A workable criterion looks like this: if by the end of the first shift the system cannot issue tasks for more than a tenth of the lines, we roll back. One named person on the client side makes that call, not a meeting.

Which site to start with in a network

Start with a simple site rather than the main one. Fewer addresses, no automation, a shift of standstill that does not break deliveries. That is where the mistakes in strategies and labels surface, the ones that would have cost a large site its dispatch day.

The second switchover runs about twice as fast as the first: the rules are already written down, the interfaces are already built, and what remains is the topology with its own quirks. That margin is what makes the order of sites matter more than the start date. General timings for a SAP migration are collected in what a SAP migration’s timeline depends on.

When SAP stays in the ERP layer

Sometimes only the warehouse changes: ERP stays on SAP and EWM comes out. The new warehouse system then has to sit exactly where EWM sat in the exchanges, with SAP remaining the source of master data. In that case the interface is designed before the product is chosen: the composition of the exchanges decides which of the systems on the market is suitable at all.

The opposite case, where ERP leaves together with the warehouse, is easier on integration and harder on organisation: there are two switchovers now, and putting them on the same day is a bad idea.

Common questions

Can a warehouse be switched over with no standstill at all? No. What is negotiable is the length of the window, not its existence. It gets shorter through counting zones in advance and moving the date onto a quiet day.

Is a custom-built WMS needed instead of an off-the-shelf one? Rarely. Products on the market cover an ordinary warehouse, and custom development earns its place where the process genuinely does not fit any of them. The choice is unpacked in the methodology, and one replacement from the manufacturing side is described in our WMS case.

What does it cost? The estimate is built from the number of sites, the volume of strategies and the number of live integrations. What goes into it and what inflates it is covered in what replacing SAP costs.

How many people are needed on the client side? One person per site who owns the warehouse and can stop the switchover, plus a picker who knows the exceptions. Without the second one, putaway rules get carried over from the documentation rather than from life.

The rule

The switchover date is set after the strategies, print templates and interfaces have been pulled out of SAP EWM, not before. A date set earlier always moves, and it moves by the standstill window that has already been agreed with the warehouse’s customers.