Kaptio does not offer a loading template to migrate legacy or active bookings from our customers' legacy systems. However, we have assisted customers over the years in finding ways to extract value from their legacy bookings. Additionally, we can help with the transition of any active bookings that have not yet traveled in their current legacy reservation system. This document provides a good overview of the recommended approach for both areas.

Legacy Bookings & Client Data

A definition of a legacy booking is a specific client itinerary that has already travelled in the past. This can in some cases also include quotes that did not convert. Providing your users with this data helps build up a full picture of the client (whether that is B2B or B2C) from a booking timeline perspective.

If legacy booking data needs to be retained, it is important to understand what data points should be stored and for which department and use case. The key questions that we advise clients to take into consideration are:

What legacy data will be useful to the sales team and why?

This will mostly be for Customer 360° view reasons and to help your frontline have context on repeat customers.

What legacy data will be useful to the marketing team and why?

This might help with creating marketing programs and/or do segmentation but this type of work usually happens in Marketing Automation platform such as Marketing Cloud, Hubspot or Marketo, and the legacy data might already be in those systems.

What legacy data will be useful to the operation team and why?

They will usually have access to historical data through a data warehouse or similar to do data analysis such as YoY.

Do you need this data inside Kaptio to start getting value from the Kaptio platform?

Usually, no. This data has value but this type of project can be executed after kaptio go-live. The exception to that is active bookings (see more on this in the section below).

Recommended Approach

Bookings in other reservation systems tend to be stored in a different structure compared to the Kaptio Travel data model. Because of this differing structure, Kaptio does not support transforming legacy data into the Kaptio Travel Itinerary object model due to complexity. If you are considering migrating your legacy bookings - and you feel you have good reasons to do so (see questions in the previous section), Kaptio recommends that customers create custom objects that represent the legacy bookings in a new flat structure just to keep a legacy data and reference to the Account object model (for 360° view purposes).

In order to achieve this, two new custom objects can be defined within Salesforce by your Salesforce administrator:

Legacy Booking
Account Legacy Booking Association

The account object can then be extended to be linked to these new objects, data transformed and then imported into this structure. Due to the different circumstances of each client and data set, Kaptio does not have any out-of-the-box objects or functionality, but adding these custom objects is straightforward and gives you more control over what data you want to retain.

Below is a starting point for the data points to consider for the Legacy Booking object:

Booking Number (text)
Booking Owner (text)
Package Name (text)
Booking Length in Days (numerical)
Total Amount (Currency Input Field)
Booking Currency (Currency Picklist Field)
Total Commission Amount (Currency Input Field)
Account (if B2B - lookup to Account)
Lead Passenger (lookup to Person Account)
Travel Start Date (date)
Travel End Date (Date)
Booking Date (Date)
Countries Visited (Text)
Number of Passengers (number)
Other Passengers’ Names & Ages (Long Text Area - transformed into a single field)

At the passenger level for each booking, it is useful to consider retaining and linking the additional passengers other than the primary passenger and having a “Lead Passenger” flag to distinguish between them from a reporting perspective on the Account Legacy Booking Association object.

This model assumes that you want all your previous passenger data to be created as Accounts in the system. We do recommend reviewing whether you have enough information about each Passenger for them to be created as an account in the system. A good rule of thumb is that if you don’t have any personally identifiable information about the passenger, they should probably not be created as an account, rather just “Name” on the legacy booking association object.

Active Bookings

Active bookings are bookings that have already been made in the legacy reservation system but have not yet travelled.

The approach we recommend to our customers is:

Set a cutoff travel date. This is the date that defines whether the booking should be created inside your legacy system or inside Kaptio. Example: Cut-off date is 01 Jan 2023. A guest wanting to start their trip on 31 Dec 2022 would be created into the legacy system, whereas a guest wanting to start their travel on 01 Jan 2023 would be created in Kaptio.
Operate all the existing and new bookings that are prior to the cut-off date in your legacy reservation system.
Any existing active bookings that are traveling after the cut-off date will be manually recreated in Kaptio
Any new bookings that are traveling after the cut-off date will be created and operated in Kaptio.

The obvious downside with this approach is that during this period your teams will be working in 2 systems, but due to data migration complexity, this is the recommended and best course of action for how to handle your active bookings and transition strategy.

Recommended approach

When manually recreating an existing active booking that already has a payment collected, make sure you recreate the payment on a payment method that is easily traceable so that it does not get counted again in your accounting system in case that payment has already been accounted for.
We recommend keeping the booking active in your legacy system. However, if an amendment it required after you have moved it into Kaptio, it is easiest from an accounting perspective to cancel the booking inside the legacy system, create an amendment in Kaptio and then have Kaptio be the full source of truth for that booking post amendment. If no amendments are required - this will also depend on your accounting integration setup with your legacy system.
Any supplier confirmations that have already been captured need to be moved manually. Any changes to the booking after this from a supplier operational standpoint should be managed within Kaptio.

Consideration for API Bookings

Migrating active bookings that include live API bookings from bedbanks and other third-party providers is a complex process that demands a lot of attention to detail for the following reasons:

The respective supplier(s) may provide their data in different formats, or the data can be incomplete depending on the API method used to retrieve it
This complexity is further compounded by the fact that different API methods are often required to obtain all the necessary information for a complete booking migration
This means that a great deal of effort must be put in to ensure that each booking is migrated successfully, which can be incredibly time-consuming and costly
There are significant risks associated with migrating API booked services, if something goes wrong during the migration process, important data can be lost or corrupted, leading to serious financial and reputational damage.

For these reasons, Kaptio recommends the general approach mentioned under the title "Active Bookings" This approach involves using the legacy system for any transactions related to API services. By doing so, the risks associated with attempting to migrate API booked services can be eliminated, while still allowing businesses to manage their active bookings.

On this page

Legacy Bookings & Client Data
Recommended Approach
Active Bookings
Recommended approach
Consideration for API Bookings