A cutover weekend had been planned for months. A twenty-year-old WMS was to be replaced, the full inventory was organised, the teams were ready. The day before, a critical module did not work in the migration scenario. The business teams decided to postpone. This lessons-learned article tells the story of that NO GO, then draws a method from it: the go/no-go criteria for an industrial IT project, the checklist to go through before any cutover, who should decide, and how to announce a postponement without damaging trust.
Because this is the hardest decision in project management: after months of effort, with senior management waiting and teams mobilised, saying “not now”. Yet it is often the right decision, and it can be prepared.
The background: a high-risk WMS migration
The WMS (Warehouse Management System) at this manufacturer had twenty years of service behind it and no recent maintenance, yet it remained at the centre of daily operations: receiving, locations, picking, shipping. Replacing it was not a change of tool; it was open-heart surgery, with four stakes:
- operational continuity: no interruption to logistics flows, as customers expect their orders on Monday;
- data integrity: twenty years of history on parcels, locations and pallets to preserve;
- team training on new processes and new screens;
- reliability: in an industrial environment, a failed shipment is noticed immediately.
The planned cutover
The deployment strategy was methodical, in three phases:
- Data migration. Extraction of the existing system's SQL tables and conversion to the new WMS's NoSQL database, with reconciliation of both sides.
- Full inventory. The moment of truth: exhaustive scanning of parcels, locations and pallets; detailed typology (bulk, single-customer, multiple statuses); three counts to detect discrepancies; closing with removal of ghost parcels and reassignment of locations. The tool developed for this stage is described in the case study on the inventory module.
- Validation tests. Picking and shipping under real conditions on the new system, before opening it up to the whole warehouse.
The spanner in the works: a shipping module that does not work
The day before the inventory, the team discovered that the shipping module did not work in the migration scenario. Without shipping, no cutover is possible: it is the flow that directly affects the customer. The discovery came late, and that lateness revealed the real problem.
With hindsight, the warning signs had been there for several weeks:
- incomplete testing of the critical modules, shipping first among them;
- a technical team without an overall view of how the flows fit together;
- insufficient communication between developers and business teams;
- time pressure that put the date ahead of quality.
Faced with these findings, the business teams took a unanimous decision: postpone the deployment. A NO GO, fully owned, on the eve of a weekend that had been prepared for months.
Go/no-go for an industrial IT project: the criteria to set before cutover
The main lesson is this: go/no-go criteria must be written down before the pressure builds. On the day itself, you no longer decide; you observe. Here is the grid we now use on our ERP and WMS projects:
| Criterion | GO | NO GO |
|---|---|---|
| Critical modules (receiving, picking, shipping, invoicing) | Tested end to end on real data, results signed off by the business | A module tested “partly” or only by the developers |
| Migrated data | Reconciled: same totals for stock, open orders and locations on both sides | Unexplained discrepancies, even “small” ones |
| Interfaces (ERP, labelling, carriers) | A complete flow run in testing, from purchase order to label | An interface never run under real conditions |
| Team readiness | Trained at their workstation, champions identified for each team | Training planned “after the cutover” |
| Rollback plan | Written, estimated in hours, tested at least once | “We'll see if things go wrong” |
| Cutover window | At least one day of margin before shipping resumes | Cutover squeezed into the last hour of the weekend |
| Support during cutover | Developers and software vendor reachable, on-site presence for the first days | Support “by email” when operations resume |
A single NO GO on a critical module is enough: a perfect data migration does not make up for a missing shipping module.
The checklist for the go/no-go meeting
- Hold the meeting at least a week before the cutover, not the day before.
- Go through each criterion in the grid, with the evidence: test reports, reconciliation figures, training attendance sheets.
- List the open issues and classify them: blocking, workaround available, cosmetic.
- Check that the fallback procedure is known to those who will have to carry it out.
- Take the decision, record it in writing, and name who announces it and to whom.
Who decides?
The business. The technical team informs, documents and raises alerts, but it is the logistics manager or the production manager who carries the operational risk; so it is they who say GO or NO GO, together with senior management. On this project, it was precisely because the decision was taken collectively, by the business teams and not by the developers alone, that it was accepted without argument.
How to announce a postponement
A badly announced postponement costs almost as much as a failed cutover. What works:
- State the facts, not who is to blame. “The shipping module does not pass the migration scenario; we are not cutting over until it has been validated.”
- Give the next steps at the same time as the postponement. What will be fixed, by whom, and the date of the next go/no-go meeting. A new cutover date is announced only once it is credible.
- Thank the teams who were mobilised and make clear that the preparation work is not lost: the inventory method and tools will be used for the next attempt.
- Notify customers or carriers only if the postponement changes something for them. A postponement that is invisible from the outside is a success.
What we see in real workshops
Cancelling a deployment is never a failure when it prevents an operational disaster with a direct impact on customers, rollback costs that spiral, a lasting loss of user trust and organisational stress that takes the company months to recover from. Projects that replace ageing systems often fail: AvenDATA puts the failure rate of legacy replacement projects at 75%. A deliberate postponement is rarely one of them; a poorly prepared GO often is.
Three lessons come back on all our projects. Technical skill is not enough: an excellent developer is not necessarily a good project manager, and the team needs an overall view of interdependencies, a feel for the business and someone able to anticipate blockages. Business leadership is essential so that the team does not get lost in technical details at the expense of the essential flows. Finally, an owned NO GO is better than a poorly prepared GO: the sentence is simple, but hard to apply on a Friday evening.
Courage, in an industrial IT project, does not always mean charging ahead. Sometimes it means saying “stop” when the conditions are not met, then coming back with a solid plan. That is the difference between a successful migration and an obstacle course with unpredictable consequences.
At Planitools, we run ERP projects with this discipline: go/no-go criteria written down from the scoping stage, end-to-end tests on critical flows, and a cutover validated by the business. We support SME manufacturers with Odoo implementation for manufacturing companies, and our past projects show how this works in practice. Preparing a cutover? Let's talk about your rollout plan.