Changing a booking system needs a plan for both the records and the people who use them. Our recommended starting point is to list the work that must remain possible during the change: answering an enquiry, finding a live booking, taking an authorised payment, sending the right documents and helping a traveller already away.

Use that list to define the migration and its acceptance tests. A successful import count is useful evidence, but it should sit beside checks that the team can complete those tasks in the destination system.

Decide what belongs in the move

Create a data inventory covering the records relevant to your business. Consider customers, future bookings, supplier references, balances, documents, notes and agreed permissions or preferences. For each group, decide whether it will move, remain in an accessible archive or be handled under your retention policy.

Record the source, destination, owner and acceptance check for each item. If there is no sensible destination for a field, resolve it before the final export. This avoids discovering after changeover that important information has become an unexplained note or an inaccessible attachment.

Map the records before loading them

Microsoft documents a migration approach using a staging database, where data can be transformed and validated before it reaches the target. The wider principle is useful even if your provider uses a different method: agree how source records become destination records and check the result. Source: Microsoft: data migration through a staging database

Ask how customer and booking identifiers will be preserved or mapped. Define how duplicate records and missing values will be handled. Keep a record of deliberate transformations so a later difference can be explained rather than mistaken for lost data.

Use a small but varied rehearsal

Choose a sample that represents the work your team actually does. Our suggested set includes a simple future booking, a multi-part itinerary, an amended booking, an outstanding balance and a record with attached documents. Add your own unusual but important cases.

For each one, compare the agreed source and destination details. Then ask a colleague to perform the relevant task without coaching from the person who loaded the data. This checks usability as well as field transfer.

Reconcile money and relationships

For an illustrative acceptance check, suppose a test booking has a £1,200 total and a recorded £300 payment. Confirm the expected £900 balance in the destination, then check the currency, payment reference and link to the correct booking. These invented figures are a simple arithmetic test, not an accounting rule.

Have finance define the real checks for your records and reporting arrangements. Include corrections and refunds where relevant. A matching overall total should not replace checking the records that make up that total.

Review access and processing roles

Ask who needs access to exports, test environments and the replacement system. Use the minimum information needed for the rehearsal and agree how temporary copies will be handled. These are recommended controls to make the migration process explicit.

The ICO’s controller and processor guidance explains how roles depend on the actual processing activity. Its controller–processor contract guidance is also relevant when another organisation processes personal data for you. Have the responsible person review the arrangement using the current guidance, which the ICO flags as under review. Source: ICO: controllers and processors Source: ICO: when a controller–processor contract is needed

Plan the final changeover

• Agree the final capture point: identify which new bookings or amendments must be included after the rehearsal, so recent work is not missed.

• Define the switching sequence: record who changes each connection and when, so responsibilities are clear.

• Set acceptance criteria: name the essential records and tasks that must pass before normal trading resumes.

• Prepare a fallback: agree the conditions for stopping or reversing the change and how new activity will be reconciled.

• Brief the team: give colleagues a short guide to finding records, raising problems and escalating urgent booking issues.

The exact sequence depends on your systems and supplier arrangements. Ask the providers to agree it in writing rather than treating this checklist as a universal technical procedure.

Keep the old records usable for the agreed period

Before ending the old service, test the access or archive arrangement your business has agreed. Ask someone to retrieve a selected historical record and its supporting documents. Have the appropriate person set the retention period; there is no retention duration proposed in this guide.

Finally, record the decision to switch, the evidence reviewed and the owner of any remaining issue. For help defining those requirements before choosing a product, use our travel agency software buying guide.

Written and updated by Travelgenix. Sources checked on 16 October 2026. Worked examples and checklists are editorial illustrations and recommendations, not customer results.