WMS Migration Checklist: Old to New

A WMS migration checklist for moving from one warehouse system to another starts with why you are moving and the exit terms in your current contract, then covers a test export, field mapping, cut-over, open orders and rollback. It is different from a first rollout. You already have live stock, open orders, staff habits and a contract that may not be finished. You also have something a first-timer lacks: history that you do not want to lose.

This checklist is for warehouse and 3PL owners who run a system today and plan to replace it. It does not promise how long any of it takes, because that depends on your data and your vendors. It does tell you what to check and in what order.

Start with why, and what you must keep

Write down the reasons for the move in one paragraph. Examples: the price model punishes growth, a process cannot be configured, support is slow, the vendor is retiring the product.

Then write what must survive the move:

• Item records and units
• Current stock by location, lot and status
• Open orders and receipts
• Customer and supplier records
• Order history you need for billing, claims or reports

Read the exit terms before anything else

Do this before telling the old vendor anything, and before signing with a new one.

• When does the current contract end, and what notice is required?
• Does it renew automatically? On what date?
• Is there a fee for exporting data, or for access after you stop paying?
• How long will you keep read access to the old system after switching?
• Who owns the data, and in which formats can you take it?
• Is there help with the transition, and is it paid?

Put the notice date in a calendar with a reminder well ahead of it. Missing a notice date is the easiest expensive mistake in this process. This page is not legal advice; ask a lawyer to read the contract if the terms are unclear.

Test an export before you commit

Ask the old system for a full export early, even if you are not sure of the move.

Check:

• Can you get every table you need, or only reports?
• Is the file complete, or does it cap rows?
• Does order history come out with line detail?
• Are lot, serial and expiry values included?

If the export is poor, that changes your plan, your timeline and possibly your choice of new system.

Map each field to its new home

Make a mapping table for every data type. One row per field.

Common traps:

• The old system stores a unit of measure in a way the new one does not.
• Location names change, and nobody updates the labels.
• Old status codes mean different things in different departments.
• Lot numbers have been typed several ways for the same lot.
• Customers have duplicates under slightly different names.

Fix the data in a working copy, not in the live old system, so you always have the original to compare.

Decide the cut-over style

There are two broad ways to switch.

Parallel run

Both systems run for a period. Staff enter work in the new system while the old one is kept up to date or reviewed.

• Pros: safety net, easy comparison.
• Cons: double work, risk of the two drifting apart, staff unsure which is the truth.

Hard cut-over

One day the old system stops and the new one starts, with a final count in between.

• Pros: one source of truth, a clear start, no double entry.
• Cons: no fallback unless you plan one, and mistakes show up at once.

A middle path is common: run parallel for one client, one zone or one order type, then cut over the rest. Whatever you choose, write down who decides, and what condition means "go."

Plan the cut-off count

Stock changes every hour, so the numbers you load have to match a fixed moment.

1. Choose a cut-off time and tell customers and carriers.
2. Finish or park all in-progress work, such as half-picked orders.
3. Count the stock, or at least the high-value and high-movement parts.
4. Reconcile the count to the old system and decide which is right.
5. Load the agreed numbers as opening stock in the new system.
6. Check a sample by physically looking at the shelf.

Do not skip step 6. A clean load that disagrees with the shelf is still wrong.

Handle open orders and receipts

The awkward items are the ones half way through.

• Orders not yet picked: re-enter or import them into the new system.
• Orders partly picked: finish them in the old system, or reset them cleanly.
• Receipts expected: load them as open receipts so staff can receive against them.
• Returns in transit: decide where they will be processed.

Make a list of every open document at cut-off, with the decision for each.

Test with scenarios before the day

Before go-live, run realistic scenarios in the new system with the loaded data: receive a delivery, put away, pick a normal order, short pick, return, adjust stock, ship, and produce your usual reports and documents. Check that labels print, integrations send, and customer documents look right. Include the cases your old system handled quietly, since those are the ones people forget to ask for.

Prepare a rollback

Decide in advance when you would go back, and how.

• What is the trigger? For example, stock that cannot be located, or orders that cannot ship by an agreed time.
• Who makes the call?
• How would you restore the old system, and what would you do with work entered in the new one?
• How long will the old contract and data stay available?

Rollback is not pessimism. It is the reason a cut-over can be done calmly.

After the switch

• Keep the old system read-only until reports match and the first billing cycle is done.
• Keep a list of issues, with an owner and a date.
• Confirm in writing that the old vendor has ended access, and that your data has been deleted or returned as agreed.
• Calendar the date the old contract actually ends.

An example (hypothetical)

A small 3PL runs a system that charges more as it adds clients. The owner decides to move. She reads her contract and finds a notice period that falls in a busy season, so she plans around it. She asks for a test export and learns that order history comes out as summary lines only, so she saves detailed invoices as PDFs separately. She does a parallel run with the smallest client, cuts over the rest after a clean week, and keeps the old system read-only for one billing cycle.

The business is invented. The lesson is that most of the work happens before the day itself.

A note on options

When you replace a system you can pick a subscription product or a one-time custom build. Cargohold, which we make, is a one-time custom build, no per-seat, per-truck or per-client fees. The checklist above applies equally to any new system.

Next step

Find your contract, locate the notice date and put it in your calendar today.

Questions people ask

What should I check first when replacing a WMS?

Your current contract. Look at the end date, the notice required, automatic renewal, any fee for exporting data, how long you keep read access, and who owns the data and in which formats you can take it.

How do you migrate data to a new WMS?

Test an export from the old system early, map each field to its new home, plan a cut-off count, and handle open orders and receipts explicitly before the switch.

Why test a WMS data export early?

To see whether you get every table you need or only reports, whether rows are capped, whether order history has line detail, and whether lot, serial and expiry values are included. A poor export changes your plan.

Should I use a parallel run or a hard cut-over for a WMS migration?

A parallel run gives a safety net but means double work and the risk of two systems drifting apart. A hard cut-over gives one source of truth but no fallback unless you plan one. A middle path is to run parallel for one client, zone or order type first.

How do I handle open orders when changing WMS?

List every open document at cut-off and decide for each. Re-enter or import unpicked orders, finish or reset partly picked ones, load expected receipts as open receipts, and decide where returns in transit will be processed.

Should I plan a rollback for a WMS migration?

Yes. Decide the trigger, who makes the call, how you would restore the old system, and how long the old contract and data stay available.