Planning a Cloud WMS Migration from On-Premise Legacy Systems

You have an eight-year-old on-premise WMS that IT maintains full time. Every integration takes months and consultant fees, and the last outage stopped order processing for two days. Now vendors are quoting a 30-day cloud go-live. The migration usually fails on the floor, not in the server room. Pickers ask "how do I do X?" and nobody can answer. Customer orders ship with the wrong label or pack quantity. Locations don't match reality. The vendor's import runs clean, and the warehouse still stalls.

Each wrong fix below fails for a specific reason. After them come the real cause, the procedure, and the verification checks.

Throw Out the 30-Day Go-Live Schedule

The first wrong fix is accepting the vendor timeline and building the project plan around it. A 30-day window can produce a technical go-live: the tenant is configured, data is loaded, and scanners log in. It does not produce a warehouse that runs.

• Minimum realistic duration: about three months, and only when nothing major goes wrong.
• Multiplier rule: plan for at least twice the vendor's estimate. Data migration is where the extra time goes.
• Stabilization: expect 90-120 days after go-live before the team is comfortable and productive again.
• Change management per site: close to 6 months per operation is common. Sites with a lot of improvised practice take longer.
• Slip risk: one project announced an October 2023 go-live and went live in April 2024. Custom customer requirements took most of that time. The team had already been told to keep weekends open and PTO was frozen for the whole period.

The 30-day figure is wrong because it leaves out process documentation, which alone takes months. It also leaves out cloud configuration, and testing the new features your operators have to learn. Build the schedule from those three blocks. Do not announce a go-live date to the floor until data testing (below) passes twice.

Stop Loading Every Year of History Into Production

The second wrong fix is treating "preserve our history" as "load all history into the new WMS." This fails for two reasons:

1. Schema mismatch. An older on-premise WMS data structure rarely maps cleanly to a modern cloud WMS. Loading history means building ETL flows to transform every legacy table. With that scope, 30 days is almost guaranteed to be too short.
2. Performance. Most WMS platforms keep only 1-2 years in the read/write functional tables, because larger tables slow transaction performance. Moving eight years of transactions into production tables moves the old system's slowdown into the new one.

Hard rule: never keep reporting or historical data on the production WMS. Operations need current state: what has to be picked, put away, replenished, or counted now. History belongs in a reporting system.

You have two clean options:

• Clean cutover plus archive. Start fresh in the new WMS with current master data and open transactions. Export historical data to cloud storage for reference only.
• Replicated data warehouse. Stream legacy data, and later the new WMS, into a cloud data warehouse through a replication or datastream job. One multi-site operation with a few thousand operators keeps 10 years of history in Google BigQuery, with reporting and analytics running there, for under $1K per year in cloud cost. Cost scales with volume, so price your own data size. A replication path also keeps production light after go-live, not just at migration.

If the new WMS needs history for slotting or velocity decisions, analyze the history before migration. Load the result as attributes, for example A/B/C mover classes on the item master, rather than raw transactions.

Don't Map Every Process, and Don't Skip Discovery

Process documentation fails in two opposite ways.

Wrong fix A: document every current process step-by-step. Much of your current process is driven by the old system's limits: poor data visibility and missing features. Detailed maps of "how we pick today" describe workarounds for software you are retiring. The new system will train you on its own picking method, and that is often good enough.

Wrong fix B: trust the official SOPs. The gap between the official SOP and what veteran operators actually do is often 30% or more. Workarounds built over eight years on a legacy system are rarely written down. They surface after go-live as "how do I do X?" and X is in no SOP.

What works sits between the two:

1. List your major process families: ecommerce, wholesale, inbound, outbound, transfers, adjustments, returns, kitting.
2. For each one, write the handful of points that must be achieved for the process to succeed. Examples: correct customer label, correct pack quantity, lot or expiry captured, carrier manifest closed.
3. Have your most experienced floor staff walk through their real daily workflow while someone records it. Capture every step that isn't in the SOP.
4. Sort each captured item into one of two buckets. Legacy workaround: drop it if the new system handles the case natively. Customer-specific requirement: it must be configured.
5. Accept the new system's generic process wherever it hits the must-achieve points. Configure or customize only where it doesn't.

Stop Relying on Classroom Sessions and Handed-Out Documents

The fourth wrong fix is a short training block before go-live: a few sessions in a conference room and a PDF to every operator. It fails because:

• End users rarely read distributed documentation.
• Subject matter experts who only watch a demo cannot run the process on the floor.
• Delays compress training. One WMS team got less than two weeks to train everyone on everything, with no documentation. The ERP replacement at the same company a year earlier got three months of training. That pattern is common: ERP is treated as the project and WMS as an afterthought.
• People who have done the same job the same way for years resist the change, and you cannot flip a switch and expect instant adoption.

Start training much earlier than you think you need to, on the new system loaded with your own data. The role-based method is in the training section below.

Find the Real Cause: Master Data and Customer-Specific Rules

Historical transactions are usually the easy part of data migration. What stalls go-live is master data: item masters, units of measure, location records, and the customer-specific handling rules that live only in veteran operators' heads.

Symptom after go-live	Likely cause	First check
Operators keep asking "how do I do X?"	Undocumented workaround never captured in discovery	Log every question for the first two weeks; each one is an unmapped process
Orders ship with the wrong label or pack quantity for a customer	Customer-specific notes (labeling, pick-into quantities) not migrated into system rules	Compare the legacy customer notes field against the new customer or order configuration
Directed putaway or replenishment sends operators to wrong or nonexistent locations	Dirty location master: dead bins, wrong dimensions, wrong zone assignments	Physically audit a sample of location records against the rack
Picks or counts disagree with on-hand quantity	Item master UOM or pack configuration errors, or a transform error in the load	Reconcile quantity per item and location between legacy and new system during parallel run
Screens and queries slow down within months	History or reporting data kept in production tables	Check the retention period on transactional tables; move reporting to the warehouse replica
VLM or other MHE doesn't receive tasks or confirm picks	Integration claimed at the demo but never proven	Run the MHE interface end-to-end in test before go-live

Start auditing item masters and location data now, before vendor selection finishes. That work does not depend on which WMS you pick, and it is the longest pole in the data workstream.

Customer-specific requirements get special handling. Notes like how to label a customer's cartons, or what quantities they want items picked into, are configuration requirements. Don't bring them over as free-text notes the operator is supposed to read. One site with a stable, experienced crew went live fine on routine work, then struggled afterward to get those custom notes into the new system. Put them into the rules or configuration of the new system before go-live.

Qualify the Vendor Against Your Equipment and Integrations

The main operational benefit of a cloud WMS is faster integration. One migrated site now adds integrations in days, where it used to take months. Cloud platforms differ widely here, so test this during selection instead of taking the vendor's word.

Score each candidate on:

• Integrations: sales channels, parcel carriers, ERP, MHE, EDI, and how far you can customize.
• RF-enabled workflows:
  • Picking: bulk, batch, and single.
  • Packing: bulk, by item, and by case.
  • Counting: cycle and physical.
  • Directed putaway and replenishment.
  • Kitting, work orders, and BOM.
  • Receiving and returns.
  • Labor tracking and 3PL billing, if applicable.
  • Lot, serial, and expiry support.
• Data connectivity: API coverage, ease of export and import, and data warehouse support. This is what makes the replication approach above possible.
• UI: modern, usable on mobile and tablet, with Android and iOS app availability.

Two selection failures to rule out early:

1. Wrong product class. A WMS built exclusively for 3PL operations will fight a distributor that is not a 3PL. Confirm the vendor's core customer base matches your business model.
2. "Yeah, we handle those." One site with vertical lift modules (VLMs) talked to four or five vendors, and every one said it supported VLMs. Only two actually could, and only one did it well. Make every vendor show working evidence for each equipment type and workflow on your must-have list. Visit a warehouse running the WMS and judge whether the process it enforces is a good one.

Build and Rehearse the Data Pipeline Before Cutover

Do this in order:

1. Secure the legacy data. Have a DBA copy the old WMS tables, or extract them to a compressed file format if the volume is large. Check with IT first: the legacy database may already have archive tables for exactly this.
2. Stand up the reporting destination. Configure replication or a datastream from the legacy system into the cloud data warehouse. Point historical reporting there now, so the new WMS never carries that load.
3. Decide the load scope. Choose between a clean cutover (current master data plus open transactions) and a full ETL transform of history. If you choose ETL, re-plan the schedule; this is the path that breaks short timelines.
4. Clean the master data. Fix item masters, UOM and pack definitions, and location records at the source, before the first export.
5. Practice export and formatting. Run the full extract and transform to the new system's import format repeatedly until it runs without manual fixes. Every rehearsal surfaces formatting problems you would otherwise hit at cutover.
6. Load test data and walk it. Load enough data to test and validate: your orders, your inventory, your layout. Supervisors then walk the floor with RF devices running real tasks against that data.
7. Wipe and reload. Clear the test tenant and load fresh data again. Each cycle is cutover practice. Do not wipe and reload years of data this way; keep test loads to validation size.
8. Stage the final load early. Do the large historical or master load a few days ahead of go-live. The cutover itself then only has to catch up with current details: on-hand deltas, open orders, receipts in progress.

Run a Short Cutover With a Parallel Safety Net

Keep the switch itself fast to limit downtime. In one on-premise-to-cloud ERP migration, the team exported and formatted the data, the vendor's staff imported it, and the site was live within 24 hours. That speed came from a lot of planning and setup beforehand, not from the cutover window.

Cutover procedure:

1. Freeze legacy master data changes at a defined point.
2. Export the final delta and apply the rehearsed format.
3. Import, then reconcile record counts and on-hand quantities against the legacy export before releasing work to the floor.
4. Run both systems in parallel for a few weeks. It doubles some work, but it lets you check that data migrated correctly before you fully commit to the new system.
5. Keep the legacy system available read-only until parallel reconciliation passes.

Write the fallback plan before go-live. The new cloud provider will have an outage at some point. The two-day outage that justified this project can happen on the new platform too. Decide ahead of time:

• How you pick and ship orders that can't wait if the WMS is unreachable.
• Who authorizes switching to the fallback.
• How transactions made during the outage get keyed back in afterward.

A major fallback plan also gives the floor a quick direction when smaller problems appear, and every system, including the new one, will need some workarounds.

Train by Role, Then Expand

When training time gets compressed anyway, narrow the scope:

1. Give each person one task family: packers only pack, pickers only pick, receiving only receives.
2. Train each person on that task alone, in the new system, with your own data.
3. After a few weeks of stable operation, expand roles one task at a time.
4. Use the vendor's training modules if they exist. Management should make them mandatory and enforce them. Operators who arrive at go-live unprepared after mandatory training are a management issue, not a project-team issue.
5. Get supervisors and SMEs out of the training room and onto the floor. They walk through every major process in the new system before go-live. Skipping the post-training walk-through is the most common implementation failure.

Customer-specific handling knowledge that lives only in veteran heads transfers through the discovery sessions and role-based floor practice, not through documents. Pair a veteran with each role during the first weeks and record every exception they explain. Each one is a missing configuration rule or a missing SOP line.

Confirm the New WMS Is Stable Before Closing the Project

Go-live is not completion. Check each of these during the 90-120 day stabilization window:

• Inventory reconciliation: on-hand quantity by item and location matches between the legacy system and the new WMS for the whole parallel run. Cycle counts in the new system confirm it.
• Question log trending to zero: the "how do I do X?" log shrinks week over week. A flat count means discovery missed a process family.
• Customer rules enforced by the system: labeling and pack-quantity requirements for special-handling customers come from configuration, not from operator memory or notes.
• Equipment integration: VLM and other MHE tasks complete end-to-end with no manual re-entry.
• Production kept light: transactional tables hold only the operational retention period, and reporting runs from the warehouse replica.
• Fallback plan tested: run it once as a drill, not only during a real outage.
• Integration turnaround: the next integration request is delivered in days, not months. That is the benefit you migrated for.

Stop and escalate to the WMS vendor's official support when a reconciliation difference traces to their import or transform tooling rather than your source data. Do the same when an integration the vendor committed to during selection does not work in test. Get these fixed under the implementation contract before you retire the legacy system or end the parallel run.

FAQ