When should the migration data be checked?

Twice: on the extract you're about to load, about four weeks before cutover so there's time to fix fields, and again 60 to 90 days after go-live, once a full cycle of receipts, counts and a period-end has run.

Isn't this the implementation partner's job?

They own the load and the configuration. The data they load is yours, and so is its quality: most partners migrate what they're given. An independent check gives you a list to hand them, with evidence attached.

Checklist · Before and after cutover

WMS data migration checklist:
what to check before and after cutover

Accuracy usually drops after a WMS go-live, and the software is rarely why. It's the data carried over and the settings left permissive. These are the checks that catch both, grouped by where the damage starts.

Updated 19 September 2026
Written by WMSAudit
A Ravenspire LLC company
30 checks · 8 min read

Short answer

A WMS data migration checklist tests what you load and what the new system is allowed to do. The item master needs no default-filled packs and conversions that reconcile. Locations need a complete mapping. Opening balances should be reconciled in base units, and switches like negative on-hand and keyed confirmation deliberately set. POs that straddle cutover must not be received twice.

01 Item master

The fields every transaction converts through. Migrate a wrong one and the new system reproduces the old error at full speed.

No default-filled packs: List active items whose case pack, inner pack, TI or HI will load as 0, 1 or blank. Migration tools need a value, and 1 is the usual default. Every item on that list that arrives in cases will post one unit per case in the new system.
Conversions reconcile: For each item, inner × inners-per-case = case, and case × TI × HI = pallet. Items that don't reconcile in the source file won't in the target either.
Pack checked against receipts, not the old master: Run the receipt-ratio test on 90 days of receipts before cutover: a constant per-case variance means the field you're about to migrate is already wrong. Free check.
Identifiers per packaging level: The same GTIN or UPC on the each and the case means a case scan records one each. Split them before load.
Dimensions and weights at the level the new WMS uses: New systems often cartonize and slot from dims the old one ignored. Each-level dims copied into the case record make every case look the size of one unit.
Control flags mapped, not dropped: Lot, expiry, serial, catch-weight, hazard and temperature flags have target fields and values for every item that needs them.
Inactive items decided: Decide explicitly whether inactive items migrate, and what happens to any stock they still hold.

02 Location master

Every balance points at a location. A mapping gap turns real stock into stock nobody can find.

Mapping table is complete: Every legacy location code maps to exactly one new code. List unmapped codes holding stock: a catch-all "MIGRATION" location is a finding, not a solution.
No two old codes map to one new slot: Unless that's intended. Duplicates put two slots' stock in one and create variances on day one.
Types and capacities set deliberately: Pick, reserve, staging, QA and returns types are correct, and capacity fields reflect what fits, not a default that directed putaway will trust.
Labels match the new codes: Check digits printed, re-labeled aisles scanned end to end before go-live, and old labels removed.
Pick-face assignments current: Assignments reflect current velocity, not the slotting plan from when the old system was implemented.

03 Opening balances

The one day every error is dated to. Reconcile before anyone picks.

Loaded in base units, reconciled in base units: Export legacy on-hand, convert to base units yourself, and compare item by item and location by location with what loaded. A difference that equals a conversion factor is a UOM load error.
Count or freeze strategy agreed: Either a wall-to-wall count at cutover or a documented freeze window with reconciliation. "We'll fix it with cycle counts" means counting against a moving target for months.
Status carried correctly: Damaged, QA, hold and RTV stock loads with its status, not as available.
LPN and lot integrity: Lot-controlled stock loads with its lot and expiry, and LPN contents match the physical pallet.

04 Configuration switches

What the new system permits decides whether data stays clean after day one. List every switch with its value, who set it, and whether it's meant to be temporary.

Negative on-hand: Blocked, or reviewed daily. Allowed during go-live week is common; allowed forever is how phantom stock hides.
Receipt tolerance: Over- and under-receipt tolerance is set per vendor or category, not wide open.
Scan enforcement: Location scan is required at putaway and pick confirmation. Keyed confirmation is the most common post-go-live location error.
Partial task confirmation: Moves and replenishment can't close with only one leg posted.
Blind counts and count-time snapshot: Counters can't see the expected quantity, and the system quantity is captured when counting starts, not when the count posts.
Adjustment controls: Specific reason codes are required, approval applies above a value threshold, and adjustment rights are limited to inventory control.

05 In-flight documents and interfaces

Transactions that straddle cutover are how the same receipt gets counted twice.

Part-received POs: Every PO line received in the old system carries its received quantity into the new one, so it isn't received again in full.
Open transfers and returns: Transfers shipped but not received, and returns in process, are listed and closed or re-created deliberately.
UOM translation at the interface: The ERP and WMS agree on the unit for each message type. A PO in cases received in eaches is a factor error at the border.
Error queue owner: Someone named reviews failed and stuck messages daily from day one.

06 After go-live: day 1, week 1, day 30, day 90

The checks that catch what slipped through, while it's still cheap to fix.

Day 1: Duplicate receipts (same PO line, same quantity, within 24 hours); negative balances; stock in the catch-all location.
Week 1: Keyed versus scanned confirmations by user; tasks closed with one leg; the first emergency replenishments and why.
Day 30: The receipt-ratio test on the first month's receipts; adjustment reason-code distribution; WMS versus ERP by item.
Day 90: A full WMS health check: migrated data, balances, configuration, transactions and interfaces, before a year of adjustments buries the evidence.

The operational takeaway

A new WMS doesn't clean your data; it enforces whatever you load, faster. The cheapest time to fix a case pack, a location mapping or a permissive setting is before cutover. The second cheapest is the first 90 days, while every error is still dated to go-live.

If you're pre-cutover, start with the item master section and the free case-pack check. If you're already live, the WMS health check covers the same ground from the other side.

Questions

When should the migration data be checked?: Twice: on the extract you're about to load, about four weeks before cutover so there's time to fix fields, and again 60 to 90 days after go-live, once a full cycle of receipts, counts and a period-end has run.
Isn't this the implementation partner's job?: They own the load and the configuration. The data they load is yours, and so is its quality: most partners migrate what they're given. An independent check gives you a list to hand them, with evidence attached.