Shouldn't our implementation partner do the health check?

They should be involved, because they know the configuration. But they built it, and some findings will land on their work. An independent check of the data, with the evidence attached, gives you something concrete to take to them rather than a support ticket describing a feeling.

Is a WMS health check a performance or infrastructure review?

Not in the sense used here. Server response times, RF coverage and database tuning are real concerns, and your vendor or IT team is better placed to review them. This health check is about whether the records are right and whether the system enforces the controls that keep them right.

How long after go-live should we wait?

Long enough for a full cycle of receipts, counts and period-end: usually the first 60 to 90 days. Earlier than that, stabilization noise hides real defects. Much later, and the defects have had months to compound and a year of adjustments has buried the evidence.

Service guide · After go-live

WMS health check:
auditing the system after go-live

A new WMS usually goes live with the old system's data and a set of configuration defaults nobody chose on purpose. When accuracy dips afterwards, the cause is rarely the software. It's what was loaded into it, and what it was left permitted to do.

Updated 17 September 2026
Written by WMSAudit
A Ravenspire LLC company
9 min read

Short answer

A WMS health check is a post-implementation audit of whether the system is holding accurate data and enforcing the rules it was bought to enforce. It tests five layers in order: migrated master data, opening balances, configuration switches, transaction behavior and interfaces. Most accuracy problems after a go-live trace to the first three, and they can be found from exports without the implementation partner.

What a WMS health check is, and isn't

A WMS health check asks two questions of a system that's already live. Is the data it holds true? And does it enforce the rules that keep the data true? It isn't a software evaluation, a vendor comparison or an infrastructure review. It assumes you've chosen your system and you're keeping it.

It's the same work as a WMS audit, pointed at the specific failure modes of an implementation: data carried across from the old system, balances loaded at cutover, and a configuration that was set under deadline pressure and never revisited.

Why accuracy often dips after a go-live

Implementations are judged at go-live on whether orders ship. Data accuracy problems don't stop orders shipping in week one. They surface in week six as short picks, in month three as a count that won't reconcile, and in the first year-end as an adjustment nobody can explain. The usual mechanisms:

Master data migrated as-is: The old system's item master, pack fields included, loaded into a system that uses them differently. A field the old WMS ignored can drive every conversion in the new one.
Defaults filled in where the source was blank: Migration tools need a value. Blank case packs become 1, blank dimensions become zero or a placeholder, and blank control flags become "off".
Opening balances loaded in the wrong unit: Balances exported in one UOM and loaded as another. Every error starts at go-live, sized by a conversion factor.
Location mapping gaps: Old location codes translated to new ones by a mapping table. Unmapped codes land in a catch-all location, and duplicate mappings put two slots' stock in one.
Permissive configuration: Negative on-hand allowed, over-receipt tolerance wide open, keyed confirmation permitted: switched on to get through cutover and never switched back.
In-flight documents at cutover: POs part-received in the old system and received again in full in the new one. Transfers shipped from one system and never received in the other.
Workarounds that became process: Whatever users did to get through the first fortnight, such as manual receipts when ASNs failed or adjustments when a task wouldn't close, is often still happening a year later.

A worked example: the migration default

The legacy system stored case pack only for items bought in cases, and left it blank for the rest. The migration tool required a value and defaulted blanks to 1. For most of those items, that's harmless. For 60 items whose vendor had since moved to case shipping, the new WMS now receives each case as one unit.

60 items · case pack defaulted to 1 · first 90 days Illustrative arithmetic

Effect of a migration default on received quantities
Line	Value	Working
Actual pack (typical)	12 EA / CS	What the vendor ships
Cases received, 60 items, 90 days	1,800 CS	Averages 30 cases per item
Recorded	1,800 EA	1,800 × 1
Physically received	21,600 EA	1,800 × 12
Unrecorded stock	19,800 EA	Stock the system doesn't know it holds

Symptom on the flooroverflow and over-ordering· cause in the dataone default

Nothing in this failure looks like a data problem to the people living with it. Buyers see the system short and reorder. Receiving sees product with nowhere to go. Counts find large positive variances on a handful of items and get adjusted up, which makes the balance right until the next receipt. The health check finds it in one query: active items with a case pack of exactly 1, joined to receipts in case UOM.

The five layers, in the order to test them

Test from the bottom up. A defect in an early layer produces symptoms in every later one, so fixing symptoms in layer 4 while layer 1 is still wrong just recreates them.

Layer 01

Migrated master data

Item master: packs of exactly 1, zeros, placeholder dimensions, missing control flags, identifiers duplicated across levels. Location master: codes with no physical position, catch-all locations holding stock, capacity left at default. The item master audit covers twelve tests in detail.

Layer 02

Opening balances

Reconcile the cutover load against the legacy system's final balances, by item and location, in base units. Differences that are a clean conversion factor are UOM load errors. Stock sitting in a catch-all location is a mapping gap. Both are dated to go-live, which makes them easy to separate from later errors.

Layer 03

Configuration switches

List every setting that governs what the system permits: negative on-hand, over- and under-receipt tolerance, keyed versus scanned confirmation, partial task confirmation, count visibility (blind or not), adjustment approval thresholds, required reason codes. For each, record the current value, who set it, and whether it was meant to be temporary.

Layer 04

Transaction behavior

Does the process follow the configuration? Keyed confirmation rates by user, duplicate receipts, moves with one leg, adjustments clustered on a few items. This is where post-go-live workarounds show up. The root cause matrix maps the signatures.

Layer 05

Interfaces

New integrations fail in new ways. Check the error queue for messages never reprocessed, WMS against ERP by item, and in-flight documents from cutover still open in either system. Inventory reconciliation covers separating timing from real gaps.

When to run it

60 to 90 days after go-live. After a full cycle of receipts, counts and a period-end, and before defects have compounded for a year.
After any major upgrade or re-configuration, especially one that touches UOM handling, receiving or task confirmation.
When accuracy hasn't returned to pre-go-live levels and the explanation is still "stabilization" after the first quarter.
Before signing off the implementation, if your contract has an acceptance milestone. Findings are much easier to resolve while the project team is still engaged.

Yours, or the vendor's?

Every health check finding should say who can fix it, because post-go-live defects split three ways and each has a different path to closure.

Yours to fix: Master data values, location records, configuration settings you control, and process discipline. Most findings land here, and most can be fixed without a change request.
Your implementation partner's: Migration mappings, load scripts, configuration they set up and documented as final, and interface mappings built during the project. Bring the evidence: the items, the dates, the rule.
The software vendor's: Behavior that contradicts the documentation, such as a restatement rule that doesn't do what it says or a task that can close with one leg posted. These need a reproducible case, which the transaction evidence gives you.

The operational takeaway

After a go-live, "the new system is wrong" is almost never the finding. The finding is a specific default, mapping or switch, dated to cutover and affecting a specific list of items. That's good news, because a dated, bounded defect can be fixed and its damage reversed, which a general loss of confidence can't.

Start with layer 1. If the item master and location master are clean, the rest of the health check goes quickly. If they aren't, nothing downstream will stay fixed until they are.

Questions

Shouldn't our implementation partner do the health check?: They should be involved, because they know the configuration. But they built it, and some findings will land on their work. An independent check of the data, with the evidence attached, gives you something concrete to take to them rather than a support ticket describing a feeling.
Is a WMS health check a performance or infrastructure review?: Not in the sense used here. Server response times, RF coverage and database tuning are real concerns, and your vendor or IT team is better placed to review them. This health check is about whether the records are right and whether the system enforces the controls that keep them right.
How long after go-live should we wait?: Long enough for a full cycle of receipts, counts and period-end: usually the first 60 to 90 days. Earlier than that, stabilization noise hides real defects. Much later, and the defects have had months to compound and a year of adjustments has buried the evidence.