Based on public supplier documentation and editorial analysis, not hands-on testing. Confirm current plan features and commercial terms before buying.
Moving house is stressful enough. Now imagine doing it while still living there, with visitors arriving every morning expecting breakfast, and the post still going to the old address for a while.
That is a booking-system migration. Guests keep booking, deposits are already in the bank, and marketplaces keep sending reservations while you change the plumbing underneath. Done well, nobody notices. Done badly, a guest gets two different meeting points and a boat goes out with the wrong passenger list. This countdown takes you from the first inventory to the morning after, in the order the work actually needs to happen.
Weeks before: list everything you are moving
Start with an inventory. List future bookings, products, product options, customer contacts, outstanding voucher values, deposits, unpaid balances and channel references. Decide which history must stay searchable in the new system and which can live in a controlled archive. Give every category an owner and a rule for how long it is kept.
Then ask both suppliers the obvious questions: what does the old system export, and what does the new one import? FareHarbor says it transfers future reservations. Regiondo describes an onboarding manager importing existing bookings and connecting marketplace channels. Those statements justify asking for help with the move, but neither promises that every historical transaction or custom field will come across.[1][2]
Before the big move: test the awkward boxes first
Every house move has a few boxes that are hard to pack. In a migration they are the bookings with history. Build a permitted, securely handled sample that includes a moved departure, a part payment, a cancellation and a partly redeemed voucher. Compare source and destination field by field: product option, time zone, participants, booking status and money.
Picture a charter booked with a deposit that later changed date. After import, the calendar must show the new departure, and the original payment reference and correct outstanding balance must still work. A matching customer name proves nothing. Log every discrepancy before importing the rest, and run the sample again every time the mapping changes.
In parallel: move the money separately
Payments travel by a different route from bookings. Ask your payment providers whether stored payment tokens or references can move, and what consent, technical or contractual conditions apply. Never export card details into an ordinary file, and do not assume that importing a reservation gives you permission to charge it later. If credentials cannot move, agree a safe way to collect outstanding balances.
Decide where refunds for bookings made before the switch will be issued, who keeps access to the original payment gateway, and how those refunds will show up in the new booking record. Keep the reconciliation references, but do not give every staff member access to financial or sensitive guest information to do it.
The week of the move: redirect the post
Your sales channels are the post that keeps arriving at the old address. For each marketplace or agent, record the existing listing reference, its mapping to the new product and option, the commercial owner and the agreed time for switching it over. At every stage, one system is in charge of availability, and staff know exactly when to stop entering bookings in the old one.
Rezdy and Bókun both document channel-management arrangements that work with other reservation systems, so keeping your current channel layer may be an option. It still needs an agreed technical and commercial setup, and it is not a guarantee that your existing mappings survive unchanged.[3][4]
If inventory is in conflict, pause or restrict sales under the procedure you agreed with the supplier. Do not run two independent live calendars for the same vessel just to have an informal backup.
Moving night: go, or roll back
Before you swap the booking widget on your website, check the migrated future departures, participant counts, balances and voucher totals against the old system. Test the guest confirmation, staff permissions and one supplier-approved channel booking. Name the one person who has the authority to stop the cutover.
Agree rollback before you need it. Decide which widget or connection gets restored, where bookings taken during the changeover are recorded and how any duplicates will be sorted out. Keep the old system available, on agreed terms, until those records and payments can be handled safely.
The morning after: check every room
Before the first departure, compare the live manifest or pickup list with confirmed reservations. Track each exception on its own line: the reference, what does not match, who owns it, what was done and how it was resolved. Watch for both systems still sending reminders, so a guest never gets two conflicting sets of meeting instructions.
After the first settlement, reconcile money as well as headcounts. Remove old access only once the archive, export and refund procedures are working. And check before cancelling any add-on that holds records: Bookeo's published policy, for example, deletes signed waivers when a paid waiver plan is switched to No waivers.[5]
You are finished when staff can run the next departure and resolve the old balances, not when a screen says the import succeeded. If you have not yet chosen the new system, start with the trial guide.
Sources
Official documentation supporting this guide. Prices and availability may change; an access date is not a supplier publication date.
Related guides and tools
Boat and fishing tour software: compare manifests, charters and weather changes
Compare boat-operation features, then rehearse a vessel conflict, a crew handover and a mixed weather cancellation.
Walking and food-tour booking software: guides, guest notes and late changes
Choose around direct sales or distribution, shared guides, current meeting instructions and acknowledged guest requests.
Equipment rental software: compare stock, returns and shared bookings
Booqable and Checkfront lead different rental evaluations: item returns and downtime versus stock shared with activities.
Printable demo and migration checklists · Create a requirements checklist