WMS data migration: SKUs, units, locations, and opening stock

WMS data migration is successful when the new system represents the same usable stock and open work as the warehouse, not when an import finishes without errors. Validate identifiers, units, locations, ownership, status, and required lot or serial detail before moving balances. Rehearse the transformation and reconcile the result. A clean file with the wrong pack conversion can create a larger problem than a visibly rejected record.

Assign a business owner to the fields

Create a data dictionary for item identifiers, descriptions, units, pack conversions, locations, owners, statuses, and tracking requirements. Record the source, target field, transformation, validation, and approver. The person writing the import should not have to decide whether a carton contains twelve or twenty-four eaches. That is a business data decision requiring evidence.

Separate inactive data from data needed to complete open work or retain required history. Do not migrate every obsolete item simply because it exists, but do not delete records without checking business and retention needs. Ask finance, operations, quality, and legal specialists where relevant. Retain the original extraction so a transformation can be explained and repeated during rehearsal.

Validate units before quantities

An illustrative example shows the risk: ten cases with twelve eaches per case equal 120 eaches. If the new system interprets the same ten cases as individual units, the balance becomes ten. The import can be technically valid while the inventory is wrong. Test receipts, storage, picking, shipping, and returns across the approved units rather than checking only a static item record.

Distinguish purchasing, storage, selling, and shipping units. Confirm whether partial cases are permitted and how rounding is handled. Check barcodes against the intended unit and product identity. A scan that identifies an item does not necessarily identify its pack quantity. Document conversion changes rather than overwriting a master field without understanding their effect on existing stock.

Use layered validation

Reject and log invalid records with a reason. Do not silently substitute a default location, owner, or status just to make the import pass. A default can be appropriate only when the business has approved it and can identify the affected records. Preserve counts and totals at each transformation stage so a missing subset can be located.

Rehearse with representative complexity

Include more than clean, fast-moving items. Test inactive items with open orders, mixed units, multiple owners, empty locations, held stock, lots, serials, and partially completed work where relevant. Run the same import process planned for cutover. Record duration, errors, manual decisions, and reconciliation results. Use the findings to repair the source or transformation before the final run.

Define control totals carefully. A grand total quantity across unrelated units can conceal offsetting errors. Reconcile by item, unit, location, owner, status, and tracking detail where required. Compare open order and receipt positions separately from stock. Ask the receiving and shipping teams to complete sample transactions after import to prove that migrated data can support actual work.

Control the final extraction and sign-off

At cutover, define how physical movements and transactions are restricted while the final position is captured. Record the extraction time, source version, import version, rejected records, and approved corrections. If work continues, use a controlled delta process with clear ownership and reconciliation. Do not assume a database timestamp alone captures every physical event on the floor.

Approve opening stock and open work before releasing normal tasks. Keep unresolved differences visible and prevent uncertain stock from being allocated if necessary. Retain the evidence used for approval and a mapping between old and new identifiers. Migration is part of the cutover decision, so the person approving stock must understand whether a remaining discrepancy is acceptable and how it will be resolved.

FAQ

Should historical transactions all move into the WMS?

Not automatically. Decide what is operationally required and what can remain in an accessible archive, subject to applicable retention obligations. Verify that the archive is usable.

Can the supplier clean our master data?

It can help implement checks, but business owners must approve identities, units, status rules, and other operational meanings. Make that responsibility explicit.

Is a matching total inventory value enough?

No. Financial totals may conceal differences in location, unit, owner, status, lot, or serial. Reconcile the dimensions needed to operate the warehouse.

Continue your decision

• WMS implementation roadmap: from scope to controlled launch — Organize a WMS project around approved workflows, data readiness, tested interfaces, floor training, and an explicit go-live decision.
• Run a warehouse requirements workshop on the floor — Capture actual receiving, replenishment, picking, packing, and exception requirements in a workshop that leads to test cases.
• WMS integration testing: retries, duplicates, and reconciliation — Test order and inventory interfaces beyond the happy path, with ownership rules, retry scenarios, and reconciliation controls.
• Use the launch readiness checklist to connect this guide to a practical planning task.
• Compare WMS approaches before treating a product category as a complete specification.

Sources and scope

Official pages checked on October 30, 2026. The planning procedures, test scenarios, and worked examples are original editorial guidance, not prescribed standards or evidence of product testing.

• SAP — What is a WMS? — General warehouse execution terminology; supplier education, not independent product evaluation.