Modernisation without the rip and replace.
Every travel business over fifteen years old has a system it cannot turn off. A PMS with twenty custom modules. A mid-office written in Java 1.4. A GDS session manager that talks to a mainframe over a socket that must not be closed. The vendor's slide says modernisation. The engineer's whiteboard says the vendor's slide has never met this system. Both are right. Neither is useful.
The two failed strategies
Strategy one is rip and replace. Buy a modern platform, migrate everything, sunset the old system inside eighteen months. It has never worked in travel. The custom modules were custom for a reason. The reason is still there. Strategy two is strangler fig. Wrap the old system in an API layer, route new features through the wrapper, deprecate the old system over time. It works in theory. In practice the wrapper becomes another system to maintain, and the old system continues to accept direct writes from three other places that were never inventoried.
The third strategy, which does work
Boundary the old system. Do not wrap it, do not replace it. Draw a boundary around it and enforce that boundary in code. Every read is a contract. Every write is a queue. Every side effect is a documented event. Inside the boundary, the old system keeps working. Outside the boundary, new systems are free to move at their own pace. The old system does not get modernised. The business does.
What that looks like in a booking stack
The GDS session manager stays. It is wrapped in a service that publishes every booking event to a message bus. A modern pricing engine reads from the bus, computes a rate, and writes back through the service. A modern loyalty engine reads from the same bus, credits a member, and never touches the GDS directly. If the pricing engine breaks, the GDS keeps working. If the GDS is down for a maintenance window, the bus holds the messages. The old system is not modernised. It is contained.
The economics
Rip and replace costs eighteen months, a team of forty, and a chief executive's political capital. Boundary and modernise costs six months, a team of eight, and a very good architect. The old system will still be there in five years. That is fine. It works. What you are buying is the freedom to move everything around it at speed, without asking permission from the vendor who has not shipped a release in four quarters.
The single question to ask
Before the next modernisation slide, ask one question. What is the smallest change we can make to the interface of the old system that lets every new system stop caring about it. If the answer is a queue, a documented event schema, and a service that owns the boundary, you have a plan. If the answer is a two-year migration, you have a slide.
We modernise travel platforms without asking clients to rip out the systems that still work. If your roadmap has a migration on it, we can probably shorten it.