A courier operation has a problem most businesses do not: at any moment, thousands of items are physically in transit, each with a tracking number a customer already has. You cannot pause that, and you cannot invalidate those numbers.
In-flight shipments decide your approach
Two options, and the right one depends on transit time:
Drain. Stop booking in the old system on a set date; keep it live for tracking and delivery updates until the last consignment booked in it is delivered. New bookings go to the new system from day one. Clean, and requires running both for roughly one transit cycle.
Migrate in-flight. Move active consignments with their current status into the new system. Cleaner for staff — one screen — but any status mapping error affects a real parcel someone is waiting for.
For most regional operators, drain is safer. Transit times are short enough that the parallel period is a couple of weeks rather than months.
Old tracking numbers must keep resolving
Customers have tracking numbers on receipts, in emails, in SMS. They will look them up for months. If those return "not found", your support line absorbs it.
Either import historic consignment records so the numbers resolve in the new system, or keep the old tracking page live and route unrecognised formats to it. Decide which, and test with a real number from six months ago.
COD is where money actually goes missing
Cash on delivery collected against consignments booked in the old system, remitted after the new one is live. If the two systems disagree about what was collected and what is owed to which client, the reconciliation becomes manual and the disputes are with people who pay you.
Freeze COD reconciliation at the cutover boundary: close and settle everything booked in the old system through the old system, even after new bookings have moved. Do not let a single COD settlement span both.
Your API consumers cannot be broken
E-commerce clients integrate against your booking and tracking APIs. Their developers are not sitting waiting for your migration.
- Give notice measured in weeks, not days
- Keep the old endpoints working during a defined overlap, even if they proxy to the new system
- Document exactly what changes in request and response shapes
- Provide a sandbox before the switch
- Expect some clients to do nothing until the last week — plan for it rather than being annoyed by it
Breaking a client's integration without warning costs more relationship damage than the entire migration is worth.
Reference data first
Before any consignment moves: pincode and serviceability master, rate cards per client, hub and route definitions, delivery staff. Get these right and verified, because every booking depends on them and an error here shows up as mis-rated consignments rather than as an obvious failure.
Rate cards are the most error-prone. Have each client's rates checked by whoever negotiated them, not by whoever is doing the data entry.
Training the people who will decide whether this works
Delivery staff and hub operators, on their own devices, before go-live. If the mobile app for proof of delivery is slower or more confusing than what they used before, adoption fails at the last mile — literally — and the tracking data becomes unreliable, which undermines the whole point.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
