The old platform followed a tenant-per-CMS-instance model. Each airline had its own Umbraco instance, its own branded website, and its own operational setup.

That worked for a while, but it became increasingly difficult to maintain. User management, content management, configuration, deployment, and platform updates had to be handled repeatedly across separate instances. At production scale, the client was operating seven airline websites through seven CMS instances.

Each airline had different branding, domains, catalogues, languages, layouts, and features. There was no shared content between airlines, so the platform still needed strong tenant separation. But the operational model around that separation needed to change.

The API layer also had to evolve. The legacy API was split across multiple areas such as movies, audio, games, flights, and supporting services. The old sync process pulled data from client systems, and the growing product requirements made that model harder to extend.

A big-bang rewrite would have been too risky. The old and new systems had to run side by side while functionality was replaced step by step.

We started by analysing the existing API and its business areas: movies, audio, games, flights, and supporting services.

That analysis showed that we did not need to migrate everything at once. The platform could be modernised incrementally. We could replace one API area at a time, plug new services into the existing sync pipeline, and allow old and new parts of the system to coexist during the transition.

We chose a microservices architecture so each business area could be separated and migrated independently. Azure API Management helped route traffic while old and new APIs were running side by side.

The first services were introduced into the existing flow, starting with flights, then films, and eventually the remaining API areas. In total, six API services were replaced.

This phased approach reduced risk. It allowed the product to keep running while the underlying architecture changed around it.

After the API migration, we moved deeper into the sync and admin parts of the platform.

The old sync process was based on API polling. It pulled data from client systems and synchronised content such as movies, audio, games, and flights. Some data also came through manual upload processes.

We redesigned the sync process to be event-driven. Events coming from the client’s systems triggered downstream processing instead of relying only on repeated API pulling.

The new sync platform also introduced more options for enriching synchronised data before it reached passengers. Teams could add tags to movies, fill missing translations, replace low-quality images, and prepare content more reliably for airline-specific use cases.

Synced and enriched data was stored across the platform: in the CMS, backend databases, and search indexes, depending on how it was used by the passenger website, APIs, admin workflows, and third-party consumers.

The client also needed a modern admin experience, but replacing every old admin function at once would have created too much disruption for users.

We built the new admin in React and embedded selected legacy admin views through iframes. That gave users one place to work, while old functions were gradually replaced behind the scenes.

The same roles and permissions model was preserved, so users did not have to learn a separate access model during the migration.

Over time, old functions were migrated into the new admin and new required capabilities were introduced. The admin became both a product improvement and a practical bridge between the old and new platform.

The CMS migration was one of the most important architectural changes.

The old platform used Umbraco 7.15, with one Umbraco instance per airline. There was no official direct migration path from that version to the modern target version, so the CMS layer had to be redesigned rather than simply upgraded.

We moved to a headless CMS model using modern Umbraco, initially version 14 and now version 17. Instead of running one CMS per airline, the new platform uses one CMS instance capable of handling all tenants.

Each airline still gets its own branded website, domain, catalogue, languages, layout, and feature set. But the operating model is simpler: one CMS platform, multiple tenants, and clearer separation between content management and passenger-facing rendering.

The passenger-facing websites were rebuilt with React and Next.js. This removed the need for custom rendering stitched into old Umbraco pages and avoided many of the previous server-side versus client-side rendering problems.

The result was a cleaner architecture: Umbraco manages content, the frontend renders the passenger experience, and APIs provide structured access for websites, onboard and off-aircraft scenarios, and third parties.

Streaming was one of the key reasons the old system needed to change.

As part of the migration, the platform was extended with airport lounge streaming. We integrated with a streaming provider and adapted the platform so airline content could be presented and accessed in that context.

This was not just a frontend feature. It required the underlying platform to support richer content workflows, streaming-related metadata, third-party integrations, and tenant-specific behaviour.

The migration therefore did more than replace old technology. It created a foundation for new product capabilities that did not fit naturally into the legacy stack.

The modernisation also changed the hosting and operations model.

The old platform depended partly on virtual machines. The new platform is hosted fully in Azure, with no remaining VM-based application hosting.

The modernised stack includes ASP.NET Core services, React and Next.js applications, Umbraco, SQL Server, MongoDB Atlas, Service Bus, Azure Container Apps, Azure API Management, Azure B2C, Azure DevOps, and Terraform-based infrastructure as code.

This gave the client a more consistent deployment model, clearer infrastructure ownership, and a stronger base for future platform growth.

The migration is complete, the platform is live in production, and we continue to maintain it.

The client moved from seven airline-specific CMS instances to one multi-tenant headless CMS platform. Seven branded airline websites are now supported through a shared architecture while still preserving separate domains, catalogues, branding, languages, layouts, and feature sets.

Six API services were replaced, the sync process was redesigned around events, and the admin experience was modernised without forcing users through a disruptive cutover.

The platform supports more than 100,000 content records across movies, audio, games, and flights.

One of the clearest operational improvements is onboarding. Setting up a new airline instance now takes around three days. Previously, it could take around a month.

The result is a modern IFE platform that supports passenger-facing websites, third-party APIs, admin workflows, sync operations, onboard and off-board use cases, and airport lounge streaming — without carrying forward the operational weight of the old architecture.