Every operator who has ever migrated off Limo Anywhere has the same two thoughts on day one: this will take three months and we're going to lose bookings during cutover. Both are avoidable. The teams who lose bookings during migration lose them because they skipped the parallel-run phase. The teams who take three months do it because they tried to migrate everything at once instead of picking a single lane and finishing it.
Below is a 30-day migration playbook built from the actual migrations we've run — including moving a seven-brand transportation portfolio off legacy WordPress and Limo-Anywhere-shaped stacks onto a shared static ops backbone with over 528,000 pages. The same pattern works whether you're a 10-vehicle single-brand operator or a mid-market multi-brand roll-up. Only the volume changes.
Before you start: the pre-migration audit
Do not begin migration until you have written answers to all of the following. If any answer is "I don't know," find out first. Every one of them will bite you mid-migration otherwise.
- What's the earliest date you can cancel Limo Anywhere without penalty? (Auto-renewal clauses trap operators every year.)
- What does the data-export deliverable look like? CSV of what tables, in what format, with what fields?
- Do you have API access to your existing data, or are you dependent on the vendor's export?
- How many active reservations are booked in the future? (These are your parallel-run scope.)
- How many active customer records with saved payment methods? Payment tokenization does not port between processors — plan for re-collection or a card-vault migration.
- What integrations are live? QuickBooks, SMS, Google, review platforms, dispatch overlays. Each one needs a re-wire plan.
- Which staff are the deep users of the current platform? They own the training risk.
- What is the actual booking volume per day (weekday vs weekend)? This scopes your parallel-run capacity.
- What season are you in? Migrating during peak (prom, wedding season, holiday) is a mistake most operators regret. If you can wait for shoulder season, wait.
The 30-day timeline
Here's the shape. Each phase overlaps slightly with the next; nothing is strictly sequential.
| Day | Phase | Owner | Deliverable |
|---|---|---|---|
| -14 to 0 | Pre-migration audit | Ops lead | Audit doc, cancel-notice timing, integration inventory |
| 1-5 | Data export + import | Ops + vendor | Customers, vehicles, saved bookings, packages, rate tables all in new system |
| 3-10 | Configuration | Ops + vendor | Pricing engine, cancellation policies, add-ons, brand customization |
| 8-15 | Integrations | Vendor + ops | Payment processor, QB, SMS, Google, website widget |
| 10-20 | Parallel run (shadow mode) | Full team | Every quote entered in both systems; daily comparison logs |
| 18-25 | Partial cutover | Ops lead | 20-30% of new bookings routed entirely through new system |
| 25-28 | Full cutover | Ops lead | 100% of new bookings on new system; legacy platform in read-only |
| 28-30 | Post-mortem | Full team | Written retrospective; carry-forward fix list; kill legacy contract |
Phase 1: data export (days 1-5)
The single most important sentence in the migration playbook: data-hostage clauses exist and you will discover them under time pressure. Every vendor tells you that data export is easy. Very few actually deliver a clean, complete, machine-readable export in a timeframe that doesn't blow your migration schedule.
What to export, in priority order:
- Customer records. Contact info, source, notes, tags, historical spend. This is your business.
- Future-dated reservations. Anything with a trip date on or after your cutover. These have to move first.
- Vehicles + drivers. Fleet config, driver assignments, licenses.
- Rate tables + packages. Every variant. Every seasonal override. Every add-on.
- Historical trip data. Last 12-24 months. Nice-to-have but not blocking.
- Reviews, ratings, testimonials. Often skipped, always regretted later.
- Financial records. Invoices, deposits, refunds. QuickBooks handles the accounting truth; your reservation platform just needs enough context for customer service to answer past-trip questions.
What you probably won't get cleanly, and what to plan for:
- Saved payment tokens. These are locked to the payment processor. Even if you keep the same processor, moving accounts often means re-collecting. Plan for a customer email campaign explaining why.
- Custom-field data. If your team relied on 15 custom fields, mapping them to the new schema is manual work.
- Attachments. Signed contracts, guest waivers, itinerary PDFs. Often only exportable one-by-one.
Phase 2: configuration (days 3-10)
The temptation is to reproduce Limo Anywhere's configuration exactly in the new system. Resist. Every migration is also a rare chance to fix the config-drift accumulated over years. Ask: "which of these 47 rate variants are we actually using in the last six months?" You will find at least 30% of your config is dead.
Configure in this order:
- Fleet (vehicles + capacities).
- Base rate tables (per vehicle class).
- Package tiers (4-hour minimum, 6-hour, all-night, etc.).
- Seasonal / day-of-week / blackout overrides.
- Add-ons.
- Cancellation and refund policies.
- Deposit + auto-charge-balance rules.
- Notification templates (email + SMS).
- Customer-facing widget branding.
Phase 3: integrations (days 8-15)
Every integration is its own mini-project. The order matters. Get payment processor working first — nothing else matters if you can't take money. Then QuickBooks (or whatever you use for accounting truth). Then SMS. Then Google/review platforms. Then the website widget.
The website widget deserves its own subsection because operators consistently underestimate it. If your existing site has SEO equity built on a legacy widget URL structure, the naive cutover breaks that equity. Plan for URL redirects. Plan for maintaining any deep-linked booking URLs (email campaigns, paid ads, partner integrations). Plan for the temporary hit while search engines re-crawl.
Phase 4: parallel run in shadow mode (days 10-20)
This is where migrations succeed or fail. For 7-10 days, every new inbound quote gets entered in both systems. Your team is doing double the data-entry — this is the pain you cannot skip. In exchange, you catch every configuration error, every workflow mismatch, every training gap, before customers see it.
Daily standup during shadow mode: what didn't match? What did the new system do worse? What did it do better? Log every friction point in writing. By the end of shadow mode you should have a written punch list of maybe 15-40 issues, most of them small.
Phase 5: partial cutover (days 18-25)
Route 20-30% of new bookings entirely through the new system. Pick the segment intentionally — some operators start with a single brand, some with a single vehicle class, some with a single service line (only wedding shuttles, only prom). The point is to have real customer-facing production traffic on the new system while you still have the old system as a backstop.
Watch for: quote-to-book conversion rate deltas, staff-time-per-quote deltas, customer complaints, dispatch-day smoothness. If everything holds, proceed. If any metric degrades meaningfully, pause and diagnose. Do not move to full cutover until the partial cohort is stable.
Phase 6: full cutover (days 25-28)
The all-in day. Legacy platform goes read-only. All inbound bookings on the new system. All future-dated reservations that were parked on the legacy system get pushed through their trip date and either completed there or transferred (depending on your comfort). Any remaining historical data stays accessible for customer-service lookups but nothing new gets entered.
Cutover day checklist:
- Payment processor live and taking real transactions.
- All active bookings visible in the new dispatch view.
- All staff logged in and working from the new system.
- Legacy platform locked to read-only for at least 90 days (for lookups).
- Website widget swapped to new endpoint. Old URLs 301-redirected.
- Support number, email autoresponder, and Google Business Profile updated if needed.
- Customer email sent to your top 200 customers explaining any experience changes.
- On-call rotation confirmed for the first 48 hours post-cutover.
Phase 7: post-mortem (days 28-30)
Written retrospective with the full team. What worked? What didn't? What decisions would you re-make? The output is a fix-list you'll work down over the following 30-60 days as small punch-list items.
Also on this day: cancel the legacy contract in writing. Auto-renewal is how vendors extract another year of revenue from operators who thought they were done paying. Send the notice, get the confirmation.
Common pitfalls
Contract lock-in and auto-renewal
The most common surprise: you planned to cancel Limo Anywhere on day 30 and discover the auto-renewal window closed on day -60. Now you're paying two vendors for six-to-eighteen months. Do the pre-migration audit properly. Read the contract language on notice windows.
Data-hostage clauses
Some contracts stipulate that data export requires 30-90 days notice and comes as a static one-time snapshot. If your migration takes 30 days and you request the export on day 1, the snapshot is stale by cutover. Ask for a second export at day 25.
Integration break-glass
The QuickBooks integration you assumed was standard often has custom mappings built by a consultant three years ago. When you re-wire it in the new system, some categories will be miscoded. Budget a week of post-cutover accounting reconciliation.
Missing edge-case configuration
Every operator has "the one weird rule" — the customer who always gets a 10% discount, the vehicle that can't go into a specific county after 11pm, the driver who only works Tuesdays. Undocumented rules do not migrate. Interview your longest-tenured dispatcher during phase 1.
Payment processor re-collection resistance
Customers hate re-entering payment info. If your migration includes a processor change, this is real churn risk. Send a warm, well-designed re-collection email — not a system-generated one. Explain why.
Realistic timelines by complexity
| Scenario | Realistic timeline | Notes |
|---|---|---|
| Single brand, 5-15 vehicles, no affiliate | 30 days | The clean case. Playbook above works. |
| Single brand, 25-50 vehicles, moderate affiliate | 45-60 days | More integrations, larger training footprint, affiliate handoff logic to rebuild. |
| Multi-brand, 50+ vehicles | 60-90 days | Do one brand at a time. Prove the pattern, then repeat. |
| Enterprise 100+ vehicles, heavy TMC/affiliate | 90-120 days | Real project management overhead. Enterprise vendor support required. |
What to migrate first when you can't migrate everything
If you're multi-brand or multi-line, do not try to migrate everything at once. Pick a single lane and finish it. Options in order of least-risk:
- A single service line. E.g., only wedding shuttles. Low volume, forgiving customers, contained blast radius.
- A single brand or DBA. If you have a smaller secondary brand, prove the migration there before touching the flagship.
- A single geography. One market, especially a lower-volume one, before rolling out nationally.
- The whole book of business. Only after two of the above have run successfully.
Case study: 7-brand transportation portfolio migration
We migrated our own seven-brand transportation portfolio off legacy WordPress and Limo-Anywhere-shaped stacks onto a shared static ops backbone. The scope: seven consumer-facing brands, over 528,000 pages combined, roughly 40,000 city variants, thousands of active customers with saved payment methods, and a live production booking flow that could not go dark.
The pattern that worked:
- One brand at a time. We migrated the smallest brand first (roughly 4-week migration), proved the pattern, then did the second brand, then the third, and so on. Total portfolio migration took roughly six months. Trying to do them concurrently would have doubled the timeline through cross-contamination of debugging cycles.
- Static site rebuild in parallel. We rebuilt each brand's consumer-facing site on a static Hugo stack during the same migration window, which eliminated WordPress plugin churn and made SEO recovery faster. If you're migrating your platform, migrating your website hosting at the same window is more efficient than two separate projects.
- Parallel run for 10-14 days per brand. Zero booking loss across all seven migrations. The overhead of double-entry during shadow mode is the price.
- Shared ops stack, distinct brand faces. One CRM, one dispatch desk, one vendor portal, seven public brands. This is the architecture that pays back over years.
- Post-migration SEO recovery. Every brand's organic traffic dipped 15-30% for 2-4 weeks post-cutover, then recovered and exceeded prior baseline within 60-90 days. Expect this shape. Plan for it. Do not panic-revert.
Full details on the multi-brand ops architecture are on our case studies page.
A 30-day migration is not "30 days of work." It's 30 days of calendar time with careful sequencing. Most of the work is preparation. Most of the risk is in the two days on either side of cutover.
Honest closing
Migration is a project management problem more than a software problem. The vendors who do it well are the vendors who show up with a real playbook, dedicated resources for the first 30 days, and enough humility to catch their own mistakes during parallel run.
If you're evaluating a migration off Limo Anywhere and want to see what a real white-glove migration looks like, our 30-day pilot includes data import, config-mirror, and parallel-run tooling. No credit card. See our pricing for what comes after.