Legacy System to Cloud-Based Group Management System: Modernising a History Tour Operator Without Missing a Departure

Industry:

Travel

Platforms:

Confirm: Web Application

Legacy System to Cloud-Based Group Management System

Project Summary

A family-owned history tour operator had run every group for twenty years on a desktop application only its retiring author understood. We moved it to a cloud-based group management system between seasons, keeping decades of traveller history and never putting a live departure at risk.

Client

Family-owned US operator of escorted history and battlefield tours in Western Europe

Group

Commemorative departures, returning veterans' and reunion associations, multi-generation repeat travellers

Problem

An office-bound legacy application, near end of support, understood by one retiring contractor

What we built

A cloud-based group management system with the old system's rules written down and tested

Delivery

Parallel run, then a between-season cutover with every live group reconciled

Legacy System to Cloud-Based Group Management System second

About the Client

No single failure forced the decision. Several pressures arrived together:

Key-person risk. The contractor who wrote the application was retiring, and nobody else understood its queries.
End of support. The office server and its database were nearing the end of vendor support, with no simple upgrade path.
Office-bound access. Tour managers in Normandy couldn't check a traveller's needs without phoning the US office across a time difference.
Re-keying. Online registrations arrived by email and were typed in by hand, a textbook case of re-keying traveller data across channels.

Every commemorative season also ran on one machine; an outage in those weeks would have stopped the business. The question wasn't whether to modernise, but how, without losing the memory or a live departure. Groups were always somewhere between recruiting and travelling, peak season ruled out any move, and some behaviour lived in queries and forms that nobody had documented.

Why This Approach

Option	Where it fits	Why it did or didn't fit here
Extend the existing system with a group module	Operators whose core still works and only lacks group capability	The foundation itself was at end of life; see when extending an existing platform is the better path
Copy the old application into a browser	Systems whose workflows still fit the business	Would have moved the old limits, and the notes-field workarounds, to the cloud
Write down the old rules, redesign the workflows, then migrate	End-of-life systems that still encode how the business runs	Chosen: keeps the knowledge, drops the constraints

What We Built

The design rule: treat the old system as the specification. Every form, report and saved query was walked through with the staff who used them, and with the contractor while he was still available. Each behaviour was written down as a plain business rule; anything nobody could explain was marked for testing, not guessed.

Component	What it does	Gap it closes
Linked groups, departures and travellers	Association groups, open departures and private family trips share one model, like a wholesaler's linked operations record	Workarounds for anything outside the original design
Structured traveller needs	Accessibility, dietary needs, room shares and the memorial a family is visiting, as fields	Critical facts buried in free-text notes
Online registration and payments	Website registrations and gateway payments post straight to the traveller; accounting exports from the same records	Emailed registrations and hand-keyed payments
Tour manager access	Phone or tablet sign-in to the group's manifest, needs and memorial visits, with changes recorded on the road	Calls to the office across time zones
Managed cloud hosting	Backups, separate test and live environments, role-based access and an audit trail	One office server in peak season

Data was cleaned on the way across. Duplicate travellers were merged with staff reviewing uncertain matches, never on name alone, and wherever a note's meaning was unclear, the original was kept beside the new fields. Nothing was thrown away.

How It Works Now

Plan the season's departures with hotels, coaches and guides, drawing on what earlier seasons recorded.

Open association groups from their history: preferred hotels, usual leader, past travellers to invite.

Produce manifests in the formats hotels and coach companies already know.

Run the tour on the ground, with tour managers recording changes the office sees immediately.

Feed the next season, so the next invitation starts from accurate history.

In Practice: The Rule Nobody Wrote Down

During the parallel run, one departure was managed in both systems and every manifest compared. Rooming and meal lists matched. Coach seating didn't.

Before, travellers with mobility needs had always appeared in the front rows, and the tour manager's seat was always held. Nobody had listed it as a rule. An old seating report was quietly sorting travellers by a code staff typed into the notes field when someone needed help with steps.

Now it is an explicit rule, run from the structured accessibility field: travellers with a recorded mobility need are offered front seats first, the tour manager's seat is held, and the manifest shows the driver why. For elderly veterans and their families, that decides whether someone can get off the coach at a cemetery with dignity. The rule inventory had flagged the behaviour as unexplained; the parallel run proved it.

Legacy System to Cloud-Based Group Management System third

Delivery and Scope

The cutover was timed to the gap between seasons, not a project deadline. The old system went read-only for a short window, every open group was migrated, and each was reconciled against supplier confirmations, headcount, balances and rooming from the old system's own reports before going live. One veterans' group travelled weeks later; when a traveller had to leave mid-tour, the tour manager logged it in France that evening and the US office started the follow-up next morning without a phone call. Staff reviewed the rules for their own work, their daily reports were rebuilt first, and training used the operator's own groups.

Results

Area	Legacy application	Cloud system
Where it works	The office, or a fragile remote connection	Anywhere, including tour managers abroad
Continuity	One server, one contractor	Managed hosting, backups, a documented rule set
Business rules	Hidden in queries and forms	Written down, tested, visible on manifests
Traveller needs	Free text in notes	Structured fields, original notes kept
Repeat-traveller history	Locked in the office	Merged and available wherever the group runs

The most important result is the easiest to overlook: the operator's memory survived the move. Twenty years of families, associations and their needs no longer depend on one machine or one person.

Lessons for Tour Operators

Extend if you can, replace if you must. Replacement makes sense when the foundation is unsupported, office-bound and dependent on one person.

Expect rules nobody wrote down. A parallel run that compares real manifests is where they surface.

Never switch a live group without reconciling it against the old system's own reports.

Keep the memory. Merge duplicates carefully and keep original notes.

If your group operation still depends on an ageing system and the one person who understands it, see how we build custom group management systems for tour operators