Switching Off RMS or NewBook Without Losing Your Forward Bookings

Switching booking systems sounds scary because of all the forward bookings already sitting in your old system. The good news: for most parks, the simplest approach is to leave those bookings where they are and only direct new ones into the new system.

This post is the playbook for that. The parallel-running approach, the few cases where you actually need to do more, and what the switch looks like in practice. It uses RMS and NewBook as the most common starting points, but the approach works for any existing system.

The Simplest Playbook: Parallel Running

Forward bookings already in your old system stay there. They keep their confirmation numbers, their saved payment details, and the email flow they're already on. Nothing about those bookings needs to change.

What changes is where new bookings land. You re-point your "Book Now" link or embed to the new system, and from that moment on, everything new flows through it.

The old system then naturally drains as those existing forward bookings happen. When the last one has departed, you close the old account and you're done.

What You Do on Switch Day

The actual switch is a short list:

1. Build out your sites, categories, and pricing in the new system - while the old one is still live.
2. Connect your payment gateway in the new system.
3. Walk through the booking flow yourself end-to-end so you know what guests will see.
4. Re-point your "Book Now" links and any embedded widget on your website to the new system.
5. Update your Google Business Profile and any directory listings so their booking links go to the new URL too.
6. Stop accepting new bookings through the old system, but leave the existing ones running.

None of those steps are heavy lifting on their own.

What Stays the Same

Everything about your existing forward bookings continues exactly as it was:

• Confirmation emails for those bookings still come from the old system.
• Reference numbers don't change.
• Saved card details stay where they are.
• Already-booked guests don't need to know anything has happened. From their perspective, nothing has.

This is what makes parallel running so much safer than a forced migration: there's no data movement to go wrong.

The Two-Dashboard Period

The trade-off is that until the old system drains, you're checking two dashboards for arrivals. For most parks that period is somewhere between a few months and a year, depending on how far ahead your guests book.

A few things that make the period bearable:

• Pull a forward arrivals report from the old system, print it, and cross things off as they happen. You'll always know how much further the old system has to run.
• For modifications and cancellations to old-system bookings, handle them in the old system. Don't try to recreate the booking in the new one.
• To avoid overselling, block the affected sites in the new system for any dates that have an existing booking in the old one. As old bookings depart, free those dates up in the new system.

When Parallel Running Isn't Enough

A few cases where you'd want to actually migrate forward bookings into the new system:

1. The old system charges a high fixed monthly fee and the parallel period would cost more than the migration effort itself.
2. The old system is being shut down by the vendor and you don't have the option to keep it running.
3. You need a single, unified view of all bookings - for example, if you're running multiple parks and want consolidated reporting.

If any of those apply, the harder path is a CSV export from the old system and a manual import into the new one - typically a spreadsheet with columns for booking reference, guest name, contact, dates, site, total, and balance due. It's real work, but it's manageable for parks under a few hundred forward bookings.

Closing the Old Account Properly

Once the last forward booking has departed and the old system is empty:

• Export your historical data while you still have access. Bookings, guests, invoices - anything you'd want for tax or audit purposes (in Australia, that's typically seven years of records).
• Save the export somewhere safe and accessible.
• Then cancel the account.

Don't cancel before you've exported - most vendors take the data offline as soon as the account closes, and there's usually no way to retrieve it after that.

What This Looks Like With Camper BMS

Camper BMS is built for the parallel-running model. Usage-based pricing means you only pay when invoices are paid - so in the early weeks when most of your bookings still live in the old system, your Camper BMS costs reflect that.

Guest payments stay yours from day one - Camper BMS isn't in the payment flow, so funds settle directly to your merchant account whichever system the booking came through.