Cases Study: Learn how a SaaS escrow agreement saved an international airline from disaster USA

Airline’s SaaS booking system vendor goes bust:
Escrow London was approached by an international airline to arrange a SaaS escrow solution for their web-based booking system, which was supplied to them by a small SaaS vendor. The software provided the end-to-end management of customer flight bookings and seat allocations. This was deemed a business-critical application for the airline.

Escrow London provided a SaaS escrow continuity model where the production environment was replicated to an independently managed Escrow London Amazon Web Services (AWS) account. The entirety of the source code, databases, deployment scripts and documentation also formed part of the solution deposit.

Only a few months into providing the service, the SaaS vendor entered into bankruptcy and Escrow London was immediately notified by the airline. The Escrow London technical team mobilized and were able to bring up the dormant AWS escrow account managed by Escrow London into a live status.

This enabled the airline to seamlessly provide all necessary services to their customers without any interruption to their business or the revenue stream attached to these functions. After several months of continuing to support the AWS services, Escrow London successfully transferred the entire system and all associated deposit materials that formed part of the solution over to the airline to manage internally.



The Escrow London team of AWS certified architects and code specialists consulted with the airline to implement a bespoke Replicated SaaS Continuity solution that best addressed their concerns. The main aim was to provide the airline with complete continuity in the unlikely event of a release scenario. Several critical instances needed to be protected and replicated. The final implemented solution included:

  • Complete source code deposit of the airline booking engine automatically synced on a nightly basis via the developer’s GitHub repository.
  • Scheduled deposit of an encrypted copy of the application database.
  • Deposit of the airline AWS cloud environment and CloudFormation deployment scripts.
  • Full Verification test on the source code to ensure that it could be built into the working application.
  • SaaS Release Verification to demonstrate that Escrow London had the ability to spin up and host a replicated booking engine environment including the database within a dedicated Escrow London AWS account.
  • Vendor Financial Monitoring provided the beneficiary with pre-emptive alerts if there were any irregularities with the payments to AWS.

saas diagram

Escrow London and the SaaS developer collaborated to ensure that all the required source code, databases, deployment scripts, detailed build documentation and AWS instances were available to be securely deposited. Two in-depth verification exercises were then conducted as part of the Replicated SaaS Continuity solution to successfully confirm that the deposited source code was full and complete and that the booking engine application was replicated successfully within the dedicated Escrow London AWS map


The secondary escrow environment hosted by Escrow London within their AWS account was successfully deployed during the SaaS release verification exercise. Representatives of the airline were invited to join the testing session via Webex allowing them to fully test the functionality of the replicated environment from the comfort of their own office. This SaaS escrow solution was now an integral component of the airline Business Continuity Plan (BCP).

A true measure of success of any Business Continuity Plan is when it is put to the test in a real-life high-pressure event.

So, what happened?

After a few years of operations, the developer had run out of money due to unpaid debts to the IRS. A decision was made by the company director of the SaaS vendor to appoint a trustee in the hope of salvaging the company or finding an investor. Under the terms of the SaaS escrow agreement, appointing a trustee constituted a trigger event. The airline management contacted Escrow London to work through the release process.

The release process involved securing immediate consent from the appointed trustee to allow for the escrow to be released to the beneficiary according to the terms of the SaaS escrow agreement. The escrow environment hosted within AWS was brought online and the DNS of the production environment was shifted to the escrow environment managed by Escrow London.

All the applicable source code, scripts and documentation were transferred to the airline which allowed them to appoint a new developer to maintain the code and system.

The airline continued operations uninterrupted on the escrow environment without missing a single reservation. After a 90 day period in which Escrow London managed the AWS environment, the entire booking system was transferred to the airline to continue to maintain the system internally.

The SaaS escrow agreement the airline had in place with Escrow London clearly saved them from a massive outage and ultimate financial disaster. SaaS applications in their nature are complex as they include many components, third party applications and customer data.

To the best of Escrow London’s knowledge, this was the first live release of a SaaS escrow environment within AWS anywhere in the world.