Migrating a Live Car Rental Platform Off Lovable + Booqable Without Breaking Bookings

The first version of Amber Car Rental existed before I did — a Lovable prototype wired to Booqable for fleet and booking management. It worked well enough to take real bookings, which is exactly what made replacing it dangerous: there was live data and paying customers to not break.

Why move at all

A no-code prototype is a great way to validate that a rental business needs a booking system. It's a bad place to build the real thing once you need custom availability logic, an admin workflow tailored to how this specific agency operates, and a backend you actually control instead of renting through a third party's API surface and pricing tiers.

The cutover, not the rewrite

• Modeled the new schema in Supabase first, mapping every field Booqable exposed to its Postgres equivalent — no silent data loss on migration.
• Ran the new booking flow in parallel against a staging copy of live data before touching production traffic.
• Migrated fleet and historical booking records in one scripted, re-runnable pass — re-runnable mattered, because the first dry run surfaced date-format mismatches that would have corrupted availability windows.
• Cut over during the platform's lowest-traffic window, with the old system left read-only as a rollback path for the first week rather than deleted immediately.

What actually made this safe

Not moving fast — moving in a sequence where every step was individually reversible. The riskiest part of any live migration isn't the code, it's not having a way back if the data doesn't match what you expected. Keeping the old system alive and read-only for a week cost nothing and would have cost everything not to have, if week one had gone wrong.