Logistics and distribution
WMS migration: preserving historical order and exception data
By SourceX Editorial · Updated
Short answer
A WMS migration preserves historical data only if the project scopes an archive separately from conversion. Conversion moves open orders, item masters and on-hand inventory; it rarely moves closed orders, short-pick and adjustment history, reason codes or supervisor notes. Decide what to archive, in what format and who can query it before the cutover date is set.
Key takeaways
- Conversion scope and archive scope are different decisions, and usually only conversion has an owner.
- Exception records such as short picks, adjustments and holds are the history most often left behind.
- Code tables and reason code definitions must be archived with the transactions, or the history becomes unreadable.
- A database backup is not a usable archive unless someone can query it without the old application.
- In a 3PL, client contracts, not system ownership, decide how archived client order data may be used.
What a WMS conversion usually moves, and what it leaves behind#
A WMS conversion usually moves only what the new system needs on day one: item masters, locations, open orders, on-hand inventory by license plate or lot, and active client and carrier setups. Closed and historical records tend to stay behind, because loading them costs mapping and testing time and adds little to go-live.
That is a sensible go-live choice. The trouble is that nobody owns the leftover history, so it sits on a server scheduled for decommissioning or in a SaaS tenant that closes when the subscription lapses.
| Data | Usually converted? | What is lost if it is not archived |
|---|---|---|
| Item, location and client masters | Yes, current records only | Retired items, old slotting and past client setups |
| Open orders and on-hand inventory | Yes | Little, if counts reconcile at cutover |
| Closed orders and shipment history | Rarely | Order profiles, seasonality and client history |
| Short picks, adjustments and cycle count variances | Almost never | The record of what went wrong and why |
| Reason codes and code tables | Active codes only | The meaning of codes in older transactions |
| Supervisor notes and task overrides | Almost never | Judgment calls and workarounds |
| Billing activity and accessorial events | Sometimes, as totals | Line-level evidence behind client invoices |
| Audit logs and user activity | Rarely | Who changed what, and when |
The exception records that disappear first#
Exception records disappear first because they are spread across tables nobody maps: adjustment logs, task histories, hold tables and free-text comment fields. They also carry the most operating knowledge, since each one shows a problem, a decision and a result.
If a 3PL or distributor later wants to test an exception-handling agent, track error trends across years or license workflow records, these are the tables that matter most.
- Short picks and pick substitutions, with the order line and the picker's action.
- Inventory adjustments with reason code, user and approver.
- Cycle count variances and recount results.
- Damages, quality holds and inspections on receipt.
- Receiving discrepancies against ASNs or purchase orders.
- Returns with their disposition decisions.
- Manual task overrides and wave or replenishment changes.
- Comments added by supervisors, customer service or client success staff.
Scope the archive before the cutover plan#
Scoping the archive before the cutover plan means naming an owner, a list of tables or exports, a format and a way to read the data once the old WMS is gone. Do it while the people who know the old schema are still on the project.
Ask the outgoing vendor or your own developers which tables hold transaction history, which hold codes and configuration, and which custom fields were added over the years. Homegrown and heavily customized systems often keep critical history in tables with cryptic names, and that knowledge leaves with whoever built them.
Read the contract as well. SaaS WMS agreements differ on export formats, fees for bulk extracts and how long data stays available after termination, so check the termination and data return clauses before giving notice.
Connected modules need the same treatment. Labor management, parcel manifesting, yard management and billing add-ons often keep their own history tables, and if they are replaced at the same time as the WMS, their records can vanish without anyone noticing.
Checklist: preserving WMS history at cutover#
Preserving WMS history at cutover comes down to a short list of steps that conversion plans most often skip. Run them alongside the conversion plan, not after go-live, because several depend on the old system and the people who know it still being available.
- Inventory every history table, including custom ones, with row counts and date ranges.
- Export transactions with keys intact: order, line, license plate, lot, location, user and timestamp.
- Export every code table, including retired codes, with their descriptions.
- Keep free-text fields and attachments such as damage photos and signed bills of lading.
- Document the schema in plain language: what each table and key field means.
- Reconcile export totals against the source before the old system is switched off.
- Record which clients' data sits in each export, for later contract checks.
- Store the archive with access controls and a named owner.
What a usable WMS archive looks like#
A usable WMS archive is one that a person or a tool can query without the old application, with keys and codes that still make sense. Each format trades cost against usefulness.
Many teams combine two options: a full backup for completeness and legal hold, plus table exports loaded into a data warehouse for everyday analysis alongside ERP and TMS history. Open file formats such as CSV or Parquet, shipped with a plain-language data dictionary, stay readable long after the old database engine is gone.
Note where personal data sits as well. User IDs tie tasks to employees, and e-commerce fulfillment tables hold consumer names and addresses, so restrict access and record which tables contain them for any later review.
| Archive option | Good for | Watch for |
|---|---|---|
| Full database backup | Legal hold and a complete copy | Needs the old database engine and schema knowledge to read |
| Flat file exports by table | Low cost and portable | Keys and code tables must be exported too |
| Load into a data warehouse | Analysis and joins with ERP and TMS history | Mapping effort and ongoing storage cost |
| Read-only legacy instance | Lookups by staff who know the old screens | Licensing, hosting and security patching over time |
| Vendor archive service | Simple handover from a SaaS WMS | Format, fees and how long access lasts |
Illustrative: a multi-client 3PL retires a homegrown WMS#
Illustrative: a fictional multi-client 3PL in the Midwest runs a homegrown WMS written by a developer who left long ago, and it is moving to a commercial cloud WMS. The conversion team maps clients, items, locations and open orders. Nobody has scoped closed orders, adjustments or the comment table where supervisors explained short shipments.
The IT director pauses to inventory history tables and finds a reason code table full of retired codes no current employee recognizes. The team interviews long-tenured supervisors to document those codes, exports every history table with keys, and loads the exports into the data warehouse the finance team already uses. Each record is tagged by client account.
After go-live, the 3PL tests an exception triage tool against its own past short-ship cases. The client tags also let counsel check each client agreement before any workflow records are considered for licensing.
How SourceX looks at a WMS archive#
SourceX starts with a metadata-only fit check: which WMS, which years, which record families, and whether exceptions link to orders and outcomes. Nothing is shared at that stage, and linked exception history often matters more than raw volume.
If a company proceeds, the SourceX five-step transaction covers Supply, Rights, Preparation, Approval and Delivery. For a 3PL, rights review centers on client contracts, because client order data held in a WMS is not automatically the 3PL's to license. Large archives can stay in the company's own storage.
Frequently asked questions
Should we convert all historical orders into the new WMS?
Usually not. Loading closed orders adds mapping and testing effort and can slow the new system. Most teams convert open activity and keep history in an archive or data warehouse, where it can be queried and joined with ERP and TMS records.
Who should own the WMS archive?
Name one owner, usually in IT or data, with a business sponsor from operations. The owner keeps the schema notes, access list and retention decisions. Without an owner, archives drift toward deletion whenever a server or subscription is retired.
How long should the old WMS stay available after go-live?
Keep it read-only until the archive is reconciled, billing for the cutover period is closed, and open claims or client disputes that reference old orders are resolved. Then retire it on a planned date, with written sign-off from the archive owner and finance.
How do we handle client data in a 3PL WMS archive?
Tag every record with the client account so each client contract can be applied later. Some agreements require return or deletion of client data when the relationship ends, so check those obligations before keeping or using the records.
Is an archive of PDF reports enough?
Rarely. Reports show totals and selected fields, not the line-level transactions, codes and timestamps needed to analyze exceptions or test software. Keep structured exports and treat saved reports as a supplement.
What if the outgoing vendor charges for a bulk export?
Budget the export as part of the migration and negotiate early, before a termination notice weakens your position. Ask for table-level exports with keys and code tables, and confirm the format in writing.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.