Modernisation without the rip and replace.

The two failed strategies

Strategy one is rip and replace. Buy a modern platform, whether a cloud-native PMS like Mews or Cloudbeds, a modern CRS, or a new mid-office suite, migrate every workflow across, and sunset the old system inside eighteen months. This has essentially never worked in travel on the timeline promised, and the reason is not that the new platform is bad. It is that the custom modules on the old system were custom for a reason, usually a regulatory quirk in one market, a loyalty calculation nobody wrote down, or an integration only ever documented in one departed engineer's head. The reason is still there. The new platform does not know about it until it breaks in production, usually during the first month-end close.

The eighteen-month rip and replace also assumes a rate of change in the rest of the business that never materialises. Revenue management wants a rate change live by Thursday. Distribution wants a new OTA connection live for a promotional push next month. None of that stops so a migration programme can hit its milestones. What actually happens, in every rip and replace we have observed at close range, is the timeline slips to thirty, then forty months, the executive sponsor moves to a different role, and the programme is quietly descoped into a partial migration leaving both systems running, or cancelled outright after a nine-figure spend, with the mainframe still running the parts nobody wanted to touch.

Strategy two is the strangler fig pattern, named for the vine that grows around a host tree and eventually replaces it. Wrap the old system in an API layer, route new features through the wrapper, deprecate the old system's direct interfaces over time. This is the pattern every serious architecture book recommends, and it works considerably better than rip and replace, but in practice it usually stalls halfway. The wrapper becomes a new system to maintain, with its own on-call rotation and backlog, and the old system keeps accepting direct writes from other integrations nobody inventoried before the programme started, built by different vendors on different contracts over different years, none appearing on any architecture diagram anyone can find.

The failure mode is subtle, and it is why so many CIOs distrust the pattern even though it is directionally correct. The vine is supposed to eventually replace the host tree. In travel, it rarely does, because the cost of finding and closing off the last few direct integrations grows faster than the appetite to fund it. You end up with a wrapper, a legacy system, and the original direct writes, three systems where you meant to end up with one.

The third strategy, which does work

The strategy that actually works in travel is boundary and contain. Do not wrap the old system intending to eventually replace it. Do not migrate it. Draw a hard boundary around it and enforce that boundary in code, permanently, as a design decision rather than a transitional stage. Every read from the old system becomes a contract, a defined interface with a schema that does not change without a versioned release. Every write becomes a queue, not a direct call, so the old and new systems' availability are no longer coupled. Every side effect, a booking confirmed, a folio posted, a rate changed, becomes a documented event other systems can subscribe to without knowing anything about the old system's internals.

Inside the boundary, the old system keeps doing exactly what it has always done, at whatever pace its architecture allows, on whatever hardware it has always run on. Outside it, new systems, a pricing engine, a guest data platform, a loyalty ledger, move at their own pace and use whatever technology their team prefers, because none of that choice touches the legacy system's stability. The old system does not get modernised in the sense the vendor slide means. The business does. That distinction is the entire argument.

This is a bounded context in the Eric Evans domain-driven design sense, applied deliberately rather than discovered by accident, which is usually how legacy boundaries end up in travel systems today, jagged and undocumented after twenty years of point integrations. Drawing the boundary on purpose, with an explicit event schema and contract, converts an accidental, brittle dependency into a deliberate, stable one. It is less exciting to describe in a board deck than ‘cloud migration’, which is why businesses that adopt it stop having modernisation programmes that need renaming every eighteen months.

The architecture pattern underneath this, in nearly every implementation we have built or reviewed, is change data capture feeding an event stream. A CDC connector, often something like Debezium sitting on the legacy database's transaction log, reads inserts and updates without touching the legacy application code at all, and publishes them onto a message bus, Kafka in most large deployments, RabbitMQ in smaller ones. New systems subscribe to that stream. The legacy system never knows they exist. It is the least invasive way to put a boundary around a system you are legally or operationally unable to modify.

What that looks like in a booking stack

Take a mid-sized hotel group running an ageing on-premise PMS alongside a GDS connection for corporate and travel agency bookings. The PMS stays exactly where it is, on the hardware it has always run on, with the same nightly batch jobs the operations team has never dared touch. It is wrapped, not in the strangler fig sense of eventually replacing its interfaces, but in the boundary sense of exposing a single, stable service that owns every read and write. That service publishes every booking event, every check-in, every folio posting, to a message bus the moment it happens, using an event-sourced log other systems can replay from any point in time to rebuild their own state.

A modern pricing engine, running on IDeaS or Duetto or a custom-built model, reads from that bus, computes a rate using signals the PMS was never built to consume, weather, competitor rates from Booking.com and Expedia, group booking pace, and writes the rate back through the same service, never touching the PMS database directly. A guest data platform reads from the same bus and feeds a loyalty engine that credits points, again writing back only through the boundary. If the pricing engine has a bad deploy on a Tuesday morning, the PMS keeps taking reservations, because the two were never coupled at the database level.

The GDS side of the estate follows the identical pattern. The session manager holding that socket open to the mainframe stays exactly as it is, wrapped in a service that translates the GDS's native message formats into the same event schema the rest of the business already understands, and increasingly translates newer NDC-based offers and orders into that same internal language so downstream systems need not know whether a booking arrived via the classic GDS pathway or a modern NDC aggregator. If the GDS connection drops during a maintenance window, which it will, the message bus holds the backlog and replays it once restored, and nothing downstream needs telling there was an outage at all.

None of this requires touching a line of the legacy codebase, which is the point and why boundary and contain succeeds where the other two fail. It does not depend on understanding, refactoring, or migrating code the people who wrote it left a decade ago. It depends on the legacy system's behaviour at its edges, a knowable, observable thing, rather than its internals, which frequently are not, and it is the same reason our capabilities in this area sit closer to integration engineering than to classic migration consulting.

The economics

Rip and replace, in every large modernisation programme we have reviewed the post-mortem for, costs upwards of eighteen months, a delivery team of thirty to fifty once integrators and client staff are counted, and a chief executive's political capital, because the programme inevitably needs re-approval when the timeline slips. The failure rate, measured as programmes that miss their original scope and timeline, sits well above half in our experience, before counting the ones quietly rescoped and never reported as a failure at all.

Boundary and contain costs, in every implementation we have run, something like four to eight months for the first bounded context, a team of six to ten with someone senior enough to own the event schema, and considerably less political capital, because nobody has to promise the board the mainframe is going away. The old system will still be there in five years. That is not a compromise, it is the plan working. What the business buys is the freedom to move the pricing engine, loyalty ledger and guest data platform at whatever speed the market demands, without asking a legacy vendor who, often, has not shipped a substantive release in years.

The cost of failure differs sharply between the two. A failed rip and replace typically means a written-off nine or ten-figure investment, a legacy system still in place, and an organisation more resistant to the next attempt because the last one burned every stakeholder who backed it. A failed early attempt at boundary and contain usually means one bounded context needing its event schema redesigned, a cost measured in weeks, because the blast radius was deliberately kept small by the same architecture that makes the approach work when it succeeds.

There is a discipline question underneath the economics that most business cases skip. A boundary and contain programme has to be evaluated context by context, not as one large capitalised project, which means finance teams used to a single multi-year budget line must learn to fund a sequence of smaller initiatives instead. That is an organisational change, not just a technical one, and it is often the real reason a board reaches for rip and replace even after seeing the numbers: one big number is easier to approve once than ten smaller ones on an ongoing basis, even when the ten add up to less.

Where the mid-office and the DCS fit in

Two systems in the travel estate get skipped in most modernisation conversations because nobody enjoys discussing them, and both are exactly where boundary and contain earns its keep. The mid-office, the reconciliation layer between booking systems and the general ledger, is usually the single most brittle piece of software in the stack, built to paper over differences between however many booking sources feed into it, each changed at least once since the mid-office was written. Wrapping it in a boundary, with every reconciliation input arriving as a well-defined event rather than a nightly file drop nobody documented, does more to reduce operational risk than almost any other single move available.

Legacy is retired when nobody reads it any more, not when someone replaces it. The boundary service is how you get there.

The departure control system at an airline is the other. A DCS is about as far from a system anyone wants to touch as exists in the industry, because it is directly load-bearing for getting aircraft off the ground on schedule, and tolerance for a modernisation programme introducing a new failure mode is, correctly, close to zero. Boundary and contain lets an airline build modern crew and baggage systems that consume DCS events without ever proposing to touch the DCS itself, usually the only modernisation conversation a DCS owner will agree to have at all.

Oracle Opera sites, and the older Micros-derived estates many hotel groups still run pieces of, present a related version of the same problem: deep customisation accumulated across two decades of acquisitions, each with its own PMS instance before consolidation, none of which anyone has the appetite to migrate wholesale. A boundary drawn around each instance, publishing a common event schema regardless of which PMS version sits behind it, lets a hotel group build one guest data platform across a genuinely heterogeneous estate without waiting for a consolidation programme that, realistically, is not going to finish this decade.

The pattern generalises past travel but is unusually well suited to it, because the industry's core systems of record, GDS hosts, PMS platforms, DCS software, were mostly built assuming a stable, slow-changing world of a small number of large suppliers, an assumption that has not held for fifteen years. Boundary and contain accepts the old systems will keep being slow and stable, and builds the fast-changing parts of the business somewhere else, connected only by a well-defined event contract.

The four questions to ask before the next modernisation slide

First, what is the smallest change to the legacy system's interface that lets every new system stop caring about its internals. If the answer involves a queue, a documented event schema, and a service that owns the boundary, you have a workable plan. If it is a multi-year migration with a single go-live date, you have a slide, not a plan.

Second, has anyone inventoried every system that writes to the legacy platform directly, not just the ones on the current architecture diagram. Strangler fig fails almost every time on this question, because the direct writes nobody found are what keep the old system's coupling alive long after the wrapper goes live. This inventory work is unglamorous and is also the single most valuable week of effort in the programme.

Third, can the first bounded context ship in under six months with a team under ten people. If the first slice cannot be scoped that small, the boundary has been drawn in the wrong place, usually too large, and needs redrawing before any code is written, because a six-month, ten-person failure is recoverable and an eighteen-month, forty-person one usually is not.

Fourth, does finance understand this is a sequence of investments, not one, and has the budgeting process been adapted to fund it that way. If the only way to get this funded is as a single large capitalised programme, the funding model will eventually push the team back towards rip and replace, regardless of what the architecture review recommended.

What this looks like in practice

A regional airline group came to us with a familiar mandate from a new chief executive: modernise the passenger service system estate within two years. Their PSS, hosted in partnership with one of the major GDS providers, ran reservations, inventory, and departure control across three sub-brands acquired over the previous decade, each with slightly different fare structures and none with documentation anyone still at the company had written. The original plan, inherited from the previous administration, was a full PSS migration to a newer hosted platform, budgeted at just under three years and a nine-figure sum.

We proposed cutting the migration entirely from the first eighteen months of the roadmap and starting with a boundary around the PSS's booking and inventory functions, using a CDC layer reading the PSS's transaction feed and publishing booking, cancellation and schedule change events onto a Kafka cluster the airline's own platform team would own outright. The first bounded context, scoped deliberately small, was ancillary revenue: seat selection, baggage and lounge access, none of which needed to touch fares or inventory logic directly, all reading live seat maps and booking state off the event stream.

That first context shipped in five months with a team of seven. Ancillary revenue per passenger rose measurably within the first two quarters, driven mostly by a faster seat selection experience the old PSS's native booking flow had never rendered properly on mobile. More importantly for the mandate, the airline now had a working, observable event stream carrying every booking and schedule event, which became the foundation for the loyalty rebuild that followed, and the revenue management modernisation after that, each funded and scoped as its own small programme rather than a slice of one enormous migration.

Eighteen months in, the original PSS is still running the same fare and inventory logic it ran on day one. Nobody at the airline describes this as a problem any more, including the chief executive who arrived wanting a migration. The conversation moved, over the space of a year, from ‘when do we replace the PSS’ to ‘what else can we build on the event stream’, the actual sign a modernisation programme has succeeded, whatever the original slide promised. Businesses evaluating a similar path should also read our note on why revenue, distribution and loyalty need to converge into one system, because the event stream this pattern produces is usually the fastest route to that convergence, and our approach explains why we scope the first bounded context as a fixed-price pilot rather than a phase of a larger programme.