Switching from per-trip software

Switching dispatch software takes about a month for a 10 to 30 car operation, and the two weeks that matter are the parallel run. The export takes an afternoon. The rate rebuild takes a day or two. What takes time is convincing yourself, with real trips, that nothing falls through before you turn the old system off.

This guide is for an operator leaving Limo Anywhere, Moovs or a spreadsheet. One thing to know up front: liverybook does not have self-serve signup today. A tenant is created by liverybook, so the migration starts with a demo, and the steps below assume that call has happened and you have a login.

Audit what you actually use

Before exporting anything, write down what the office touches every day. Most operators use a fraction of their current system: the reservation form, the dispatch grid, a customer list, a handful of reports, and a monthly invoice run. The rest was configured once in 2019 and never opened again.

Walk the day with the dispatcher. Which statuses do they actually set? Which columns do they look at? Which reports does the bookkeeper pull, and what does she do with them afterwards? The answers decide what has to work on day one and what can wait.

Be honest about two gaps in liverybook as of today. There is no driver mobile app yet, so your own drivers will not update their status from a phone; the dispatcher sets it from the run board. And there is no SMS. If your drivers currently get trip sheets by text from the old system, you need a plan for that before cutover (email, a group chat, or printed sheets). Both items are on the roadmap, but you should migrate on what is built. The comparison pages at /compare/limo-anywhere and /compare/moovs list these differences plainly.

Export customers, accounts, rates and affiliates

Pull four exports from the old system: customers (passengers and bookers), corporate accounts with their billing terms, your rate tables, and your affiliate list. Limo Anywhere and Moovs both export to CSV from their admin screens. A spreadsheet operator already has the files, usually in more tabs than expected.

Clean each file before it goes anywhere. Merge duplicate customers. Mark which corporate accounts are net terms and which are direct pay. Delete rates for vehicle classes you no longer run. The old system tolerated mess because the people using it knew where it was; a new system will not know.

Do not export trip history yet. Open bookings for the next 60 days need to move; the last five years of completed trips do not, at least not on day one. Keep the old system in read-only mode for historical lookups for a few months after cutover.

Map your statuses to liverybook's

liverybook separates the order from the vehicle movement. A booking is the order; each leg is a trip leg. There are 7 booking statuses (draft, confirmed, in_progress, completed, cancelled, late_cancelled, no_show) and 11 leg statuses (unassigned, assigned, driver_notified, en_route_pickup, arrived_pickup, passenger_on_board, arrived_dropoff, completed, cancelled, late_cancelled, no_show). Only 25 status transitions are allowed, and the service layer enforces them.

Most legacy systems have a flatter list. The typical per-trip platform's handful of trip statuses (unassigned, assigned, on the way, arrived, passenger in car, done) map one-to-one onto the leg statuses. Moovs is similar with fewer steps. A spreadsheet usually has a colour.

Write the mapping down in a table and give it to the dispatcher. The two that need thought are late cancel and no-show. In liverybook these are distinct statuses with fee rules attached, and moving a booking into either one creates the invoice line automatically. If your old system recorded a late cancel as "cancelled" with a note, decide now whether you want the fee to be automatic. Most operators do.

Rebuild your rate lists

Do not import rates. Rebuild them. Rates are where old systems carry the most dead weight, and a clean rebuild takes a day for a typical fleet.

In liverybook a rate list has one rate per vehicle class, with the base rate and the late-cancel and no-show rules on each rate. Rate groups hold rate lists with a seasonal schedule by month. If your holiday pricing was a sticky note on the dispatcher's monitor, this is where it becomes a schedule.

Start with the rate list your office uses for walk-up and web bookings, because that one feeds the customer portal. Then build the lists for your top corporate accounts. Accounts that get a contracted rate below the public list are a billing account with its own list. The guide on how to price a limo trip covers the method if you want to review rates while you rebuild them.

Bring affiliates over with their insurance dates

Your affiliate list is more than names and phone numbers. For each affiliate you need the certificate of insurance expiry, the tier you have assigned them (standard, preferred or strategic in liverybook), and whether they are currently approved to receive work.

liverybook computes a compliance status for each affiliate from those dates (compliant, expiring soon, expired, pending, blocked) and warns at 60, 30 and 7 days before expiry. That only works if the dates go in. An affiliate record with no insurance date sits at pending, and the compliance gate will not let a farm-out go to them until the record is approved.

Load the affiliate contacts and the affiliate driver roster too, with licence details. Affiliate drivers get a tokenised link for each farmed trip and can set statuses from en route to completed, so a well-loaded roster means your overflow work gets live status updates on the run board even before the driver app ships.

Run parallel for two weeks

Enter every new booking in both systems for two weeks. Yes, double entry. It is the only test that catches the things nobody thought to check.

Dispatch from the old system in week one and from liverybook in week two, but keep both populated throughout. At the end of each day compare the two manifests. Every difference is either a data entry error (fine, that is why you are running parallel) or a gap in the mapping (fix it before Monday). Pay particular attention to multi-leg itineraries and round trips, to anything farmed out, and to any booking that was cancelled, because those are the paths where the two systems differ most.

Have the bookkeeper run the week-two invoices from liverybook and reconcile them against what the old system would have billed. Leg totals in liverybook are base plus gratuity plus tolls plus parking plus wait time plus extras minus discount, built from invoice lines as legs complete. If an account comes out different, the rate list is wrong, and it is better to learn that on a dozen invoices than on a month of them.

Cut over on a Monday

Pick a Monday with a normal week behind it and no event weekend ahead. On the Friday before, enter all remaining open bookings in liverybook, confirm the portal is live at your {slug}.liverybook.com address if you are using it, and send your drivers whatever replaces the old system's trip sheet.

On Monday morning the dispatcher opens the liverybook run board and nothing else. Keep the old system logged in on a second screen for a week, in read-only use, for lookups. Cancel the old subscription at the end of its billing cycle, not before; the overlap month is cheaper than discovering a missing export after the account is closed.

The money side of the switch is simple. liverybook is priced per office seat with no per-trip fee, so the bill does not move when your trip count does. Current seat prices are at /pricing, and the first step is still a demo, because that is where your tenant gets created.