Switching holiday let software without losing your bookings, guest messages or financial records

The common mistake when switching holiday let software is treating it as one export and one import. Your history sits in four places: bookings and availability, guest messages, financial records, and the know-how that lives in your head. Each needs moving in its own way and its own order. This guide covers what to move and what to keep, setting a cutover date so you don't run two systems for months, the order that avoids double bookings, and how to test the new system before a real guest books.

The four kinds of records every holiday let switch has to move

Almost every failed migration has the same root cause. The host treats "my operating history" as one single thing that needs to move from System A to System B in one go. It doesn't work that way, and treating it that way is exactly why things get lost.

There is your bookings and availability data: dates, prices, availability, which platform each booking came from. There is your guest communication history: every message, every complaint, every "can we check in early" exchange. There is your financial and compliance record: what you charged, what you were paid, what you need to be able to show if asked. And there is your operational knowledge: the things you have learned about this specific property that live in your habits, not in any database.

Export tools, when they exist, generally move the first category reasonably well. They rarely touch the other three at all. If you assume "export and import" covers everything, you find out what it missed at the worst possible moment, usually when a guest references something from before the switch and you have nothing to point to.

Bookings and availability: what has to move

Start here because it is the most time-sensitive category. Before you export anything, freeze the picture. Pick a date, write it down, and treat everything booked or blocked before that date as final in the old system.

Export whatever the old system will give you: a calendar file, a spreadsheet, a booking list. Check it against your own memory of upcoming bookings. Software exports are not infallible, and a booking that silently failed to sync from a platform months ago might not be sitting where you expect it.

Cross-reference against each platform you list on directly. If you are moving a channel manager, delete the old iCal links on each platform before adding the new sync, otherwise the old system can continue pushing stale blocks. If the old connection is API-based, check each listing afterwards because disconnecting it can affect settings or pricing. If you use more than one booking platform, log into each one directly and confirm the dates that show as booked there match what you are about to bring into the new system. This step catches the errors an export alone would miss, because the platform itself is the source of truth, not whatever your old tool cached. If you're unsure how your current setup syncs, how channel managers keep calendars in sync explains the difference between calendar links and direct connections.

Only once you have confirmed the calendar picture is accurate should you import it into the new system. Do this before you go live, not on the day you go live, so you have time to catch mismatches while there is still slack to fix them.

Guest communication history: what to archive and what to keep live

You do not need every past guest message accessible inside your new system's interface. You need it retrievable, which is a lower bar and a much easier one to hit.

Airbnb and Booking.com keep their own message threads on their platforms, whichever management software you use, so the higher archiving priority is direct-booking conversations and email exchanges.

Before you close the old account or cancel the old subscription, export or download whatever conversation history the tool allows. Many will let you download messages as a file, even a basic one. If there is no export function, take screenshots of anything important: agreements about early check-in, promises made about refunds, anything that could resurface as a dispute.

Store this somewhere outside both systems. A dated folder on your own computer or cloud storage works. Keep it secure and do not retain personal data for longer than needed under UK GDPR. See the ICO UK GDPR guidance for the current principles.

For bookings that are still upcoming at the point of switch, you do need the relevant messages visible somewhere useful, ideally copied into the new system's guest record if it allows notes, so whoever handles that guest's stay next has the context without having to dig through an archive.

Financial records

Treat this as separate from the switch entirely, because it is. Your booking system was never the correct permanent home for financial records, even though it might have felt convenient to leave them there.

Download every financial report the old system offers: payout summaries, fee breakdowns, anything itemised by booking. Include direct-booking payment records from services such as Stripe and any damage-deposit records, not just the reports generated by the management software. Do this before you cancel anything, because access often disappears the moment a subscription lapses.

HMRC's guidance on how long to keep your records says that if you send your tax return on time, you should keep records for at least 22 months after the end of the tax year it covers. Different periods apply if you file late, are self-employed or run the let through a limited company, so check the guidance that applies to you.

The new system will start generating its own financial records from the point you go live. There should be no gap and no overlap. This is exactly why the cutover date matters so much: it is the line between "old system's financial record" and "new system's financial record," and it needs to be unambiguous.

Operational knowledge

This is the category that gets skipped most often, because it never felt like it needed exporting. It was just what you knew.

Before you switch, write it down properly, in one place, even if it feels excessive. How the property works, room by room. Quirks that confuse guests. The phrasing that has worked well in awkward messages, whether about noise complaints, late checkout requests, or refund conversations. Timing habits: when you usually message guests before arrival, what you check before every changeover, what you have learned to double-check because you got caught out once.

None of this needs to live inside the new booking system specifically. It needs to exist somewhere durable, independent of whichever software you happen to be using this year, because you will likely switch again eventually, and this knowledge should outlast every tool you ever use.

Setting a cutover date instead of running two systems forever

The single biggest practical decision in any switch is picking the moment the old system stops being live and the new one takes over. Without a clear date, hosts often end up running both systems simultaneously for weeks, updating one and forgetting the other, which is exactly how a double booking happens.

Pick a date that sits in a quiet period on your calendar if you can, ideally a stretch with no imminent check-ins. This gives you breathing room if something needs fixing before a guest is affected by it.

From that date, the old system becomes read-only in your mind, even if it technically still lets you make changes. All new activity, all new messages, all new bookings, happen in the new system only. Any booking that existed before the cutover but arrives after it should already have been migrated across during your calendar transfer, so there is nothing left dangling.

The order to switch in

Sequence matters more than most hosts expect. Do it in this order:

The reason to update platforms one at a time rather than all at once is simple. If something goes wrong with the sync, you want to know immediately which platform caused it, not be left guessing between three simultaneous changes.

Old booking links and receipts after you switch

Guests sometimes hold onto old confirmation emails or messages for months, sometimes referencing a link that points back at the old system. If that system is cancelled outright, those links can break, and a guest chasing a receipt or a booking reference finds nothing.

Where possible, keep the old account active in a minimal, low-cost state for a reasonable window after the switch, rather than cancelling it the same week. This buys time for any loose ends to surface naturally rather than all at once.

For anything important, such as receipts guests might need for expense claims or their own records, consider proactively resending a copy in a format that will still work after the old account closes, rather than relying on a link staying live indefinitely.

Test the new system before a real guest books

Before the cutover date, run a dry test. Do it before your live platforms are connected, or on dates you've already blocked, because a test booking in a connected system can push blocks out to your real listings. Create a test booking if the new system allows it, or walk through the guest journey manually: what message would a guest receive on booking, what would they receive the day before arrival, does the calendar block correctly across every connected platform.

This is where you catch the mismatch between how you assumed the new system worked and how it works. Every system has quirks that only reveal themselves under real conditions, and finding them before a real guest is affected is the entire point of testing.

Common switching mistakes

The most common mistake is treating the switch as a single afternoon's task rather than a short project with a defined sequence. It usually shows up as rushing the export step, skipping the cross-check against each platform, or cancelling the old system before every sync has been confirmed.

A close second is forgetting that guest communication and financial records need separate handling from calendar data. Hosts who only think about the calendar are often the ones who lose a guest dispute months later because they cannot produce the conversation that would have settled it.

A quieter mistake is switching because a new tool looked impressive in a demo, without testing whether it solves your specific bottleneck. Sometimes the fix is not a new system at all. It is using the current one properly, or adjusting one habit rather than replacing the whole setup. Choosing software around the problem that's costing you most is the test to apply before you commit.

When staying with your current software is the better choice

If your current system does the job and your frustration is about one specific feature or a price increase you resent, a full switch carries real risk for a marginal gain. Weigh the cost of the migration itself (the time it takes and the risk window around the cutover) against what you gain.

If the answer is "slightly nicer interface" or "a feature I would use occasionally," it is worth pausing. If the answer is "this system cannot do something I need every week" or "the cost has become unworkable," the switch is worth the effort described above.

Keeping your history, whatever software you use

None of your operating history was ever stored only in the software. The software was just where you happened to be looking at it. Your calendar, your guest conversations, your financial records and everything you have learned about running this property belong to you, not to whichever tool you paid for last year.

Move each piece deliberately to where it needs to live rather than relying on one export button. Keep a short note of where each type of record now sits, and the next switch, whenever it comes, will be much easier.