How to switch dispatch software without losing a week

Most fleets stay on software they dislike for about a year longer than they should. Not because switching is hard in any technical sense — it rarely is — but because deliveries have to go out on the day you switch, and nobody wants to be the person who broke Tuesday.

That fear is reasonable and manageable. Here is how the switch actually goes when it goes well.

Pick the week deliberately

The single biggest factor in how a migration feels is when you do it.

Do not switch in your peak. Not December for retail, not the week before a holiday for grocery, not the first week of the month if that is when your wholesale orders land. The tool will be fine; your people will not have the slack to learn anything.

Do switch early in a week and early in a month, on a Tuesday rather than a Monday. Monday carries the weekend backlog. Tuesday gives you three working days to find problems while everyone is still fresh, and a Friday to catch up if you need it.

Give yourself a genuinely quiet fortnight. If your business has no quiet fortnight, take the quietest one and reduce the scope: move one depot or one route first.

What actually has to move

Less than people expect. Delivery operations are mostly about today, and today’s data is created fresh each morning. The persistent set is small:

• Customers and addresses. The big one, and the one worth cleaning on the way through. Export to CSV, fix the addresses that never geocode, then import.
• Drivers and vehicles. Usually a few dozen rows. Twenty minutes of typing.
• Zones, teams and depots. Redraw them. They are usually better the second time.
• Rules. Auto-dispatch logic, proof requirements, delivery windows, pay structure. This is where the thinking is, and it is worth an hour with a whiteboard rather than a copy-paste.
• Integrations. Store webhooks, API keys, anything posting orders in. Plan this as its own step.

Historical orders are the argument you will have with yourself. Ask what you would actually do with three years of them in the new system. Usually the honest answer is “nothing, but I want the reports”. Keep the old system read-only for a month, export a CSV of the history for your records, and move on. Migrating years of completed orders is where simple switches turn into projects.

Clean the address book on the way through

A migration is the only time anyone will ever clean the customer data, so use it.

Run the export through geocoding before importing. Anything that fails to resolve, or resolves to a town centre, is a stop that has been costing a driver ten minutes for years. Fix those, delete customers with no order in eighteen months, and de-duplicate the ones entered three times with different spellings.

Fleets routinely find 5–10% of their address book is wrong in a way that costs real time on the road. That alone can pay for the switch.

Run parallel, but with a rule

Running both systems for a few days is the right instinct and it fails when nobody decides which one is real.

Pick one to be the source of truth from day one — the new one — and use the old one as a reference you can look things up in. Two systems both accepting orders is how a delivery gets dispatched twice or not at all.

Three days of one depot on the new system, everything else unchanged, is a better test than everything running twice.

Drivers are the risk, not the data

Your data will import in an afternoon. Your drivers are the migration.

A driver who cannot complete a stop at 4pm on a wet Thursday will call the office, and if that happens for six drivers at once, that is the lost week people are afraid of. Prevent it:

• Install and log in the new app before cutover day, on every phone, with the driver present. Not by email instructions.
• Walk one real stop with each driver, or one group session with the phones out. Fifteen minutes.
• Give them one page: how to see the day, how to navigate, how to complete a stop, how to capture proof, who to call.
• Have a named person on the phone all day for the first two days who is not also dispatching.

Drivers adopt a new app quickly when the app shows one stop and one button. They adopt it badly when they first see it in the van.

The integration cutover

If orders arrive from a store or an API, this is the only step with a real ordering problem. Do it in this sequence:

1. Point the new webhook at the new system while the old one is still connected, into a test or staging organisation if you have one.
2. Place one real order and watch it land. Check the address, the line items, the note, the reference.
3. Cut over for real at the end of a day, not the start.
4. Watch the first morning’s orders arrive one by one before anyone plans anything.

The failure mode is orders arriving in neither system for two hours because a key was rotated. Confirm the first one lands with your own eyes.

What “migration help” should mean

When a vendor says migration support is included, ask what it actually is. Useful versions: they take your CSVs and do the import, they set up your rules with you on a call, they check the first live day with you. Less useful: a documentation link.

Ask directly — will someone be on a call with us on our first live morning? The answer tells you a lot about the year ahead.

A two-week plan that works

Week one, no pressure. Create the account. Import customers and drivers. Draw your zones. Set your rules. Put yesterday’s real orders in as a dry run and plan the day as if it were real — this is the rehearsal that finds every gap. Install the driver app on every phone.

Week two, one depot. Run one depot or one route live on the new system for three days. Keep the old one read-only. Fix what surfaces — it will be small and specific.

Then everything. Cut the rest over on a Tuesday. Keep the old system readable for a month. Cancel it after you have gone one full month-end without opening it.

Two weeks, mostly in the background, and the only genuinely tense morning is the one you rehearsed twice.

PrivateMile imports customers and drivers from CSV, connects to Shopify, WooCommerce, Wix, Ecwid, BigCommerce and Zapier by webhook, and includes onboarding and migration help on every plan — with a 15-day trial that is long enough to do the rehearsal week properly before you pay anything.