Here is what nobody tells you about WMS go-lives: the software is rarely the problem. The first week is.
I have watched go-lives where the system passed every test, every interface returned green, and the cutover plan was 40 pages long — and by 9 a.m. on day one the floor was on fire anyway. New processes, new location codes, new devices, all landing on the same morning, with people who learned the new flow in a two-hour training session three weeks ago. The war room is the only thing standing between that chaos and a missed carrier cutoff. But most war rooms I have seen are just a few people sitting around answering phones. The fire burns anyway, because nobody decided in advance what the first week would actually look like.
The three fires you will fight, guaranteed
The first fire is master data. Barcodes that won't scan, location codes that don't match, unit-of-measure conversions that are wrong. In 2023 I supported a go-live at a 120,000-square-foot 3PL warehouse in Ontario, California. To hit the deadline, the team deferred loading barcodes for 200-plus slow-moving SKUs to "after go-live." Every morning of week one, a dozen wave orders jammed at the audit station because there was no barcode to scan, and auditors had to dig through cartons by hand. Zero technical difficulty, pure incomplete prep work — and the most grinding fire of the week. It never kills you, it just burns every single day.
The second fire is interfaces. WMS to OMS, to carriers, to EDI — something will misbehave in week one. Orders don't come down, status updates get lost, a wave release dies halfway. The nasty part is that the floor can't see this kind of problem: pickers just know "there are no orders to pick." If the war room isn't watching the interface queues, you find out two hours later when the backlog is already in the thousands. And here's the kicker — it's often not the WMS's fault at all. The other side changed a field and forgot to tell you. So the war room needs someone who can read logs and get the other party's engineer on the phone in one call.
The third fire is people. The new flow feels awkward, so workers quietly route around the system: pick on paper first, key it in later; skip the RF gun because handwriting is faster. If you don't kill these shadow processes in week one, you never will. Once the data goes dirty, inventory accuracy never recovers. Of the projects I've seen still reconciling inventory three months after go-live, nine out of ten buried the problem in week one. My war room rule: the first time someone bypasses the system, it's a conversation that day. The second time, it goes straight to the warehouse manager. Sounds harsh. It's the only way to protect the data.
Who sits in the war room matters more than where it is
The setup that works best is one or two people from each of three sides. Operations sends a warehouse supervisor — someone who knows the process and can make calls like "this order can ship manually." IT sends the interface and infrastructure person — someone who can read logs and restart a service without filing a ticket. The implementer sends a consultant who knows the configuration — someone who can fix a bad parameter on the spot. All three are non-negotiable. Without operations, issues can't be triaged. Without IT, interface problems get blank stares. Without the implementer, one config item can stall you for half a day.
Run two shifts, not three. The early shift covers wave release through the evening peak; the late shift covers night closeout, with a two-hour overlap for handoff. Lock the schedule three days before go-live, print it, put it on the wall. If someone needs time off, they find their own replacement. "Phone support" doesn't count. In week one, a person in the room and a person on the phone are two completely different levels of firepower.
Most important: name one decision-maker, usually the business-side project manager. The war room's deadliest disease is three people and no decision. When a P1 hits, the decision-maker says one sentence — stop the line and fix it, or route around it and protect shipping. That person must have the authority to halt shipments and the authority to say "we go manual for two hours." A war room with fuzzy authority will debate for two hours what a clear decision-maker resolves in one sentence.
Six numbers on the dashboard. No more.
A week-one dashboard should be lean. I watch six numbers: unreleased order backlog, wave release success rate, RF devices online, interface queue depth and longest wait time, audit exception rate, and same-day on-time shipment rate. Each gets a red line — for example, an interface queue over 200 orders with no movement for 15 minutes auto-escalates to P1, no report needed. The three sides agree on the red lines before go-live, write them on paper, stick them on the wall, and don't touch them for the whole week. A red line that changes daily is no red line.
P1/P2/P3 severity levels need to exist from day one, and the definitions must be plain and concrete. P1: we can't ship, or the data will go bad. P2: throughput drops by more than half, but we can still ship. P3: usability issues that don't affect shipping. A war room without clear severity has everything "kind of urgent," which means nothing gets prioritized. One more iron rule: from the moment a P1 is spotted to the moment someone owns it, no more than 15 minutes. If it times out, the decision-maker's phone rings directly.
A rollback plan isn't an embarrassment. It's insurance.
Two things must be ready before go-live. First, paper backup order forms and a manual process. If the system truly goes down, the warehouse doesn't stop: pick on paper, record by hand, key it in later. Print the forms in advance and keep them on the floor — don't go hunting for a printer when things are already broken. And rehearse the manual flow at least once. Shift leads should walk the full paper process with their own hands, or on the bad day, they won't know how to use the paper they're holding.
Second, data restore points. A full backup every night, plus a separate backup before any major master-data change. Rollback doesn't mean uninstalling the system — it means "today's config change broke something, and we can get back to last night's state." Honestly, few projects actually use the rollback plan in week one. But having one changes the team's psychology completely. A team with a plan will touch the configuration. A team without one won't change a single parameter, and a P2 problem drags on until it becomes a P1.
So: before go-live week, print the P1/P2/P3 definitions and the escalation phone list, stick them on the war room wall, and put a stack of paper backup forms next to them. On the last day of week one, hold a retro with three questions: which fire burned hottest, which metric alarmed first, and which manual workaround should become a permanent system process. Then disband the war room — keeping it open means you don't trust the system yet.
One last question for you. If you had to shut down the old system yourself on the morning of day one — would you dare? If not, your rollback plan isn't ready. Fix that now, while there's still time.
