Let me give you the verdict first: the biggest risk in a WES implementation isn't the software. It's going live with wave rules nobody ever truly signed off on.
Your vendor can integrate your systems and stress-test the servers. But the question of how one order becomes a set of pick tasks? Only your team can answer that. If nobody will sign their name to the answer, a WES implementation is a gamble, not a project.
I've watched too many projects die on this sentence: "We'll go live with the wave strategy as-is and fine-tune later." Put bluntly, that's building on quicksand. It looks fast until you try to live in it.
Here's one I lived through. 2022, a 3PL warehouse in the Inland Empire, about 120,000 square feet, shipping around 12,000 orders a day — a mix of e-commerce parcels and wholesale for a few small brands. During blueprint we locked the wave rules: cut waves by order cutoff time, each wave covering 90 minutes of orders, key accounts in their own waves. Three rounds of testing, and task orchestration, pick paths, and sort destinations all lined up. The implementation team thought this one was in the bag.
Three days before cutover, the VP of Operations decided to re-cut waves by carrier — UPS orders in one wave, FedEx in another — because it would make trailer close times easier to hit. One sentence, three months of strategy in the trash. The team reconfigured the rules overnight. Retest? No time. Straight to go-live.
Cutover day, 10 a.m. The first wave dropped, and the WES sent nearly every picker into the same aisle. Re-cut by carrier, the orders' location distribution had completely changed, and every density assumption in the task engine was wrong. Pickers queued in the aisle waiting for tasks. The sorter ran empty for almost two hours. Not a single afternoon cutoff was met. That night we rolled back to the blueprint wave rules, and the system didn't stabilize until the next morning. One round trip burned an entire day of throughput — customer late penalties on top.
Two sides to this. The technical side: change the wave rules and the WES has to recompute task orchestration, labor allocation, and equipment pacing — everything moves at once, and there is no such thing as "just a small change." The management side: why could the rules still change three days before cutover? Because nobody dared sign off during blueprint; the VP kept saying "let me think about it." After all these years in implementation, I've learned that technical problems always have workarounds. Problems nobody will decide on are the ones that kill you.
So here's the checklist I hand every warehouse about to implement a WES. Eight gates, one acceptance line each. If you can't clear the line, don't move on — moving on means betting peak season on hope.
WES Implementation Gate One: Freeze the Blueprint, Sign Every Change
The single most dangerous moment in the whole project is the night before go-live, when someone with authority decides the wave rules need "one small tweak." Freeze the blueprint: wave strategy, task priorities, and exception flows, all signed and sealed. After the freeze, every change goes through a formal change order. Verbal requests don't count. Whoever wants a change signs their name to it — that one rule alone filters out ninety percent of last-minute ideas.
The 8-Gate WES Go-Live Acceptance Checklist
| # | Gate | What "done" looks like |
|---|---|---|
| 1 | Blueprint freeze | Wave strategy, task priorities, and exception flows signed off; any post-freeze change requires a formal change order |
| 2 | Master data readiness | SKU masters, location codes, and pack specs loaded; spot-check physical locations against the system, zero missing master records |
| 3 | Integration testing | WMS, sorter, pick-to-light, and printers all talking; run a network-drop drill and an equipment-down drill — no lost or duplicated messages |
| 4 | Wave and task configuration | Rules configured per blueprint; replay at least three rounds of real historical orders and hand-check the task assignments |
| 5 | Stress testing | Test at peak-season volume, not average volume; task dispatch stays responsive and nothing crashes at peak |
| 6 | Parallel run | New and old systems run side by side; order-by-order reconciliation, three straight days with zero variance before you talk cutover |
| 7 | Cutover window | Pick the lowest-volume shift; staff double crew on cutover shift and keep the old system hot and ready to roll back |
| 8 | Hypercare | Two to four weeks post go-live; core team on-site, issues triaged by severity, critical issues get a decision-maker within two hours |
Two gates deserve extra attention. The parallel run is where most teams cheat — they run it for a day, eyeball a few orders, and call it good. Three straight days of zero variance is the line. It sounds slow; it's cheaper than one rollback. And hypercare is not "the vendor's support hotline." It's your own core team, physically in the building, with the authority to make calls. A hotline can't decide whether to re-cut a wave at 2 a.m. Your shift lead can — if you gave them that authority in writing before go-live.
Big Bang or Warehouse-by-Warehouse? Two Sides to It
Here's the trade-off nobody wants to talk about. A big-bang cutover concentrates the risk: if it fails, the whole building stops. The payoff is that the pain is short — the team focuses once, and you don't maintain two sets of process logic in parallel. It fits a single building with manageable daily volume and straightforward operations.
A phased, warehouse-by-warehouse cutover spreads the risk: one building's failure doesn't touch the others, and the lessons from building one transfer directly to building two. The cost is a longer timeline, doubled management overhead during the overlap, and special logic for inter-warehouse transfers. It fits multi-site networks, or a single site whose volume is so large that one stopped day breaks bones.
My call: one building, cut once, don't drag it out. Multiple buildings, cut them one at a time, don't get greedy. The worst pattern is "phased in name, but every building chasing the same deadline" — you pay both costs and collect neither benefit.
One contrarian take before I close: most people think the biggest risk in a WES go-live is software bugs. Put bluntly, bugs always have workarounds. What kills projects is going live with wave rules nobody truly decided on. With the rules settled, even a mediocre system runs fine. Without them, the prettiest configuration is just guessing.
So stop asking me which WES vendor to pick. Ask yourselves this first: is there anyone willing to sign the wave-rules document? If not, the vendor doesn't matter.
By Lao Mi, Supply Chain Veteran (20 yrs)
