Tour Operator Software Development
Tour operator software development as a phased migration off a legacy reservation system: supplier contracting, allotments and release rules, quotes and vouchers, data cutover and what the Package Travel Directive, both the 2015 text and the 2026 amendment, requires the platform to encode.
13 min read
16 views
- Audit the legacy system before trusting its data Cached availability figures go stale quickly and should not be migrated as a source of truth.
- Model supplier capacity as a confirmation type, not a stock count Instant, manual and instant-then-manual are three genuinely different flows and manual needs a real human-in-the-loop path.
- A package is a runtime test on the cart, not a product flag The 24-hour click-through rule and the 25% value threshold are both rules a quote builder can evaluate automatically.
- Date every regulatory duty you encode The 2015 text binds today; the 2026 amendment applies from 29 March 2029 and Article 17 is rewritten between the two.
- Do not build a linked travel arrangement feature The 2026 amendment deletes the concept and replaces it with a point-of-upsell disclosure duty instead.
In short: migrating a tour operator off an off-the-shelf reservation system is a data and workflow migration first and a compliance migration second, run on different clocks. The legacy system's own copy of supplier availability, contracted rates and outstanding vouchers needs auditing, contracting and allotment logic needs remodeling around how suppliers actually confirm bookings, and the new platform needs to encode Package Travel Directive duties that bind today alongside a 2026 amendment that does not apply until 29 March 2029. Building a travel software platform for a tour operator or DMC means sequencing those two migrations rather than treating compliance as a checklist item at the end. Not every migration needs all five phases: an operator with a handful of instant-confirmation suppliers and no allotments can migrate contracts and bookings in one step and skip the parallel run. The sequencing earns its cost where manual-confirmation products, allotments and multi-currency contracts are involved.
Phase 0: Inventory what the legacy system holds
The instinct on a platform migration is to treat the legacy reservation system as a source of truth and migrate everything it holds. That instinct is wrong for one category of data: a cached copy of supplier availability, contracted rates or confirmed reservations is not the same as what the supplier's own system holds right now, and an inventory audit has to separate the two before a single record moves.
Practically, that means classifying each legacy table as either a system of record the platform itself created, such as a confirmed reservation or an issued invoice, or a cached copy of something that lives elsewhere, a supplier's availability calendar or a rate sheet pulled from an extranet. Only the first category migrates as-is; the second migrates as a starting snapshot, revalidated against the live supplier feed before the new platform relies on it. Our travel software development guide covers this distinction at the platform level; here it determines the actual sequencing of a migration project.
| Legacy data category | What to extract | Where it lands |
|---|---|---|
| Confirmed reservations and invoices | Full record, including payment and refund history | Migrated as-is into the new platform's reservation store |
| Supplier contracts and negotiated rates | Contract terms, rate tables, commission structure | Rebuilt as structured contract records, not free-text notes |
| Cached supplier availability | Snapshot only, not treated as current | Revalidated against the live supplier feed before go-live |
| Open vouchers and pending refunds | Outstanding balance, issue date, expiry terms | Reconciled against current voucher rules before cutover |
| Traveler and passenger profiles | Contact details, document numbers, consent records | Migrated as-is, subject to data protection review |
Phase 1: Supplier contracts and rates
A tour operator's contracted capacity is not a single stock model, and treating every supplier relationship as one count of units until it runs out misrepresents how most of that capacity behaves. A major distribution API documents booking confirmation as a property of the product itself, not a channel setting: Viator's own partner API documentation states that "A product's booking confirmation type indicates whether the booking will be confirmed or rejected immediately and automatically". The same documentation is explicit about the alternative: "Manual confirmation products are those that only operate at the discretion of the supplier, who must confirm or reject each booking request manually".
That gives a contracting platform three confirmation shapes to model, not one: instant confirmation against a held allotment, manual confirmation at the supplier's discretion, and a hybrid that starts instant and falls back to manual once the allotment runs out. The manual case needs a genuine human-in-the-loop path: a quote line sitting in pending-supplier-confirmation for hours or days is normal for a contracted DMC product, and the booking workflow, the traveler-facing status messaging and the operations team's task queue all need to be built around that state.
Contract data itself also needs a structured home rather than a free-text notes field. Rate tables, commission terms, minimum-stay or minimum-group rules and seasonal pricing bands should migrate into fields the quote engine can query, because a rate only a human can read is a rate the platform cannot enforce at quote time.
Phase 2: Allotments, release rules and booking cutoffs
Booking cutoffs are inventory rules attached to a product, not a setting configured once for the whole platform. A cutoff can be relative to the service's start time, relative to a fixed opening or closing time, or an absolute date, each with its own offset, and a new platform has to carry that per-product granularity rather than one global cutoff window. Getting this wrong either releases capacity a supplier still expected to hold, or blocks a booking a supplier would have accepted.
Cached availability deserves the same caution, and ignoring it costs money rather than accuracy. Distribution platform documentation for a major travel API warns integrators that its own availability schedule data can rapidly fall out of date, and a tour operator's legacy system carries the identical risk. A sync engine trusting its own last-ingested availability copy for the booking decision, rather than checking the live feed at booking time, will eventually confirm a reservation the supplier can no longer honor. Treating its own cache as advisory, and the live supplier check as authoritative, matches the discipline our hotel channel manager integration guide covers for accommodation inventory, and it applies equally to tour and activity allotments.
A migration checklist for this phase:
- Extract every active allotment agreement from the legacy system, including release date, held quantity and the release-back terms with the supplier.
- Classify each product's cutoff rule by type: relative to start time, relative to a fixed daily time, or an absolute cutoff date.
- Confirm which products are on instant confirmation, which are manual and which are hybrid, per Phase 1's model.
- Rebuild the release-rule engine to write directly against live supplier availability at the moment of booking, not against a locally cached copy.
- Run a parallel period where the new platform's cutoff and release decisions are compared against the legacy system's before cutover, and reconcile any divergence before go-live.
Phase 3: Quotes, itineraries and vouchers
The 2015 Package Travel Directive already requires standard-form pre-contractual information: the organizer, and the retailer where one is involved, has to hand the traveler the prescribed standard information before the contract is binding. That form lives in Annex I, and Annex I is replaced in full by the 2026 amendment, Directive (EU) 2026/1024. A quote and itinerary template built today against the 2015 Annex I has a known expiry date, one to revisit before the amendment's 29 March 2029 application date rather than treat as a permanent platform fixture.
Vouchers need a similar rethink, and this is the clearest place a migration project can build the wrong thing. Under the 2026 amendment, a voucher issued in place of a cash refund becomes a regulated financial instrument with its own disclosure duties, not a print artifact like a hotel or guide voucher. Modeling both under one generic voucher record, the way many legacy systems do, cannot answer either question correctly: what a refund-substitute instrument still owes, or what a hotel voucher was ever meant to represent. The two need separate records from the start of the migration, not a shared table with a type flag bolted on later.
The amendment also adds a disclosure duty that did not exist in the 2015 text: at the moment a trader invites a traveler to purchase an additional travel service outside a package, for the same trip, the traveler has to receive pre-contractual information about that add-on. For a quote builder, that is a UI event, not a product category. It fires whenever an upsell happens, regardless of what kind of add-on is being offered, and it needs a disclosure step attached to the upsell action itself rather than to a specific line of the product catalog.
Phase 4: Data migration and cutover
Cutover is where every earlier assumption about the legacy system's data meets a live deadline, and the cost of getting it wrong stops being an audit finding and becomes a customer-facing failure. Cutover planning should treat legacy data as an audit input to reconcile against the live supplier feed, not a trusted source the new platform simply inherits.
The same discipline that governs a flight or hotel booking engine development project applies here: a reservation that looks confirmed in the export is not necessarily confirmed with the supplier, and a voucher that looks redeemed in the legacy database may still carry an outstanding balance the new platform needs to honor. Running both systems in parallel, reconciling reservation and voucher state daily rather than assuming a one-time export is complete, catches the mismatches a single big-bang cutover would otherwise ship straight to travelers.
A pattern we have seen repeatedly on tour operator migrations: the new platform computes an allotment's release date from the supplier contract's calendar, while the legacy system had that release date hard-coded from whenever someone last kept it current. The parallel run catches the two systems disagreeing on which rooms were still held a week before departure, and the legacy answer turns out to be wrong, because nobody had revisited the hard-coded value since the contract was renegotiated. Nothing about that discrepancy shows up in either system's error log; it surfaces only because the two systems are compared against each other, booking by booking, for the length of the run.
On our own tour operator migrations, the parallel run has a hard stop rule rather than a fixed calendar length: any divergence in a confirmed booking's price, dates, passenger count or supplier reference between the two systems halts the cutover until explained, not just logged. The run continues until a full release cycle of the operator's longest release rule has passed with no divergence, since a shorter window can complete without ever exercising the release logic it exists to test. One named engineer owns the daily diff and signs off before the next day's bookings run.
Cutover itself should be sequenced by risk: migrate closed, fully reconciled bookings first, migrate open bookings with an active balance or pending voucher last, and freeze new bookings on the legacy system before the final window.
What the Package Travel Directive requires the platform to encode
The Directive's definition of a package is a runtime test on a booking's contents, not a flag an operator sets on a product record. Directive (EU) 2015/2302 defines a package as a combination that "means a combination of at least two different types of travel services for the purpose of the same trip or holiday". A platform letting a consultant assemble a quote line by line has to evaluate that test on every quote: two lines that were an unregulated pair yesterday become a regulated package once a second service type is added. A related trigger: passing a traveler's name, payment details and email address to a second trader who confirms within 24 hours pulls the whole arrangement into the package regime too.
The 2026 amendment sharpens that test into arithmetic. Where the 2015 text relied on a vague significant-proportion standard, Directive (EU) 2026/1024 replaces it with a stated threshold: an add-on falls outside the package only where the services "do not account for at least 25 % of the value of the combination and are not advertised as and do not otherwise represent an essential feature of the combination". That is a rule a quote engine can evaluate automatically, rather than a judgment call left to a consultant.
Refund and servicing clocks here are dated and directional. Under the 2015 text, refunds after termination of a package travel contract are due to the traveler within 14 days, with no matching deadline running supplier back to organizer. The 2026 amendment adds that missing direction: a supplier who cancels or fails to deliver a service now has to refund the organizer within seven days, and fixes clocks on complaint handling too, a seven-day acknowledgment and a 60-day reasoned reply, turning policy text into a service-level commitment the platform has to measure.
Insolvency protection duties are the clearest case where dating a claim matters: the 2015 and 2026 wordings genuinely disagree, and only one is current law after 29 March 2029. The 2015 text requires security for repatriation where the package includes carriage of passengers, sized against the timetable between deposits and completion. The 2026 amendment replaces Article 17 in full: the duty attaches to the return journey rather than to carriage of passengers, and the sizing period runs from the receipt of any payment rather than the down payment alone. A platform built today should encode the 2015 wording as what binds now, and flag the 2026 wording as the version to switch to once transposition catches up.
None of this changes on the platform's own schedule. Member States have until 29 September 2028 to transpose Directive (EU) 2026/1024, and the new measures apply from 29 March 2029 onward. A platform specified today will be live well past that date, so both rulesets need to exist in the system: the 2015 duties as what is enforceable now, and the 2026 duties as a dated, switched-on-later ruleset.
Two things worth building correctly and one worth skipping. First, build the prepayment disclosure step itself: Directive (EU) 2026/1024 confirms there is no EU-wide cap on prepayment, the Directive does not limit deposit amounts or dictate a balance-payment timetable, but it does require that whatever schedule the organizer applies gets disclosed to the traveler before booking. Second, vouchers under the 2026 amendment carry their own disclosure duties, covered in Phase 3 above, and never share a data model with a non-financial voucher. Third, skip the linked travel arrangement concept, the pre-2029 category for separately contracted services facilitated by one trader: the amendment deletes it rather than extends it. A roadmap that spends engineering effort on linked travel arrangement handling today is building a compliance feature EU law retires before most projects reach their first anniversary in production; if it appears at all, it should appear as something being phased out, with the point-of-upsell disclosure duty from Phase 3 as its replacement.
For operators selling into the UK market, a second financial-protection regime sits alongside the above rather than replacing it. ATOL, the UK Civil Aviation Authority's scheme, ensures consumers are repatriated or refunded for ATOL-protected holidays and flights, and it reaches businesses established outside the UK if they advertise and sell to UK consumers, so an EU-based operator cannot treat ATOL as someone else's problem. Bonding is set at a stated percentage of licensable revenue, fifteen percent under the standard ATOL type, subject to a minimum bond value, so the platform needs to report licensable revenue in a form that satisfies both this regime and the Directive's own insolvency-protection sizing from the same booking data. Building a travel software platform that answers both regimes from one dataset is the difference between a compliance section that ships once and one that needs rebuilding the first time a regulator asks a question the data was never structured to answer.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 6
No matches
Try a different keyword, change the topic or clear filters
-
Auditing what the legacy system's data actually reflects, not migrating it as-is. Cached availability data can fall rapidly out of date, so the audit needs to separate the system's own committed contracts and confirmed reservations from availability figures that may already be stale.
-
As a confirmation type attached to each product rather than a single stock count. Distribution platforms document three shapes: instant confirmation, manual confirmation that exists purely at the supplier's discretion and a hybrid that starts instant and can fall back to manual and a reservation engine needs a genuine human-in-the-loop path for the manual case.
-
Combining at least two different types of travel services for the same trip, evaluated as a runtime test on the contents of a booking rather than a flag set on a product. A separately booked add-on within 24 hours of the first booking, or a tourist service reaching 25% of the combination's value, can also pull a booking into the package regime.
-
No. The Package Travel Directive does not cap deposit amounts or dictate a balance-payment timetable; it only requires the operator to disclose whatever schedule it applies. Member States may regulate the point separately, but no such cap exists at EU level.
-
A new business-to-business rule requires a supplier that cancels a service to refund the organizer within 7 days, refund vouchers become a regulated instrument with their own disclosure duties and fixed clocks apply to complaint handling. The amendment also removes the linked travel arrangement concept entirely.
None of this applies before the 29 March 2029 application date.
-
No, that is a separate scheme, ATOL, run by the UK Civil Aviation Authority. ATOL guarantees repatriation or a refund for protected holidays and flights and it reaches businesses established outside the UK if they advertise and sell to UK consumers, so a non-UK operator selling into that market needs to plan for both regimes from the same booking data.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
