Skip to content
← All posts

October 19, 20266 min read

Switching Car Rental Software With Active Bookings: A Cutover Checklist

Switching car rental software while renters hold bookings is a cutover, not an export. Move the records a spreadsheet can carry, such as vehicles and customers. Then settle everything else: each active and future booking, the calendar, card holds, payments, balances, agreements and renter documents. Keep the old system open until every open item has a destination, an owner and a checked number. These steps are our recommended practice, not universal rules, a tested migration service or a promise that anything moves automatically.

An open ledger, check cards and car keys outside a rental office.
AI-generated editorial illustration, not a customer location or product screenshot.

What moves, what do you rebuild, and what stays put?

  • Vehicles and customers: CSV import, if supported, limited to the fields the new system accepts. Check a sample, then duplicates and totals.
  • Active trips (car is out): finish in the old system, so mileage, fuel, charges and the deposit outcome stay where the trip started.
  • Future bookings: finish in the old system or re-create in the new one, decided per booking.
  • Availability: block every booking the new system does not hold, before it takes requests.
  • Card holds, saved cards, payments and balances: stay with the payment account where they started, unless a secure processor migration moves saved cards.
  • Agreements and renter documents: export one complete, readable copy per booking and archive it securely.
  • Reviews: depends on each platform. Do not assume they move; keep a copy where the terms allow.

Rentovation's switching page says vehicle and customer records can come in by CSV, subject to the supported fields and checks for each import tool, and that active bookings, calendar blocks, payments, balances, agreements and reviews need separate handling.

Why do card holds and saved cards need their own plan?

A deposit hold is an authorization on the renter's card, made through one payment account. It is not collected money, and it runs on a clock. According to Stripe's guide to holds, card payments are typically held for 7 days for online payments and 2 days for in-person Terminal payments, depending on the transaction and card network. Stripe also says an authorization that expires before capture is released. With any processor, settle each open hold in the account that made it: capture what the agreement allows or release it, and record the outcome.

Saved cards also sit with the processor, not in a spreadsheet. According to Stripe's migration guide, moving sensitive payment data needs a data migration request, handled in a secure, PCI-compliant way. Even then, ask whether your new software can use migrated cards. The safe plan is to expect renters to enter a card again. Never put card numbers or license images in a spreadsheet or an email.

How do you take stock before you switch?

Seven steps for switching rental software, with one ledger row for each booking.
Keep one ledger row for each active or future booking. Check each row before closing it. AI-generated editorial illustration, not a customer location or product screenshot.

The cutover runs in seven steps: take stock and freeze, build the ledger, test a sample import, block availability, archive documents, run both systems with a rollback plan, then close the old system.

  1. Pick a cutover time and name one owner for the switch.
  2. Export everything the old system offers. Keep the original files unchanged and work from copies.
  3. Find the furthest-out booking. The old system may need to stay open until bookings finishing there are done.
  4. Write down your counts: vehicles, customers, active trips, future bookings, open holds and open balances.
  5. Check what the old system does on a cancel. If it emails renters or refunds automatically, talk to the renter before you cancel anything there.

What goes in the cutover ledger?

Build one row per active or future booking at the cutover time, with an owner for each. This ledger is the switch; the imports are only part of it. These two rows are invented to show the format.

BookingCar and datesFinishes inMoney and holdAgreementBlock in new systemChecked
OLD-AEXAMPLE-A, starts soonOldPaid in old account; hold settled thereOld copy archivedDates blockedSecond person
OLD-BEXAMPLE-B, starts laterNewPart paid in old account, noted as credit; rest and new hold in new systemNew one sent, old copy archivedBooking re-createdSecond person
  • Finish active trips where they started, with the agreement the renter signed.
  • Bookings that start soon after cutover can finish in the old system too. Block those dates in the new system.
  • Bookings far enough out are re-created in the new system. Tell the renter what changes. Re-create first, confirm with the renter, then close the old record.
  • Money settles where it was taken. Never refund in one system and re-charge in the other without a note on the ledger row.
  • No row closes without a check by someone other than the person who entered it.

How do you import, block dates and archive?

Import a small sample first, for example three vehicles and five customers. Compare each record with the source, fix the mapping, then import the full lists. Check totals against your counts and list any skipped rows. Before real renters see the new site, run one full booking through payment, agreement and deposit hold in test mode or a test account. If you must use a real transaction, record it on the ledger and refund or release it.

Before the new site takes a request, every car must show every date already sold anywhere: old-system bookings, re-created bookings and marketplace trips. If the cars are also on Turo or another marketplace, keep blocks on every channel that can sell them.

Export each signed agreement and renter document in a readable format to access-controlled storage, never open shared folders, chats or public links. Keep them as long as your insurer, lawyer or local rules require.

When can you switch over and close the old system?

During the overlap, the old system finishes its bookings and the new one takes new ones. Before you switch, write down rollback triggers, such as renters unable to pay or a calendar mismatch you cannot explain, and which booking link goes back up. Do not move your domain or main booking link until the new site has completed a full test booking.

CheckGo when
Sample and countsFields match the source; totals match or each gap is explained
LedgerEvery active and future booking has a destination and an owner
AvailabilityEvery sold date is blocked on every channel that can sell the car
MoneyEvery open hold and balance has a planned outcome where it started
Test bookingOne full payment, agreement and hold flow worked
RollbackTriggers and the fallback booking link are written down

Close the old account only when no booking, hold or balance depends on it, every ledger row is checked, you no longer need its records, and a final export is archived next to the ledger.

Verifying renters covers the screening a new booking flow should handle. New bookings in Rentovation can include e-signed agreements and security deposit holds on the renter's card; a hold is an authorization, not collected revenue or insurance. This checklist is general operating guidance, not a record of a specific customer's migration, and not legal, tax or data-protection advice.

Ready to run bookings on your own site? Rentovation starts with a 14-day free trial, and you can cancel anytime. See Starter and Pro pricing for the current trial terms.

Common questions

Can I import active bookings from my old rental software?

Plan to handle them separately. Rentovation's switching page says vehicle and customer records can come in by CSV, while active bookings need separate handling. Finish each booking in the old system or re-create it in the new one, decided booking by booking.

What happens to deposit holds already on a renter's card?

A hold stays with the payment account that made it. Capture or release it there before the authorization runs out, and record the outcome on the booking.

Will renters' saved cards move to the new system?

Plan for renters to enter a card again. Saved cards stay with the old processor unless both processors support a secure migration and your new software can use the migrated cards.

When can I close my old rental software?

Only when no booking, hold or balance still depends on it, every ledger row is checked, you no longer need its records, and a final export is archived.

Sources