The Data You Need Before Switching Booking Software

There is one rule that prevents most migration problems: export everything you can while your account is still live, and work out later what actually needs importing. Exports are cheap now and impossible after you cancel.

This is the field-level version — what each category needs to contain, the consent question on customer records, the payment data almost everyone forgets, and how to get a clean export out of a system that would rather you stayed. For the wider migration sequence, see the step-by-step guide.

1. Bookings and forward reservations

Anything with a travel date after your switch is non-negotiable. Each reservation needs:

• Lead guest name, email and phone
• Party size, broken down by adults, children and any other rate categories
• Product and option — the 10:00 English shared departure, not just the tour name
• Travel date and time, plus the date the booking was made
• Amount paid, amount outstanding, and currency
• Source channel and the platform's own booking reference
• Special requirements — dietary, mobility, pickup location
• Status, including anything modified or partially refunded

The two fields most often lost are option and source reference. Without the option, guests arrive for the wrong departure. Without the reference, you cannot reconcile the marketplace payment that arrives weeks later, because there is nothing to match it against.

2. Customer records — and consent

Names, contact details, booking history, language, and any notes worth carrying. Deduplicate before importing rather than after — the same guest under three spellings becomes three customers, and repeat-visit history is exactly what you were trying to preserve.

The part worth pausing on

Moving personal data to a new system is generally fine where you have a lawful basis for holding it and are continuing to use it for the same purpose — your new provider should have appropriate data processing terms in place, which is worth confirming before you upload anything. Two distinctions matter:

• Booking data is not marketing consent. Someone gave you an email address to receive a confirmation. That is not agreement to a newsletter, and importing them into a marketing list treats it as though it were.
• A migration is a good moment to stop carrying what you should not have. Addresses scraped from enquiry forms years ago, contacts nobody can account for — leave them behind rather than moving the problem.

Obligations vary by jurisdiction and this is general guidance rather than legal advice, so check what applies where you operate.

One practical note: marketplaces frequently mask guest email addresses, so some of your OTA customer records will not contain a usable address. That is expected — and it is the reason collecting details directly on the day matters if you want a relationship you own.

3. Products, pricing and rules

Products are usually straightforward: name, description, duration, meeting point, inclusions and exclusions, capacity, options, photos, and pricing across every rate category, group tier and season.

The rules are where migrations go quietly wrong, because these frequently do not live in the old system at all — they live in someone's head:

• Which days and times each product actually runs
• Seasonal closures and blackout dates
• Minimum numbers to operate, and what happens below them
• Cut-off times, which may differ per product
• Buffer or turnaround time between departures
• Which guides or vehicles a product requires
• Cancellation and refund terms per product

Write these down before you start. Nobody thinks to export what was never recorded, and a rule discovered mid-season — the tour that cannot run below four people, the two-hour gap the van needs — is discovered by breaking it.

4. Payment and payout records

This is the category most often forgotten, and the only one where the cost of forgetting is measured directly in money.

Outstanding balances

Every guest who has paid a deposit and still owes a balance must arrive in the new system with that position intact. Lose it and there are two outcomes, both bad: you chase people who have already paid, or you never collect from those who have not. On multi-day products with substantial deposits, this is usually the largest financial risk in the whole migration.

What else to capture

• Deposits taken — amount, date, and against which booking
• Refunds pending or partially processed, so nothing is refunded twice or not at all
• Marketplace payouts not yet received — bookings already travelled where the money has not landed
• Scheduled payment reminders that were due to send from the old system and will not now fire
• Vouchers, gift cards and credits issued and not yet redeemed

Exporting cleanly

From spreadsheets

Tidy before you export, not after importing. Standardise product names so the same tour is not spelled four ways, split combined fields — a single "name" column holding two guests, or a date and time together — into separate columns, make date formats consistent, and remove colour-coding that carries meaning nothing else can read. Save as CSV and open it once to confirm nothing shifted.

From a legacy platform

Start with any self-service export in the reporting section, and check whether an API exists — it will usually give you more complete records than the CSV button does. Export while your account is still active and paid up, because access frequently disappears the moment you cancel.

If a provider is unhelpful, two things are worth knowing. Your contract may set out what you can retrieve on exit, and data protection rules in many jurisdictions give individuals rights over their own personal data — which can apply to records you hold about your customers. Ask in writing, keep the reply, and give yourself time rather than requesting an export the week you intend to leave.

What not to migrate

Restraint matters as much as completeness. Leave behind:

• Several seasons of completed bookings. Archive them read-only instead; the import effort buys almost nothing.
• Products you no longer sell. A migration is a free opportunity to stop carrying them.
• Duplicate and unreachable customer records. Bounced addresses and contacts with no basis for holding them.
• Stored card details. These belong with your payment provider and should not be moving around in exports at all.

Then verify. After importing, check ten or fifteen bookings by hand against the originals — product and option, date, party size, balance outstanding. Imports usually succeed, and occasionally succeed wrongly, which looks identical in a list. The implementation guide covers the rest of the cutover.

How Travelity helps

Travelity holds bookings, customers, products and payment position in one place, so the records above stay together rather than accumulating across files — and your own data remains exportable, because the ability to leave is part of what makes a system worth committing to.

The 21-day trial is long enough to import a real sample and verify it by hand before anything depends on it.

Frequently asked questions

What data do I need to export before changing booking systems?

Four sets: every reservation with a travel date ahead of you, your customer records, your products with pricing and availability rules, and your payment position — deposits taken, balances outstanding and refunds pending. Export everything you can while you still have access, and decide later what to import.

What happens if I forget to migrate outstanding balances?

You lose track of who owes you money. Either you chase guests who have already paid, which damages the relationship, or you fail to collect from those who have not, which is money gone. On multi-day products with deposits this is often the single largest financial risk in a migration.

Can I move customer data to a new booking system?

Generally yes where you are continuing to use it for the same purpose and have a lawful basis for holding it, though your new provider should have appropriate data processing terms in place. Marketing consent is a separate question from booking data — someone giving you an email to receive a confirmation has not necessarily agreed to a newsletter. Check your own obligations, as they vary by jurisdiction.

How do I export data if my current provider will not help?

Start with any self-service export in the reporting area, and check whether the platform offers an API. Where neither exists, data protection rules in many jurisdictions give individuals rights over their own data and your contract may specify what you can retrieve on exit. Ask in writing, keep the reply, and export while your account is still active rather than after you cancel.

Should I migrate my full booking history?

Usually not. Forward reservations are essential and recent history is useful for context, but importing several seasons of completed bookings adds effort and clutter for little return. Archive the full history separately as a read-only record instead, and keep it permanently.

What data is most often missed in a booking system migration?

Availability rules, because they frequently exist only in someone's memory rather than in the system — seasonal closures, minimum numbers, which days a tour actually runs, and cut-off times. Write them down before you start, because nobody thinks to export what was never recorded.

Bottom line

Export everything while access is easy. Carry every forward booking with its option and source reference. Deduplicate customers and think about consent rather than importing everything by default. Write down the rules that only exist in your head. And treat the payment position — balances, deposits, pending refunds, unredeemed vouchers — as seriously as the bookings themselves.

An afternoon on this is the difference between a migration nobody notices and one that surfaces for months, usually as a guest holding a voucher your system has never heard of.

Related guides

• Moving from spreadsheets to tour booking software
• Implementing booking software without disrupting your season
• How to choose tour booking software: a buyer's checklist
• OTA reconciliation and payouts: keeping the numbers straight
• How to manage tour bookings without spreadsheets