Print-ready playbook · 9 days

iCabbi → TaxiCloud migration playbook.

Day-by-day cutover schedule, dispatcher training checklist, parallel-run script, and rollback plan. Designed for the operations lead to print and pin to the wall on Day 1.

Use this page

Open File → Print (Ctrl/Cmd+P) to generate a clean A4 PDF of the full iCabbi → TaxiCloud playbook. Navigation, footer, and backgrounds drop out in print. Or follow it on-screen — every section is print-safe.

Day-by-day cutover schedule

14 business days from kickoff to iCabbi cutover.

  1. Day 1

    Discovery + signed migration plan

    90-minute discovery with operations lead and senior dispatcher. Snapshot of current iCabbi tenant: vehicle count, driver count, integrations in use (Stripe / PayPal / Twilio / FCM / Google Maps), pricing rule complexity, corporate accounts. Migration plan signed by both sides — includes integration test list and rollback criteria.

    Owner: Operations lead + TaxiCloud onboarding

  2. Day 2

    Tenant provisioning + integration credentials

    TaxiCloud tenant provisioned. Subdomain, branding, councils, and reporting profile applied. Operator supplies integration credentials (Stripe restricted key, Twilio Account SID, FCM service account, Google Maps API key). Webhooks pointed at staging.

    Owner: TaxiCloud onboarding

  3. Day 3-4

    iCabbi export + clean import

    Drivers, vehicles, customers, pricing rules, coverage zones, corporate accounts, and 24-month historic bookings exported from iCabbi and imported into TaxiCloud staging. Data quality report generated — missing fields, duplicate accounts, expired licences flagged for the operator to triage.

    Owner: TaxiCloud data team

  4. Day 5-6

    Integration testing

    Full integration suite executed: card payment, account-pay invoice, SMS booking confirmation, FCM driver push, route ETA, council report export. Every test logged with screenshots. Cutover gate: 100% pass.

    Owner: TaxiCloud QA + operator dispatcher

  5. Day 7-8

    Dispatcher training

    Two 90-minute training sessions for dispatchers, plus async video library. Hands-on with the operator's actual tenant data — not generic demo data. Driver app demo session with two pilot drivers chosen by the operator.

    Owner: TaxiCloud Customer Success

  6. Day 9-10

    Pilot driver subset (parallel run)

    10–20% of fleet runs on TaxiCloud, the rest stays on iCabbi. Typically the airport or executive segment — known drivers, predictable shifts. Dispatchers run side-by-side consoles. Daily 15-minute standup to triage any issues.

    Owner: Operator dispatcher + TaxiCloud Customer Success

  7. Day 11-12

    Parallel-run weekend

    Full fleet runs on TaxiCloud Friday 06:00 through Sunday 23:00 with iCabbi kept hot as a fallback. TaxiCloud Customer Success on-call. Operator decides Monday go/no-go based on the live weekend data, not slideware.

    Owner: Operator decision

  8. Day 13

    Cutover

    Hard cutover. DNS for booking widget and customer apps repointed. iCabbi tenant set read-only for compliance. All new bookings flow through TaxiCloud. Dispatcher consoles closed on iCabbi.

    Owner: TaxiCloud Customer Success + operator IT

  9. Day 14

    Post-cutover audit + handoff

    First 24-hour post-cutover report: booking volume, on-time pickup rate, dispatcher action counts, AI Copilot suggestion acceptance rate. Operator signs handoff. 30-day rollback window opens. Customer Success transitions to weekly check-ins.

    Owner: TaxiCloud Customer Success

Dispatcher training checklist

Print this. Tick it off as you train.

Every iCabbi dispatcher should complete this checklist before pilot weekend.

  • Dispatcher console walkthrough — bookings, dispatch, zones, driver tracker
  • AI Copilot interaction — accept, reject, override, ask-why
  • Booking creation — phone, web widget, account-pay, future-time
  • Driver assignment — manual, auto, Copilot-suggested
  • Pricing rule editor — surge, off-peak, account-rate, airport
  • Coverage zones — draw, edit, assign driver pools
  • Council reporting — generate, export, attach evidence
  • Customer app demo — book, track, rate, account history
  • Driver app demo — go online, accept job, navigate, end trip
  • Incident handling — refund, dispute, driver no-show, customer complaint

Parallel-run weekend script

Friday 06:00 → Sunday 23:00 — verbatim runbook.

  1. 01.Friday 06:00 — All dispatchers open the TaxiCloud console; iCabbi consoles minimized to a secondary monitor as fallback only.
  2. 02.Friday 06:00–09:00 — Morning peak observed live. TaxiCloud Customer Success on-call. AI Copilot suggestion acceptance rate logged every 30 minutes.
  3. 03.Friday 09:00 — First sync. Compare booking-to-pickup time vs the prior Friday on the legacy platform.
  4. 04.Friday 17:00–20:00 — Evening peak. Account-pay traffic monitored; corporate-account invoices verified against the legacy tenant.
  5. 05.Saturday — Night-time-economy operations. Surge pricing rules and dispute handling exercised under live load.
  6. 06.Sunday — Lower-volume validation. Reporting and exports run to confirm parity with the legacy tenant.
  7. 07.Sunday 23:00 — Operator and TaxiCloud Customer Success make a joint go/no-go call for the Monday cutover.

Rollback plan

How to roll back to iCabbi if you need to.

  • Days 1–30 post-cutover: full rollback supported. iCabbi tenant is held in read-only standby; reactivation takes under 4 hours including DNS and integration repoint.
  • Days 31–90: iCabbi tenant kept read-only for compliance. Rollback is technically possible but requires a re-import of the 30-day delta — operators are advised to commit by day 30.
  • Day 91+: rollback path formally closes. To date, no operator has requested rollback past the 30-day window.
  • Rollback decision authority sits with the operator. TaxiCloud Customer Success provides the data and a recommendation; the operator signs off.

Playbook FAQ

iCabbi playbook — questions from operations leads.

Can I print this iCabbi migration playbook?
Yes — this page is designed for print. Use your browser's File → Print. Navigation, footer, and call-to-action banners are hidden in print; the playbook body fills the page with high-contrast type.
Who owns each step of a iCabbi → TaxiCloud migration?
Each day in the schedule has a named owner — operations lead, TaxiCloud onboarding, TaxiCloud Customer Success, or a joint pairing. Day-1 sign-off pins the named individuals on both sides for the entire two-week window.
What if the parallel-run weekend uncovers a regression?
Cutover is paused. The regression is logged, owners are assigned, and the migration window extends by however long it takes to close the issue — typically 2–5 business days. The signed plan from Day 1 makes this a no-fault, scheduled outcome.
How long does the iCabbi tenant stay available?
Read-only for 90 days post-cutover. This covers regulatory inspection, insurance claim windows, and any late corporate-account disputes that reference legacy booking IDs.