Migrating a taxi fleet between dispatch platforms is the single highest-stakes platform decision an operator makes outside the original platform choice. A botched migration costs missed bookings, customer churn, dispatcher distrust, and potentially regulatory exposure if compliance reporting breaks during the cutover window. This checklist covers every record class, integration, and operational workflow to verify before cutting over — used by the TaxiCloud migration team across 60+ migrations in 2024-2026 from iCabbi, Autocab, Cordic, Gazoop, and TaxiCaller.
1. Data records to verify imported clean (12 items)
Drivers — every active driver record, with PHV/SPSV/Hackney licence number, expiry date, vehicle assignment, performance rating history, and bank details for settlement. Vehicles — every active vehicle record, with PHV plate number, MOT expiry, insurance expiry, ULEZ/CAZ-compliance status, and inspection history. Customer accounts — every account record, with contact details, saved card metadata (where stored on the legacy platform's tokenised reference), booking history (24-month minimum), and PO/expense-code metadata for corporate accounts.
Pricing rules — every fare class, surcharge rule, geofence-based pricing, airport tariff, and time-of-day surcharge. Coverage zones — every operating zone, exclusion zone, and CAZ/ULEZ-aware sub-zone. Corporate accounts — every account, with PO-level booking notes, expense-code dictionary, monthly statement preferences, and named account contacts. Booker channels — every third-party booker channel integration (Lyft, Uber feeders, hotel concierge integrations, hospital trip-management integrations).
2. Integrations to verify functional (10 items)
Stripe — payment intent flow, saved-card token migration, webhook handling, refund flow, settlement export. PayPal — billing flow, refund flow if used. Twilio — SMS gateway, verified-sender numbers, message template parity. FCM (Firebase Cloud Messaging) — Android driver-app push delivery, registration token migration. APNs (Apple Push Notification Service) — iOS driver-app and customer-app push delivery. Google Maps — address autocomplete, distance-matrix API, traffic-aware ETA. reCAPTCHA — booking-widget bot prevention.
Reverb / WebSocket — dispatch-board live-update channels, driver-app live-update channels. Plausible Analytics or equivalent — marketing-website event tracking. Accounting integrations — Xero, QuickBooks, Sage, FreeAgent (whichever the operator uses for monthly settlement). Council-licensing report exports — verify the regulator-portal upload flow works end-to-end.
3. Operational workflows to verify (10 items)
Booking creation flow — web widget, customer app, phone-call entry, third-party booker channel. Booking modification — passenger-side and dispatcher-side. Booking cancellation — passenger-cancel, dispatcher-cancel, no-show flag. Dispatch assignment — manual drag-to-assign, AI Copilot recommendation flow, auto-assignment rules. Driver offer-accept flow — push notification delivery, driver app accept/decline UX, escalation if no driver accepts within configured timeout.
Live trip tracking — customer-app share-trip, dispatcher-board live position, driver-app navigation. Trip completion — fare calculation, payment processing, settlement marking, customer SMS receipt, driver app summary. Daily settlement — driver settlement run, fleet operator monthly settlement report. Compliance reporting — TfL operator monthly return for London, council quarterly returns for non-London UK, NTA SPSV quarterly returns for Ireland. Dispatcher escalations — incident reporting, complaint handling, regulator-disclosure workflow.
4. The parallel-run weekend
The parallel-run weekend is where every checklist item gets stress-tested against live data. A small driver subset (typically 10-20% of fleet, often the airport or executive segment) runs on the new platform alongside the legacy platform. Dispatchers train against real bookings; the migration team monitors side-by-side. The decision to cut over is operator-led — not vendor-led. We have had operators extend the parallel-run window from a planned weekend to a full week before cutover; that is the correct call when the data tells you to.
Most TaxiCloud cutovers complete on a Saturday morning before Sunday airport-rush traffic. The cutover sequence: confirm Friday end-of-day on legacy platform, run final delta-import overnight, switch DNS / customer-facing booking links Saturday 06:00, dispatchers run the live board on TaxiCloud from Saturday 07:00, legacy platform held in read-only mode for 90 days for any rollback contingency. We have not had an operator request rollback past the 30-day post-cutover window.
About the author
Regan Marshall
Lead, Operator Strategy, TaxiCloud
Regan Marshall works with UK and Ireland fleet operators on dispatch strategy, AI Copilot adoption, and migration planning. Reach out at regan@taxicloud.ai.