Migrating to an OMS without losing orders

An OMS migration fails in the overlap, not in the build. The configuration work is finite and the vendor does most of it. The dangerous stretch is the two to four weeks when orders exist in two systems, stock exists in two ledgers, and nobody is certain which one is right.

What has to be true before you book a date

Three things, and none of them are the vendor’s job.

A frozen SKU master. Pick the identifier scheme you are going forward with, clear the duplicates, then freeze creation. No new SKUs, no renamed SKUs, no changed pack configurations from the freeze date until go-live plus one week. Almost every migration that goes badly has a SKU created during the cutover window that exists in one system and not the other.

A known-good stock count. Not a cycle count. A full physical count at every node, closed and signed, as close to the cutover as your operation allows. The opening balance in the new system is whatever you load, and you will be defending that number for months.

A decision on history. Open orders have to move live. Closed orders do not. Decide how far back you are loading closed orders and put the rest into a flat archive you can query but not transact against. The floor is set by your longest return window, because anything inside that window can still come back and needs a record to come back to.

Cut over your smallest channel first

The instinct is to move the big channel first so the benefit arrives sooner. Do the opposite. You want your first live day on the channel where a bad hour costs forty orders, not four thousand. Usually that is your own site or your smallest marketplace.

Quick commerce is the worst possible first channel. Purchase orders carry appointment windows and fill rate scoring, and a missed slot becomes a number on a scorecard you spend the rest of the quarter repairing. Move it last, after two other channels have run clean.

The parallel run and what you actually compare

A parallel run means both systems receive orders. It does not mean both systems act. One system allocates, fulfils and invoices; the other shadows it. Two systems generating documents against the same order is how you end up unwinding duplicates for a quarter.

Run it until you have cleared two full return cycles, or three weeks, whichever is longer. Every night during the overlap, four numbers get compared and someone signs off:

• Orders accepted per channel, old versus new.
• Units allocated and units unallocated, by node.
• Sellable stock on hand per SKU per node.
• Documents generated and documents failed.

A variance that repeats on the same SKU family two nights running is a mapping problem. A variance that moves around is a timing problem. Log both, fix the mapping ones before go-live, and accept that timing gaps will persist while two systems poll on different intervals.

The three things that break in India

Invoice series continuity. The new system will want to start its own numbering. Decide, with your finance lead and your tax advisor, whether it continues the existing series or opens a distinct one with its own prefix, and make sure exactly one system is authorised to generate documents for a given channel at any moment. Where you generate e-invoices, only one system holds that job during the overlap. Two systems attempting the same document is painful to unwind and visible to the platform.

Orders in mid-flight. At the cutover moment there is a population of orders accepted, allocated, possibly picked, not yet manifested. Do not migrate them. Let the old system finish and ship them, and route only new acceptances to the new system. That means a defined acceptance boundary by timestamp per channel, published to the warehouse and to customer support before the day starts.

Returns raised against the old system. A return raised last week arrives next week against an order ID the new system may not recognise. Whoever receives it needs a lookup into the archive and an agreed manual path to credit the customer. Brief support before go-live, not after the first angry ticket.

One person owns the switch

Not a committee and not the vendor. One named operator with authority to stop the cutover, a runbook with timestamps, and a channel where every exception gets posted as it happens.

The runbook is dull and that is the point: freeze the SKU master, close the count, load balances, disable order acceptance on the first channel in the old system at a stated time, enable it in the new one, then walk the first ten orders end to end by hand before releasing the rest. Ten orders walked manually surface more than a week of test scripts, because they touch the real courier, the real document and the real customer address.

Write the rollback criteria before you need them

Rollback decisions made at 2am are bad decisions. Agree the thresholds in advance, in writing, with names against them. Something like: unallocated orders above an agreed percentage at hour twenty four, stock variance beyond an agreed unit tolerance at any node, or document failures above an agreed count. Any one of them triggers a rollback, and nobody gets to argue at the time.

Also write the point of no return. Once the new system has invoiced and shipped a full day across a channel, rolling back stops being cheaper than fixing forward. An honest plan says so out loud, so the team knows which side of the line it is standing on.