Migration protocol
Move off legacy dispatch —without dropping a booking
The full 14-day protocol we use, in public and in detail. Most of it is vendor-neutral and applies whoever you move to — including away from us.
Most fleets that stay on software they have outgrown are not staying because the software is good. They are staying because the alternative is a migration, and a migration sounds like the Friday night your dispatcher cannot find a job. That fear is rational. A dropped booking is not one lost fare — it is a lost regular, and a driver who stops trusting the screen.
So the protocol below is designed around a single principle: nothing depends on the new system until it has already been proven against your real jobs, on your own fleet. That is what the parallel week is for, and it is the step every failed migration skips.
This page is not gated and not a brochure. Most of it applies whichever platform you move to. If you read it and decide to stay where you are, it has still done its job.
Days 1–3
Audit, export, reconcile
The whole migration is decided here. Every project that runs late runs late because of something that should have been found in week one.
The step operators skip most often is reconciliation. It is tempting to import an export and move on, but a customer list that lands 4% short does not announce itself — it announces itself later, at the worst possible time, as a regular whose saved address has vanished. Count before, count after, and do not proceed until the numbers agree.
Days 4–10
Run both systems at once
The safety mechanism. For a week, the new platform has to earn the right to be trusted while nothing depends on it.
Shadow-dispatching is the part worth understanding properly. The new system allocates every job in the background while your existing platform stays authoritative. Nobody's booking rides on it. At the end of each day you have a list of the jobs where the two systems disagreed — and each disagreement is either a rule you need to fix or a genuine improvement you can measure before you commit to it.
Move account customers across early in this window. Corporate billing is where migration errors are most expensive, because they surface at month end, in front of the client, on an invoice.
Days 11–14
Cut over shift by shift
Overnight first, lowest volume first, rollback still switched on.
Keep the old platform licensed through cutover. A rollback plan that requires re-signing a contract is not a rollback plan. The cost of one extra month of overlapping licence is trivial against the cost of having no way back on the night you need one.
And define clean before you start, in writing, with your dispatchers in the room. If nobody agreed what a good day looks like, everybody will argue about it on day twelve.
What actually goes wrong
The six failures, and where each one gets caught
Every item here is a real way migrations fail. The left column is where this protocol catches it; the right is when you find out otherwise.
| Feature | TaxiDex | Without a protocol |
|---|---|---|
| Data export refused or delayed | Request in writing citing your data-ownership clause; escalate before notice expires | Discovered with two weeks left |
| Fares differ after import | Price 20 historical jobs through both systems in days 1–3 | Found by a customer complaint |
| Account customers billed twice | Move corporate accounts early in the parallel window | Found at month-end invoicing |
| Drivers resist the new app | Comms in the parallel window; both apps live so nothing is forced | Drivers log off on cutover night |
| Cutover goes wrong | Old system still licensed and running as rollback | No way back |
| Historical data lost | Final archive exported before the licence lapses | Gone with the contract |
If you are moving off a named system
The protocol is the same, but the export step differs by platform. We have written up the specifics for the systems fleets most often leave: Autocab, iCabbi and Cordic. If you are on something else, the audit questions in days 1–3 are the ones that matter regardless.
You can also see what running on TaxiDex costs — per active driver, with migration included in the rate.
Questions
The ones operators actually ask
Is 14 days realistic for my fleet?
It is the working timeline for a single-depot fleet with clean data and a nominated owner. Two things stretch it, and they are worth being honest about: messy or incomplete data from the outgoing system, and multi-depot operations with different tariffs per depot. Larger fleets usually run a longer parallel window rather than a longer setup — the extra days go into days 4–10, where they buy the most safety. If your data is in poor shape we would rather tell you in week one than miss a date.
Will we lose bookings during the switch?
The protocol is built specifically so the answer is no. Both systems run live in parallel for a week before anything is cut over, the new system shadow-dispatches without being authoritative, and the cutover happens shift by shift with the old platform still licensed as a rollback. Nothing depends on the new system until it has already been proven against real jobs on your own fleet.
Has TaxiDex actually done this?
Honestly: TaxiDex is a young product, and we have not yet taken a large legacy fleet through all fourteen days. This protocol is how we run a migration, drawn from how these projects succeed and fail generally, not a case study we are dressing up as one. When we have a fleet that has been through it and is willing to be named, we will publish their numbers here instead of this paragraph. We would rather be believed later than doubted now.
Who owns my data?
You do — check your existing contract for the clause, because it is the leverage that gets you a clean export. On TaxiDex your data stays exportable for as long as you are a customer and on the way out: customers, drivers, vehicles, tariffs and trip history, in a usable format, on request. A platform that makes leaving difficult is telling you something about how it expects to keep you.
Can we run the parallel window for longer than a week?
Yes, and for a large or multi-depot fleet you probably should. The parallel window is the part of the protocol that removes risk, so extending it is the cheapest insurance available. What we would not recommend is shortening it — every migration that goes badly wrong shortens this step first.
What does migration cost?
Data migration is included in the per-driver rate — customers, drivers, vehicles, tariffs and trip history. There is a one-time setup covering app-store deployment under your brand, configuration of your zones, vehicle classes and fares, and dispatcher training; it is scoped to your fleet and quoted up front on your demo call, so there is nothing to discover later.
Walk through it with your own data
Bring your fleet size, your current platform and your contract end date. We will tell you on the call whether 14 days is realistic for you — including if it is not.