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 provider 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 exporting your data from the old system as a spreadsheet file (CSV) and manually importing it into the new one - typically a spreadsheet with columns for booking reference, guest name, contact info, dates, site number and total. 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:

• Bookings, guests, invoices - anything you might need to look back on. Record-keeping periods vary by record type, so check your obligations with your accountant or the ATO, and grab everything while you still have access.
• 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. The usage-based platform fee (no subscriptions, no minimums) means in the early weeks - when most of your bookings still live in the old system - your Camper BMS fees stay light.

Your first 30 days are free, too. Import what you want, set up your sites and rates, and find your feet without paying for any of it - any bookings or leases you bring in or create in those first 30 days are never billed. Per-booking and per-lease fees only start after that.

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

If you're on an RMS or NewBook subscription, the parallel period is where usage-based pricing shows its value. In the early weeks, when most bookings still sit in the old system, your Camper BMS fees scale down to match your new booking volume. You're not paying a fixed platform fee for a system still being broken in.