Introduction: a generational shift in airline IT
Airlines are in the midst of a generational shift in their IT systems as they move from legacy GDS and PSS platforms to a future state based on the NDC and One Order initiatives. The goal: a modern, dynamic retailing environment that allows airlines to serve their customers with personalised, transparent product offerings.
Achieving this requires an extensive airline digital transformation project to replace systems and processes which in many cases have their origins in the mid-to-late Twentieth Century era of paper ticketing.
This article looks at what this means for the airline legal teams lawyering retailing transformation projects. In particular, it focuses on the pitfalls and obstacles in airline IT contracts that can cause avoidable turbulence along the way.
The central message for airline legal teams is straightforward. Your technology providers for next generation systems will need clear rights to access your existing systems and the data they generate. They will need this to develop and configure their own systems. You should keep a weather eye on contract restrictions that will interfere with this.
Understanding the legacy IT stack
Each airline’s Passenger Service System (“PSS”) – the software platform composed of a reservation system, and inventory and departure control systems – is unique. The way it works and its complexity will depend on the nature of the airline. For example if the airline is a full-service or low-cost carrier, if it runs a loyalty programme, or if it has interlining arrangements. The PSS may have been built and managed in-house. Some or all of it may have been outsourced.
The PSS will ingest important data from third-party sources. Data may come from one or more of the airline’s Global Distribution Systems (“GDS”). Interline, codeshare or loyalty data may be received from alliance partners. Other data sources may include real-time flight and weather data.
It will interface with other IT systems, often via proprietary or third-party APIs. A good example is the integration between a PSS and a third-party payment services provider, allowing the airline to take payment from a customer. Airlines will also be under regulatory obligations to communicate advance passenger information to immigration authorities. The big picture is that a PSS can interact with dozens of internal and third-party systems.
For the legal team, the first step in the process is to understand the third-party dependencies that underpin the PSS. This means identifying and reviewing contracts, which in some cases may be years or decades old and which may not contemplate (or may even actively restrict) a move away from the status quo.
An important point is to consider how these third-party relationships will play out over time. The move from legacy to future state may take several years. A major project is likely to happen in phases, with systems and functions moving piece by piece. To manage risk an airline may also choose to run its old and new systems in parallel for a time. This will have implications particularly for contract renewals for legacy services and it is clearly a good idea to negotiate out restrictive contract terms before agreeing a lengthy extension. To get this right, the legal team needs to have the full picture at the start.
Sorting out the contract puzzle
The contracts underpinning the legacy PSS will to a large extent be software contracts of some kind. This could be software ‘as a licence’ for on-prem systems or ‘as a service’ for any cloud-hosted parts. As such, they will probably take their cue from the world of commercial software contracting: software will be licensed primarily for the “internal business purposes” (or similar) of the airline. This general approach – along with other related restrictions and conditions common in IT contracts – can cause problems when the core object of the project is to move to new systems and new vendors. In practice, an overlooked contractual restriction on using some part of a software system or data for a new purpose can present a significant barrier.
Some key contract points to look out for:
- Rights in relation to “Airline Data” – this will be a key point if some/all of the PSS is hosted by a vendor or in the cloud. The airline must be able to export relevant data from the old system and migrate it to the new one. This means the airline should resist contractual restrictions that obstruct this right. The optimal position is a clear positive right backed up by an unambiguous IP position (generally: as between the parties, airline owns all IP rights in / in relation to “Airline Data”).
- Prohibited use of software, services and APIs – in addition to granting a licence or rights to an IT system for a specified use, a third party may also seek to restrict an airline’s usage rights. These kinds of prohibitions can take a range of forms and crop up in different parts of a contract. A few examples: restricting the categories of people who are allowed access to a system – e.g. employees, consultants, competitors. If an airline’s retailing transformation project involves the use of external consultants, do they fall within the contract definition of “Authorised Person”? If not is there a cost implication to granting access, or can access be denied altogether? What about a contractual provision that restricts the use of data, a software system or an API for a competitive purpose?
- Other ‘indirect’ restrictions – express prohibitions on use can be easier to spot. Airlines also need to be wary of contract terms that can interfere with their objectives in less obvious ways. Clauses dealing with intellectual property rights and confidentiality are good examples. Taking confidentiality: contractual definitions of “Confidential Information” can be expansive and vague. In software contracts it is common for certain categories of information to be stated to be “Confidential” or “Proprietary” to one party or another. Such information would then be subject to the contract’s confidentiality obligations: an obligation to maintain confidentiality and express restrictions on disclosure to third parties outside a narrow category of “Permitted Disclosees” (e.g. employees or an airline’s “Affiliates”). Rights like these can be asserted to prevent an airline from using one system in another context or with new vendors. Again, as well as removing any unacceptable restrictions, the ideal situation from the airline’s perspective is to negotiate clear, positive rights to give the flexibility it needs.
- Exit provisions – important IT contracts often contemplate what will happen at the end of the relationship. For perfectly understandable reasons these “exit provisions” are often given limited attention during negotiations, when the parties’ main priority is to get the contract over the line. But by the same token they become more important at the end of the contract, at the point the airline is planning how to manage the risk of migrating an important function to a new system without causing operational disruption. What kinds of things should airlines consider here? A few suggestions: managing timing risks – instead of a hard termination date say three years into the term, does the airline need a right to call for extensions? Access to up-to-date documentation and specifications which the airline can then disclose to third-party consultants / the new vendor (see ‘indirect’ restrictions above)? What about a more general obligation for the outgoing vendor to co-operate with the incoming one (e.g. via participation in a migration committee, attending scheduled meetings, responding to information requests)?
A quick word on “background” law
Finally, airline legal teams are thinking about their rights (and the duties of their third-party vendors) under “background” law. By “background” law we mean the rights and duties that are imposed by statute, rather than contained in a contract. This is especially relevant for airlines based in (or with operations / vendors in) the EU, which has been remarkably active in regulating IT in recent years as part of the “European Strategy for Data” (here). EU Regulations and Directives which have been a long time coming – e.g. the Data Act, the Data Governance Act, the AI Act – are now taking effect.
There is much detail in the new rules, but at a high level they introduce new rights and duties which could be advantageous to airlines trying to smooth out the journey to NDC / One Order.
A good example is the Data Act, an EU Regulation which applies from 12 September 2025.[1] Among other things, this contains:
- A new unfair contract terms regime for businesses. This provides that certain contract terms “concerning access to and use of data” which are “unfair” are not binding. There is much to be seen about how these rules will work in practice, but they are likely to be helpful to airlines migrating data from one system to another. See our separate article on this here.
- Detailed provisions designed to make it easier for businesses to move from one “data processing service” to another and to pursue a multi-cloud strategy through the “in-parallel use” of different data processing services. See our separate article on this here.
Another EU initiative of interest is the European Mobility Data Space, which aims to provide a common technical and governance framework to enable interoperability and remove barriers to data access and sharing in the mobility and transport sectors (here). If not done already, a good starting point for airline legal teams will be to familiarise themselves with the new rights, duties and opportunities under these legal and policy frameworks.
[1] Regulation (EU) 2023/2854 (here)
