WMS replacement lessons from the people who ran them

First question: is it a replacement, or a misconfigured rollout?

A lot of "we're replacing our WMS" projects are really "the system we own was never configured to fit our operation." Go look first at what the current system is actually doing badly: wave planning that nobody trusts, slotting that was set once in 2019, a picking path that forces extra travel, interfaces that batch when they should be real time. If the complaint is about configuration and process, a re-implementation of the system you already have is often a fraction of the cost and risk of a replacement — and it teaches you things you will need anyway if you do replace it later. Practitioners who skipped this step tend to rediscover the same problems in the new system, months after go-live, with a new vendor to argue with.

The honest test: list the five operational failures that made you start looking, and name the specific system capability or process change each one needs. If your list is mostly capabilities the current system genuinely lacks — goods-to-person automation, serial capture for compliance, multi-site inventory visibility — it is a replacement. If it is mostly "the system could do this if it were set up right," it is not.

The cutover decision shapes everything else

Big-bang over a quiet weekend, or phased by site, aisle or flow? Both work; they fail differently. A big bang concentrates the risk into one night and one hypercare period, which suits operations with strong daily volume flexibility and a team that can be pulled off the floor for weeks. A phased cutover spreads the pain but forces you to run two systems, two sets of inventory logic and two training programs at once, sometimes for months — the hidden cost is the bridging work, not the cutovers themselves. The practitioners who regret their choice usually picked it from a project plan rather than from their own peak-season calendar.

Whatever the choice, the one lesson that shows up every time: do not schedule your final cutover into your peak window, and do not let a software-licence renewal date or a project-funding deadline pick the date instead.

Data readiness is the project

Ask anyone who has lived through one and they will tell you the warehouse management system was the easy part. Location master data, item dimensions and handling rules, carton and pallet build logic, open-order and in-transit inventory — the migration and cleansing of this data is where the schedule actually goes. The lessons that repeat: start the data work months before vendor selection finishes, decide early which legacy history truly needs to carry over (usually far less than the business initially claims), and rehearse the migration end to end more than once, on production-like data, with the operations team watching real transactions move.

The labor ramp is a production problem, not a training problem

Throughput always dips after go-live. Temporary workers, agency staff and night shifts learn a new system at different speeds, and a pick rate that looks fine with your core team can collapse on a Monday with 40% agency labor. The practitioners who handled this well treated the productivity ramp as a planning problem: they pre-built volume headroom into the go-live weeks, ran super-user coverage on every shift, and negotiated explicit productivity expectations with their own leadership before the date, not during the dip.

Three questions worth asking someone who has done it

1. What did you get wrong in the first sixty days after go-live, and what did you change as a result?
2. Which interfaces and automation did you underestimate — and what would you scope differently now?
3. Knowing what you know, what would you have cut from the project to get live sooner, and what would you have refused to cut?

A consultant answers these from a methodology. A peer at your scale answers them from last year, with names, dates and numbers they are willing to share off the record. That difference is the entire product.