Switching WMS: how to keep your warehouse history

What happens to warehouse history when you change WMS vendors?#

Warehouse history usually stays in the old WMS when you change vendors, because migration projects load what the new system needs to run, not what the old system remembers. Item masters, locations, client setups and on-hand inventory move; receipts, putaways, picks, cycle counts, adjustments and shipment confirmations generally do not.

That history is easy to lose. Cloud WMS access typically ends with the subscription, on-premise servers are retired once the new system is stable, and the people who knew the old reports move on. Later, a client disputes an old shrink adjustment or asks for a shipment history, and the answer sits in a system nobody can log into.

The fix is to treat history as its own workstream with a named owner, separate from the cutover plan the implementation team is driving.

What moves to the new WMS and what gets archived#

The split between migrated and archived data is predictable once you separate what the new system needs to operate from what the business may need to answer later. Use the table to agree scope with the implementation partner before data mapping starts.

Pre-switch export checklist#

A pre-switch export checklist should be finished before the old system's access, license or support ends, and ideally before the final parallel run. Give it to someone who knows the old reports and has database or administrator access, not to the team configuring the new system.

• 1Confirm in the vendor contract how long access lasts after termination, which export formats are available and whether export help is included.
• 2Request the database schema or table documentation, or document it yourself from the reporting layer.
• 3Export transaction tables in full: receipts, putaways, moves, picks, packs, shipments, counts and adjustments.
• 4Export exception and hold records with notes, reason codes and resolution status.
• 5Export billing activity and accessorial charges with the invoice numbers they rolled into.
• 6Export code tables: reason codes, status codes, location types, carrier and service codes, and user roles.
• 7Capture a final on-hand snapshot by client, item, lot and location that ties to the cutover count.
• 8Validate exports with control totals, such as order and line counts by client and month, against the old system's reports.
• 9Store the archive in a controlled location with an owner, an access list and a retention period.

How to keep client-level history separable#

Client-level history stays separable when every exported row carries the client or owner ID and the archive can be filtered by it without fragile joins. For a 3PL this is not optional: contracts may require returning or deleting a client's data when the relationship ends, and a client audit should never expose another client's orders.

Check that the owner field is populated on transaction tables, not only on items, because some systems infer ownership from the item or location. Where shared items or commingled locations exist, write the owner explicitly during export. Keep a client mapping table linking old client codes to new ones and to the legal entity named in each contract.

Many 3PLs also write each client's history to its own folder or partition. A later return, deletion or permission request then becomes a file operation rather than a data project.

Contract terms that decide what you can keep#

Contract terms decide both how you get history out of the old WMS and what you may do with it afterward. The vendor agreement governs access and export; client agreements govern ownership, retention and use.

In the vendor agreement, look for data return obligations, termination assistance, export formats and any charges for bulk extraction. In client agreements, look for clauses on data ownership, confidentiality, return or destruction at termination, and permitted use. A 3PL may hold its own operational records, such as exception handling notes and process documentation, under different terms than client order data, so read both before deciding what the archive is for.

Illustrative: a fulfillment 3PL keeps history through a cutover#

Illustrative: a fictional ecommerce fulfillment 3PL serving apparel, supplement and home goods brands moves from an on-premise WMS to a cloud WMS. The cutover plan covers items, locations and inventory, and the old server is scheduled for retirement shortly after go-live.

The COO names a history owner, who exports transaction, exception and billing tables with the owner ID on every row, builds a data dictionary from old reports and code tables, and ties order counts by client and month to the old system. Each client's history lands in its own partition.

Later, one brand leaves and asks for its data to be returned and deleted. The 3PL delivers that partition and deletes it with a log. When the company afterward reviews whether its exception records could support a license, its own exception notes are already separated from client order detail, which makes the rights review far simpler.

Making the archive useful later#

An archive is useful later when someone outside the original project can read it. Store transaction tables in an open format such as CSV or Parquet, keep the data dictionary and code tables beside them, and add a short note on known gaps, such as periods when a field was not used or a client was onboarded mid-stream.

Exception and adjustment records are often the most valuable part of warehouse history, both internally and for AI developers building logistics agents. If licensing is ever on the table, SourceX begins by asking about systems, years and record families rather than files, and any later work runs through the SourceX five-step transaction, from Supply and Rights to Preparation, Approval and Delivery. Large archives stay in the company's own storage, and client-owned data is reviewed against each client contract before anything is in scope.