WMS Implementation: What Needs to Happen Before Go-Live?

The problems that surface when a new Warehouse Management System (WMS) goes live are often visible weeks earlier: in a location file with missing check digits, an interface tested only with clean data, or a training plan that assumed people would learn on the job. Go-live succeeds or struggles on the preparation behind it.

This guide assumes the product has been chosen. If you are still selecting, start with how to choose the right WMS.

Map the future process in detail

Selection-stage process maps are usually too high-level to configure a system from. Before building anything, agree how each process will run in the new system, screen by screen and scan by scan: receiving, putaway, replenishment, picking, packing, shipping, cycle counting and returns.

Each map should name the decision the system makes, the decision the operator makes and what happens when something goes wrong. Have the supervisors who will run the shift sign off on them, not only the project team.

Prepare master data

Master data is the reference information the WMS relies on for every task. Errors here appear on the floor as wrong suggestions, failed scans and stock that the system believes cannot fit in a location.

• Items: every active SKU (stock keeping unit), with lot, serial and expiry attributes where they apply.
• Units of measure (UoM): each, inner, case and pallet, with correct conversion quantities between them.
• Dimensions and weights for each UoM, which drive putaway, cartonization and load planning.
• Locations: a complete, consistent naming scheme, with type, capacity and pick sequence for each location.
• Barcodes: item barcodes at each packaging level, and labels for locations and handling units. Where trading partners use GS1 standards, a GTIN (Global Trade Item Number) identifies a trade item and an SSCC (Serial Shipping Container Code) identifies a logistic unit such as a pallet.

Assign an owner to each data set, usually someone in the business rather than IT, and measure completeness before testing starts. Physically check a sample of dimensions and barcodes against the goods.

Configure and integrate

Configuration turns the process maps into system rules: allocation, putaway strategies, replenishment triggers, wave or batch release, label formats and user roles. Keep a log of every setting and the reason for it. That log becomes the reference when something behaves unexpectedly after go-live.

Integrations typically include the ERP (Enterprise Resource Planning) system, carrier systems, EDI (Electronic Data Interchange) links with customers or suppliers, and any automation equipment. For each interface, agree the message format, the trigger, the expected response and the behavior when a message is late, duplicated or rejected. The WMS, WCS and WES article explains where those boundaries usually sit when automation is involved.

Test in layers

UAT should use real data and be run by the people who will operate the system, using the actual scanners, printers and network in the building. Volume testing should reflect your peak, not an average day, and include the slowest interface in the chain.

Test the exceptions, not only the happy path

Clean scenarios usually pass. The disruptions on go-live day tend to come from situations nobody scripted. Include in every test cycle:

• Short picks, empty locations and stock found in the wrong place.
• Damaged goods, over-receipts and receipts without an advance notice.
• Orders amended or cancelled after release to the floor.
• A label printer, scanner or wireless access point going offline.
• An ERP or automation interface that stops responding, and the recovery afterward.

Train for the floor

Train by role, in the building, on the devices people will use. Short sessions close to go-live tend to stick better than long ones months ahead. Identify super users on each shift who know the system well enough to help colleagues and to recognize a real defect.

Supervisors need extra time on the screens that show work queues, exceptions and inventory adjustments, because they will be making the decisions during the first weeks.

Plan the cutover, including the way back

Cutover is the period in which the operation stops working in the old system and starts in the new one. Write it as an hour-by-hour plan with named owners. It usually covers:

• Reducing activity before the switch: closing open receipts, completing or holding open orders.
• Extracting stock from the old system and running an opening-stock count, full or of an agreed high-risk sample, so that the WMS starts with inventory that matches the shelves.
• Loading and reconciling migrated balances by item, lot and location against the count.
• Switching interfaces, then running controlled first transactions before full release.

Set go/no-go decision points in advance, with the criteria for each and the person who decides. Define the rollback or fallback option for each point: what the operation will do, and how long it can run that way, if the go-live must stop. A fallback that exists only as an intention is not a fallback.

Go-live readiness checklist

• Future-state process maps signed off by the shift supervisors who will use them.
• Item, UoM, dimension, location and barcode data complete, with a physical sample verified.
• Every location and handling-unit label printed, applied and scan-tested.
• All configuration logged, with a frozen build for go-live.
• Each interface tested end to end, including late, duplicate and rejected messages.
• UAT completed and signed off, with remaining defects listed and accepted by the business.
• Volume test passed at expected peak load.
• Devices, printers and wireless coverage tested in every working area.
• All users trained by role, and super users named on every shift.
• Cutover plan with owners, timings, go/no-go points and fallback actions.
• Opening-stock count method agreed and reconciliation process ready.
• Hypercare team, support contacts, escalation routes and exit criteria agreed.

Stabilize through hypercare

Hypercare is a period of heightened support immediately after go-live, often lasting a few weeks, with the implementation team, key users and IT available on site or on call. Its purpose is to resolve problems quickly while people are still learning the system.

Track a small set of measures daily: open issues by severity, inventory accuracy, order throughput against plan, interface errors and manual workarounds in use. Agree exit criteria beforehand, so that the move to normal support is based on evidence rather than the calendar. If an outside team will later run the site, as in managed operations, involve it during hypercare rather than after.