Reservation system migrations in travel carry a narrower margin for error than most software switches: PNR data has to migrate with zero unplanned downtime, payment tokens frequently don't transfer between processors, and airlines replace passenger service systems only once every 10–15 years precisely because the risk is so high. This checklist applies whether you're migrating a booking engine, a passenger service system, or a legacy GDS-dependent platform toward NDC connectivity.

Who this is for

Travel technology leaders, OTAs, and airline or agency IT teams planning a reservation system replatform, PSS migration, or a shift from legacy GDS/EDIFACT connectivity toward NDC.

Before you start

  • [ ] Define success criteria numerically up front: target percentage of active PNRs migrated successfully (100% is the standard bar), acceptable post-migration error rate in bookings/tickets (under 1% is typical), and zero unplanned downtime during cutover.
  • [ ] Inventory every connected system: GDS connections, NDC integrations, payment gateways, loyalty platform, and any third-party distribution channels (OTAs, metasearch).
  • [ ] Assess your current distribution mix — how much booking volume still routes through legacy GDS/EDIFACT versus NDC — since this determines migration complexity and sequencing.
  • [ ] Confirm whether NDC adoption is in scope for this migration; it requires an NDC connection, IATA accreditation (for airlines/agencies), an aggregation strategy, and an offer-and-order management layer — treat this as a separate workstream if it's part of the plan.
  • [ ] Set a realistic timeline: full implementations with custom booking portals and multiple supplier integrations typically take 3–6 months; a GDS or NDC integration built from scratch alone can take 2–6 months of development.

PNR and booking data migration

  • [ ] Export and validate every active PNR before migration — partial or malformed PNR data is the most consequential failure mode in this category.
  • [ ] Map booking statuses, fare rules, and ancillary services explicitly between old and new systems; these fields rarely map one-to-one.
  • [ ] Reconcile ticketing and settlement data against your BSP/ARC reporting before and after migration to confirm nothing was lost in translation.
  • [ ] Run a parallel-processing period where the new platform shadows the incumbent system against the same live transaction stream — every divergence between the two becomes a defect to fix before full cutover, not after.

Payment and loyalty data

  • [ ] Confirm explicitly whether payment tokens transfer to the new payment processor — they frequently don't, and this is one of the most common migration failures in travel platforms.
  • [ ] Time any payment processor cutover around billing/renewal cycles for subscription or membership products, never mid-cycle.
  • [ ] For loyalty data: validate points balances reconcile to the correct totals, and that tier status transfers correctly for high-value members — "almost correct" balances are a silent-drift risk that surfaces weeks later as member complaints, not immediately.
  • [ ] Test refund and cancellation flows against the new payment setup before go-live — these are the transaction types most likely to break silently.

Cutover planning

  • [ ] Schedule cutover during genuinely low-booking-volume periods for your specific business, not just "off-peak" generically — travel booking patterns vary sharply by route, season, and channel.
  • [ ] Aim for zero customer-perceived downtime; payment and booking downtime in travel can cost tens of thousands per minute during peak periods, so the cutover window itself needs a tested rollback trigger, not just a plan.
  • [ ] Freeze non-critical changes to the legacy system in the days immediately before cutover to avoid a data mismatch at final export.
  • [ ] Keep legacy system read access available post-cutover for a defined reconciliation window, particularly for BSP/ARC settlement disputes that can surface weeks later.

Red flags to watch for

  • [ ] Any migration plan that doesn't explicitly test payment token transfer before go-live.
  • [ ] No parallel-run or shadow-processing period for booking data validation.
  • [ ] Loyalty balance migration validated only by spot-check rather than full reconciliation against source totals.
  • [ ] A cutover plan with no tested rollback path if PNR error rates exceed your defined threshold.

How to use this

Treat the "before you start" success criteria as your acceptance test for the whole project, not just a planning exercise — revisit them explicitly before declaring the migration complete. The payment token and loyalty balance sections are the two areas most likely to look fine at cutover and surface problems weeks later; build validation checkpoints for both into your post-launch plan, not just launch day.