A failed warehouse go-live can cost a global supply chain months of disruption and millions in stabilization work. However, almost all of it is traceable to the same five preventable gaps in design, testing, training, cutover planning, and hypercare.

After years of implementing warehouse management systems, I still remember one morning after a go-live. I was on the floor, and saw everything gradually grind to a halt: trucks waiting, scanners didn’t match the system data, and boxes were piling up in the shipping zone with nowhere to go.

Not because the software was bad, but because the preparation wasn't good enough.

I've since been part of dozens of warehouse system implementations – including a post-go-live stabilization project for an international life sciences company operating distribution centers across multiple countries, where a team of 50+ consultants spent months untangling a go-live that didn’t go as planned. That experience, more than any other, sharpened my thinking about what actually makes these projects succeed or fail.

The recommendations below apply to any warehouse management system implementation. I'll use SAP Extended Warehouse Management (SAP EWM) as my primary example, since that's where I spend most of my time – but the underlying principles are the same whether you're rolling out SAP EWM, Blue Yonder, Manhattan Associates, or any other WMS platform.

Why warehouse implementations are uniquely high-stakes

When a warehouse management system go-live fails, the disruption rarely stays inside four walls. In fact, even a 15-minute delay can cost you a shipping window, a customs deadline, and, eventually, a customer relationship that took years to build.  For larger companies that operate across borders, the consequences of even a short, unplanned delay can already be severe. Imagine the impact of a botched WMS cutover!

The five phases where things go wrong – and what to do instead

1. Solution design: map the exceptions, not just the happy path

Every implementation starts with process design. And almost every team spends too much time designing the happy path – what happens when everything goes right – and not enough time on exceptions.

But real warehouses are messy with goods arriving damaged, deliveries coming on the wrong pallet type, customers changing their orders after picking has already started, etc. If the company operates internationally, add customs holds, country-specific labeling requirements, or carrier-specific handling rules.

When implementing warehouse management software, you have to consider all potential issues – for example, through process diagrams. The diagram  maps how flows should work – and when you have that flow, go back through every decision point, asking what could possibly go wrong. The best way is to engage  business users in building  those diagrams – in my practise, every single time, they'll point out something I hadn't thought of.

The other lesson I've learned: resist the urge to put everything in the system. Sometimes, a clear operational procedure is better than clever configuration. Take, for example, issues with damaged goods: you can build an elaborate rerouting workflow for every unique case, or you can create a "damaged goods" zone and let the warehouse team manually handle it from there. Simpler systems break less often, and when they do, they're easier to fix.

2. Testing: the phase most often cut short

If there's one thing I'd tell every project sponsor, it's this: don't cut the testing phase.

In the botched go-live project I mentioned above, around 30% of the functionality hadn't been fully tested before go-live. That 30% caused a disproportionate share of the post-launch problems – months of stabilization work, on-site consultants across multiple countries, hundreds of blocked handling units to manually clear. All of it traceable back to compressed testing.

A thorough testing cycle for a complex warehouse system takes two to three months. That includes the implementation team's own testing, followed by training, followed by UAT (User Acceptance Testing). Each phase builds on the previous one.

UAT alone typically takes four to six weeks – and it's demanding. Plan for business users to dedicate 30–50% of their working time to it, or roughly 12–20 hours a week.

Who should be in the room for testing:

You don't need every warehouse worker involved; you only need a focused group: process leads who own each area, line supervisors who know the floor, and a handful of operationally sharp end users. Enough to cover real scenarios – including the ones that go wrong.

When writing test scripts, ensure you include exceptions and negative scenarios. Otherwise, testers might simply not find them –but then, on the go-live day, you'll face those issues.

3. User training: practical beats theoretical, every time

I've seen the same pattern repeatedly: training gets squeezed into one session close to go-live, people sit through a demo, and everyone walks out feeling reasonably confident. Then a small mismatch after go-live can paralyze the whole system.

Real case example: in one implementation, storage locations were set up using hyphens (01-01-01), but physical bin labels were printed with underscores (01_01_01). UAT covered only the system side, so everything looked fine. After go-live, warehouse staff couldn't put goods away or pick them up because the scanned barcodes didn't match any records in the system: a classic gap between what's tested on screen and what exists in the real world.

Warehouse workers learn by doing – so while training, they need to go through all those negative scenarios. Who do you call when a task can't be completed? What's the process when a delivery is wrong? These are basic questions that should have clear answers before day one.

The other thing teams consistently underestimate: warehouse users are busy. If participation in training isn't protected time – formally scheduled and prioritized – it gets squeezed out. No wonder go-live gets rocky!

And don’t underestimate people’s resistance. It’s completely normal when you ask them to move from a system they already know to something new. If that’s what you’re dealing with, don’t push. Instead, explain to them the real benefits of that new system: not the abstract "this is more efficient", but "the task that currently takes you four steps will take only two." That tends to land.

4. Cutover planning: sequence is everything

The cutover – the actual switch from the old system to the new – is its own project within the project. It needs a detailed, sequenced plan with time estimates for every step.

Why does sequence matter? Because warehouse systems have hard dependencies. In SAP EWM, for example, you can't set up bin sorting until the warehouse structure is loaded. Get the order wrong, and you block yourself – while doing this overnight, under time pressure, with carrier pickups scheduled for the next morning.

And remember that business users must also plan and execute their part of the work: close open deliveries, clear the goods receipt area, confirm or cancel pending shipments, run an inventory count, and, finally,  verify that the stock in the WMS matches the ERP. These tasks must be included in the cutover plan, along with the technical steps.

Cutover checklist:

Note: The sequence is important because each step depends on the others. Document time estimates for every item.

5. Hypercare: go-live is the beginning, not the end

Don’t think of a go-live as the finish line. It's the start of hypercare – a period of intensive support while operations and the system settle in together.

During this phase, issues will surface. The important skill is categorizing them correctly, because the right response depends on the category:

• System bug or configuration gap – fix it
• User error or training gap – retrain, clarify responsibilities
• Out-of-scope scenario – treat it as a change request (i.e., a separate project with its own timeline and budget) and offer a workaround in the meantime

Without such categorization, post-go-live issues can turn into an endless argument over whose fault it was and who is paying the bill. At the end of the day, it can damage even a perfect relationship between client and implementation partner.

Larger operations are usually better off with someone in-house who simply knows the WMS cold – doesn't have to be a developer, doesn't have to carry an IT title, just someone who can triage an issue, ask the right question, and keep it from getting lost between the warehouse floor and the implementation partner.

The real cost of cutting corners

The life sciences company's botched project was fixable. At the end of the day, the team stabilized operations, cleared the backlog, identified root causes, and retrained users. By the end of the stabilization phase, the warehouse was running well. On the other hand, it took weeks of work, dozens of consultants, and a disruption to an international distribution hub.

And the worst part is all of it could be prevented with proper testing, practical training, and a realistic cutover plan.

For companies operating globally, the calculus is straightforward: the most expensive part of a WMS implementation is often the part that wasn't planned.

Artem Latyshev leads the SAP EWM practice at ACBaltica, an SAP Platinum Partner with 25+ years of experience in warehouse management implementations across Europe and the United States.

Artem Latyshev leads the SAP Extended Warehouse Management (EWM) practice at ACBaltica, an SAP Platinum Partner with more than 20 years of experience delivering SAP solutions across Europe and the US. He has worked on dozens of warehouse management implementations, including post-go-live stabilization projects for global manufacturers and life sciences companies, with a focus on practical, business-first approaches to enterprise rollouts.