A field-by-field plan for products, future departures, bookings, guests, payments, staff, testing, cutover, and rollback.
The safest way to switch tour booking software is to define a cutover owner, inventory and map the source data, configure the new operating model, pilot representative departures, reconcile every count and payment total, and keep a tested rollback path. Confirm supported import fields before promising a date.
Choose one accountable migration owner. Define the first date that new bookings enter the new system, the last date staff update the old system, and the conditions that would trigger rollback.
List products, options, schedules, capacity, blackout dates, price rules, add-ons, future bookings, guest fields, payment status, refunds, invoices, customer notes, groups, staff, roles, and historical exports. Record who owns each source and how it can be exported.
For every source field, decide the TourSyncer destination, transformation, owner, validation rule, and what happens when no safe destination exists. Do not assume an import can preserve undocumented custom fields.
Create workspaces, users, roles, products, schedules, capacity, pricing, forms, payment rules, cancellation wording, invoices, and notification settings before moving live bookings.
Verify the correct legal entity, test payment methods, settlement, receipts, partial and full refunds, failed payments, and pay-later or manual records. Never move raw card details through spreadsheets or general-purpose imports.
Rebuild a simple scheduled tour, a private group, and the most complex multi-day or high-capacity departure you sell. Test booking, guest details, price, payment, invoice, staff assignment, manifest, communications, and check-in end to end.
Compare counts and totals by departure: booking count, guest count, amount due, amount paid, refund status, staff assignment, and capacity. Resolve differences before the new system becomes authoritative.
Stop changes in the old system, run the final approved transfer, switch booking links, monitor the first transactions and departures, and retain read-only exports. Do not delete the old source until retention, tax, dispute, and audit needs are satisfied.
| Record set | Validate | Safe default |
|---|---|---|
| Products and schedules | IDs, duration, time zone, capacity, blackout dates, price rules | Rebuild and test before bookings |
| Future and active bookings | Departure, guest count, amount due/paid, status, notes, add-ons | Highest migration priority |
| Customers and guest data | Consent, purpose, duplicates, contact fields, retention | Move only justified fields |
| Payments and refunds | Processor, amount, currency, status, refund and dispute state | Move references/status—not raw card data |
| Staff, roles, and assignments | Active users, least privilege, schedule/activity ownership | Reinvite and verify access |
| Historical records | Tax, support, dispute, audit, and retention need | Secure read-only archive when sufficient |
It depends on source quality, future-booking volume, custom fields, payment setup, integrations, and testing. Set the schedule only after a sample export and field map are reviewed. A small staged pilot is safer than choosing a universal timeline.
Do not assume that. Import scope depends on the source system, available exports, data quality, and current TourSyncer import support. Ask for the exact supported fields, transformations, exclusions, and validation method in writing before committing to cutover.
Never export or move raw card details through a spreadsheet or ordinary import. Payment credentials are controlled by payment providers and card-security rules. Confirm any provider-to-provider payment-data process directly with the payment providers.
Move only what has a clear operational, customer-service, financial, or legal purpose. Future and active bookings usually deserve the highest validation. Older history may be retained in secure read-only exports if a full import adds risk without enough value.
Use the same evidence-based process: obtain a sample export, map supported fields, configure payments and products, pilot real departure types, reconcile counts and totals, define rollback, and preserve required records. The exact export and contract steps vary by vendor.
Bring a sample export and one representative departure to the evaluation. Ask for supported fields, exclusions, validation, and rollback in writing.