Bottom line up front: when a WMS project slips, eight times out of ten it's not the software — it's the data. Go live on dirty data and you didn't buy a WMS, you bought an expensive ledger that records the wrong numbers.

I've seen this hole three times. Same script every time: the client says "our data is ready," day one the system says a slot has stock and it's empty, the system says a slot is empty and there are three pallets sitting in it. Everything stops for a full recount, go-live slips two weeks, and the boss loses it.

Why data migration is the #1 WMS killer

Simple: a WMS is an amplifier. In the Excel era, dirty data was survivable because humans papered over it — Lao Zhang remembered the pallet in zone A was damaged, don't touch it. After go-live, the system auto-assigns slots, auto-releases waves, auto-suggests replenishment. Dirty data gets amplified by the machine — faithfully, relentlessly — into production incidents.

Three dirty-data species to hunt:

Dead SKUs squatting in prime slots. Most warehouses have 10–20% of SKUs untouched for a year, still sitting in golden pick faces. Migrating them as-is imports the garbage-sorting workload into the new system too.

Book-to-physical gaps. The books say 100, the floor has 80, and the missing 20 is a three-year-old count variance nobody adjusted. "Everyone knew" in the old system. In the new system it's 20 ghost units triggering false replenishment and phantom stockouts.

Item masters missing fields. No length, width, height, or weight, and the WMS's slot recommendations, cartonization, and wave strategies are decorative. Worst I ever saw: 3,000 SKUs, under 400 with dimension data.

The playbook: three checklists

4–6 weeks before: scrub (the part that matters most)

Here's how each of the three dirty-data species gets cleaned in practice.

Dead SKUs. Don't just list them — walk the floor. I make the client physically visit the top 50 dead SKUs by cubic volume. Half the time, "dead" SKUs turn out to be mislabeled or stored under the wrong code, which is itself a data problem worth fixing. The genuinely dead ones get a disposition decision with a name and a date attached: "Zhang Wei, scrap by Nov 15." No owner, no date = it never happens.

Book-to-physical gaps. The trick is to reconcile in the old system, not during migration. Run a wall-to-wall or full cycle count 2–3 weeks before cutover, adjust everything, then freeze adjustments. Any variance discovered after the freeze gets a variance log with root cause — not a silent adjustment. Silent adjustments are how ghosts are born.

Item master gaps. Prioritize by cubic velocity: the 20% of SKUs that drive 80% of picks get dimensions first. For the long tail, a $200 dimensioning station (scale + measuring frame + barcode scanner) at receiving captures dimensions on the next inbound — no archaeology project needed. I tell clients: you don't need all 3,000 SKUs measured before go-live; you need the top 600 measured and a process that captures the rest within 90 days.

  1. Pull SKUs with zero movement in 12 months. Business decides: scrap, clearance, or move to low-cost storage. Target: zero dead SKUs in golden pick faces.
  2. Run a full cycle count and adjust every variance. No "we'll fix it later." I've seen this hole three times — every deferred variance became a P0 incident after go-live.
  3. Complete the item master: dimensions, weight, lot-tracking flags, expiry flags. Whatever can't be completed gets tagged "pending" and runs through a manual-confirmation workflow in the WMS as a stopgap.
  4. Freeze location master data one week out: codes, types, attributes. Any new location goes through change control.

Migration week: dual-track reconciliation

  1. Export from the old system, import to the new, then produce the same SKU-level balance report from both sides and reconcile line by line. Over 0.5% variance = stop. "Close enough" is not a standard.
  2. Physically verify 10% of locations, prioritizing high-value and variance SKUs.
  3. Run three days in parallel: old system keeps issuing orders, new system shadows them, compare pick accuracy.

First two weeks live: watch three metrics

  1. Daily: system-suggestion vs. manual-override rate. Overrides above 30% mean dirty data is still sabotaging you — go find it.
  2. Dead-SKU clearance progress: everything relocated during migration must be disposed within 60 days, or it quietly creeps back.
  3. "Pending" item-master burndown: 200 SKUs a week, zeroed within a month.

Go-live-eve checklist (memorize this)

  • Unadjusted historical count variances carried into the new system
  • Only SKUs with stock migrated; zero-stock legacy SKUs skipped, breaking old order references
  • Lot/expiry attributes that were free-text notes in the old system never structured — lot tracking dead on arrival
  • Location codes with inconsistent case/spacing creating "A-01-01" and "a-01-01" as two locations
  • Migration scheduled Friday night, nobody reachable all weekend, go-live Monday in flames

One contrarian rule to close: the faster the data migration, the faster the project dies. Every client who tells me "data migration takes three days" gets their go-live pushed a month. Slow is fast. Clean data is the only real infrastructure a WMS go-live has.

By Lin Xiao, WMS Implementation Consultant