Every time you book a flight or check a hotel room, your request is routed through a green-screen mainframe system that traces back to the 1960s — and the entire multi-billion-dollar travel industry still relies on this ancient digital foundation because replacing it would be enormously expensive, dangerous, and slow

Every time you book a flight or check a hotel room, your request is routed through a green-screen mainframe system that traces back to the 1960s — and the entire multi-billion-dollar travel industry still relies on this ancient digital foundation because replacing it would be enormously expensive, dangerous, and slow Featured Image

When you book a flight on your phone — a clean, modern app with smooth animations, real-time pricing, and one-tap payment — the part of the system you’re touching is the very thin, very recent layer at the surface.

Underneath it, almost invariably, your request is being routed into one of three vast, deeply old systems that quietly hold the entire global travel industry together. Sabre. Amadeus. Travelport. Between them, they handle essentially every airline booking, the majority of hotel bookings, and most travel-agent transactions on Earth.

And the oldest of them, Sabre, traces its origins to the early 1960s — an era when the most powerful computer in the world had less computing power than the phone you’re holding.

The interface most travel professionals use to talk to these systems is, in many cases, still a green-screen text terminal — or a modern graphical wrapper over one. The reservation made for your seat on a Boeing 787 in 2026 is, at some layer of the stack, still being processed by a piece of digital infrastructure designed when the most exotic computer in service was an IBM 7090.

The system that started it all

The story begins, of all places, on a 1953 American Airlines flight.

The president of American Airlines, C. R. Smith, happened to be seated next to an IBM salesman named R. Blair Smith. Over the course of the flight, they got talking about American’s reservation problems. At the time, airline bookings were managed by rooms full of clerks shuffling physical cards on circular tables. Errors were constant. Two passengers would routinely be booked on the same seat. Empty planes flew while paying customers were turned away.

By the end of the flight, the two had agreed to start a project together. It would take more than a decade, $40 million (around $350 million in today’s money), and 400 person-years of programming work. But when they finished, they had built something that didn’t exist anywhere else in the world: a real-time, computerised reservation system, distributed across multiple cities, capable of booking flights in seconds rather than hours.

They called it Sabre — Semi-Automated Business Research Environment. It was fully operational in 1964. It would, over the following decades, become the template for every airline reservation system in existence.

How a 1960s system runs the modern travel industry

What Sabre proved was that real-time, networked, high-volume transaction processing was possible. IBM, recognising the commercial opportunity, took the underlying technology and built a generic version called PARS — Programmed Airline Reservation System — and sold it to other airlines. Sabre’s TPF operating system (Transaction Processing Facility) became the standard substrate on which the entire industry was built.

The result is that today’s “competing” travel systems are, in deep structural terms, cousins running variations of the same 1960s technology. Sabre processes nearly 70 million transactions per day. Amadeus, the second-largest, handles a similar scale. Travelport, which owns Galileo and Worldspan, makes up most of the remainder. Together they constitute one of the most important pieces of infrastructure in the global economy — the silent layer through which travel itself becomes possible.

The travel agent’s green-screen terminal, with its cryptic command codes and 256-character data fields, is a direct visual descendant of Sabre’s original mainframe interface. Modern graphical interfaces have been added on top, and many agents now click between text and visual views. But the underlying language — the codes that actually instruct the system — has not fundamentally changed in sixty years.

Why nothing has replaced it

The honest answer to why the travel industry still runs on 1960s-derived infrastructure has nothing to do with the systems being secretly superior, or modern alternatives being technically incapable. Both of those explanations get repeated in popular write-ups and neither is right.

The actual reasons are more mundane and more powerful.

First, the systems work. Sabre and its peers have been continuously developed for six decades. They handle enormous transaction volumes reliably, with uptime measured in nines. The cost of any failure is catastrophic — a multi-hour Sabre outage in 2024 stranded thousands of passengers worldwide and dominated international news. Asking the industry to bet its operations on a replacement is asking it to take a risk no rational executive would take voluntarily.

Second, the systems are deeply, intricately entangled. Sabre doesn’t just hold flight inventory. It connects to airline pricing engines, frequent-flyer databases, hotel chains, car rental networks, regulatory reporting systems, payment processors, fare-filing services, and the booking systems of hundreds of thousands of travel agencies worldwide. Replacing the core requires either replacing all of those connections at once or maintaining compatibility with infrastructure designed half a century ago.

Third, the migration cost is enormous. Sabre itself has been actively modernising for more than a decade — moving code to cloud infrastructure, replacing middleware, rebuilding components in microservices. As of 2019, roughly 11% of Sabre’s code still ran in on-premises data centres, with the rest having migrated. That migration cost billions and is still ongoing.

The modernisation is real. The pace is glacial because the alternative — getting it wrong — is unthinkable.

Why this story matters

The travel-industry mainframe story sits next to the COBOL banking story as one of the two clearest examples of a broader truth about technology: some infrastructure, once embedded deeply enough, simply never gets fully replaced. It gets layered over. It gets wrapped. It gets gradually modernised, piece by piece, over decades. But the underlying bones remain.

When you book a flight on a smartphone in 2026, you are touching software with multiple distinct geological layers. The app on your phone might be three months old. The booking API behind it might be two years old. The pricing engine might be ten years old. The inventory system might trace its design directly to the mid-1960s, when American Airlines clerks were still shuffling cards on a circular table and a man on a flight from New York to Los Angeles convinced IBM to help him do something better.

That conversation was 73 years ago. The system it produced is still running. And on the day you read this, it processed, somewhere in the world, a booking you made — quietly, reliably, invisibly, exactly as it has been doing for six decades.

Subscribe to our newsletter!

Our latest tutorials delivered straight to your inbox

Make Tech Easier Editorial Team Avatar

Read next

In 1997, a team of engineers hid an entire flight simulator inside the code of Microsoft Excel as an unlisted “Easter egg” — and to this day, it remains one of the most sophisticated pieces of hidden software ever secretly shipped to millions of corporate computers
A 65-year-old programming language called COBOL still quietly processes over $3 trillion in banking transactions every single day — and because the original engineers are rapidly retiring, banks are scrambling to pay younger developers fortunes just to keep the ancient infrastructure from breaking
Stanford scientists just built a room-temperature quantum device that uses “twisted light” to connect electrons and photons — an long-sought breakthrough that could finally take quantum computing out of extreme sub-zero labs and into everyday devices
When Microsoft was developing Windows 95, developers discovered that SimCity had a severe memory bug that caused it to crash on the new operating system—but instead of forcing the game studio to fix it, Microsoft engineers actually rewrote the core Windows 95 source code to detect if SimCity was running and safely allocate memory for it.
The first computer bug was a literal moth, pulled out of a relay in a Harvard computer in 1947 and taped into the logbook with the note “first actual case of bug being found” — and the logbook is still preserved at the Smithsonian
Latest Windows Update Problems and How to Fix Them
I Replaced Claude Code With Codex, And I Should Have Done It Sooner
OneCommander Is a Great File Explorer Alternative for Power Users