A mid-sized tour operator launched a 48-hour flash sale on Mediterranean cruise packages. Its new website, rebuilt the year before on a modern cloud platform, handled the surge of visitors without trouble. But every search still passed through the company's 20-year-old booking engine in its own data center, which could only manage a limited number of simultaneous sessions. Forty minutes in, searches started timing out. Customers who did reach checkout often found the price had changed since they'd searched. By the end of the weekend, the marketing team had a record number of visitors and a disappointing number of bookings.
The website had been modernized. The business underneath it hadn't.
Table of Contents
The Front End Was Never the Problem
Travel companies often start modernization with the part customers see: a new site, a better app. It's visible and relatively quick. The harder part sits underneath, in the systems that hold inventory, calculate prices, and create reservations. Many of these were written decades ago, and some still connect to external distribution systems that charge per query.
Travel has a particular pressure that makes this worse. Customers search far more often than they book. A single booking might follow dozens or hundreds of searches as people compare dates, cabins, and departure cities. A legacy core built for travel agents making deliberate bookings wasn't designed for millions of casual shoppers refreshing results on their phones.
Replacing the Old Engine Piece by Piece
Business application transformation in travel rarely works as a single big rewrite. Booking systems carry decades of rules about fares, cancellations, supplier contracts, and group bookings, many undocumented. Rewrites that try to replace all of it at once tend to run years late.
The approach that holds up is gradual. First, put an API layer in front of the legacy system so new applications never talk to it directly. Then move the read-heavy work out. Searches get answered from a cache of availability and prices refreshed every few minutes, while the live price is confirmed only at checkout. Itinerary displays and "manage my booking" pages come next, since they read data but rarely change it.
The reservation core, where bookings are actually created and money changes hands, moves last, once everything around it is stable.
There are tradeoffs. A cache that refreshes too slowly shows prices that no longer exist, and customers who see a higher number at checkout often abandon the booking or complain. Keep refresh intervals short for popular routes and peak dates, and when the price does change, say so plainly rather than quietly showing a new total.
Test against disruption, not only sales. When a storm cancels a day of flights or a ship misses a port, thousands of customers need rebooking at once. That load looks very different from a flash sale, and it's when travelers are least forgiving.
Why Travel Companies End Up on Several Clouds
Few travel companies choose multiple clouds deliberately. They arrive there. An acquired booking brand runs on one provider while the parent company uses another. European customer data has to stay in specific regions. The data science team prefers analytics services available on a third.
My view: running on multiple clouds for its own sake is expensive and rarely worth it. Moving data between providers carries transfer fees, engineers need skills on each platform, and security settings that are secure on one cloud can be misconfigured on another. It's acceptable when acquisitions, regulation, or a genuinely necessary service drives it.
Keeping Several Clouds Under Control
Once you're there, multi-cloud management tools help keep it manageable. The useful ones show combined spending across providers, apply the same security policies and access rules everywhere, and deploy infrastructure from templates that work on each platform. Prefer tools that enforce policies, such as blocking untagged resources or public storage, over those that only display dashboards.
Placement decisions still count for a lot. Keep components that talk to each other constantly, like the search service and its cache, on the same cloud and in the same region. Splitting them across providers adds delay to every search and a transfer charge to every response.
The tour operator ran its next flash sale eight months later, with searches served from cache and the legacy engine handling only confirmed bookings. Searches stayed fast through the whole weekend. In travel, customers rarely remember a company's technology. They remember whether the price they clicked on was the price they paid.