Skip to main content

Software Escrow – Debunking Myths & Overcoming The Challenges

Published on 13/01/2020

As one of the UK’s leading Software Escrow agents, we’ve heard every myth, challenge and reason in the book why Software Escrow isn’t at the top of your priority list.

In almost 20 years working alongside organisations to protect their continuity, we’ve seen some frightful scenarios resulting from a lack of awareness and understanding surrounding Escrow and why it is important. 

This includes high profile multinational businesses jeopardizing themselves by outsourcing development of critical applications but not implementing Escrow protection, Escrow contracts with the Escrow agents indemnity limited to the cost of the agreement and organisations declining further validation services only to find that the developers have deposited the wrong code.

Below we have outlined six of the most popular myths and challenges our customers raise surrounding Escrow protection to help you overcome them and ensure you can protect the continuity of your business.

1. “Our software owner is too big to fail”

There are a few variations to this myth: “they have been around for many years”, “everyone uses them”, “they are a global organisation” etc. However, none of these factors are guarantees of continuity and no business – end user or software developer is too big to fail. Their industry, size, market share, turnover or even media coverage is irrelevant, and it only takes one unforeseen circumstance to cripple a business.

A prime example of this is 2e2 Limited – System Integrators and Data Centre for 1000’s of well-known global organisations that included Vodafone, NHS Trust, Citigroup, O2 and Kellogg’s, entered into voluntary liquidation in 2013. What followed was the administrators asking 2e2 customers for nearly £1 million in funding if they wanted uninterrupted services and access to their Data Centre facilities.

This is a unique case and most administrators wouldn’t allow you the opportunity to continue. With an Escrow agreement in place, you would be able to legally access a copy of the source code (as well as potentially their data, a runtime, version, install version and a runtime report on how to rebuild it etc.) for the applications provided by your developer, enabling you to maintain your applications going forward.

2. “You can’t place hosted software into Escrow (SaaS)”

This misconception comes from the belief that if the application isn’t installed on-site then how can it be placed into Escrow?

At SES we’ve witnessed a significant increase in the number of organisations using SaaS applications. To ensure that these applications are protected, SES has developed an intuitive SaaS Escrow solution which captures regular backups of application data which can occur as often as the data changes (daily, weekly and monthly) and are stored in Escrow alongside the source code and runtime files.

3. “We wouldn’t be able to use the code if it was released”

If your Escrow deposit hasn’t been fully validated, then yes it would be unclear whether the code was complex or correct. However, having the deposit fully validated and having a complete build guide ensures that you or an appointed third party can accurately redeploy and maintain the application post-release. 

4. “You have to have all your applications in place and tested”

Software Escrow protection is designed for applications which are business critical, bespoke, highly customised or revenue-generating. When deployed effectively it ensures an end user can retain access to their critical applications should the developer no longer be able to support them.

With that in mind, an audit should be undertaken on each of your applications to determine their criticality, enabling you to make an informed decision on whether to Escrow the application.

If you do have multiple applications which require Escrow, you can also place these under a Master Escrow Agreement which consolidates all your Escrow agreements in one location.

5. “We don’t see it as value for money”

The most accurate way to determine the value of Software Escrow protection is to identify their criticality and cost of your application Vs the cost and impact of not having it at all and the combined cost, time and effort you would need to spend procuring an equivalent replacement application. By definition, an Escrow agreement also reduces the amount of money needed to be set aside to potentially replace a failed system.

6. “We use a scoring system when procuring a new software owner”

This is a crucial part of procuring any third-party software, but a ‘scoring system’ can only mitigate so much risk, generally for the short-term visibility.

However, there is no way of predicting what will happen in the long term and therefore the creation of an Escrow agreement should be an essential requirement when working with third-party software owners to protect you from unforeseen circumstances.

These are just a handful of the more prominent myths and challenges to introducing Software Escrow protection we hear from our customers. Escrow is no longer about casting fear and doubt, setting up an Escrow Agreement is now considered good practice and makes your organisation more attractive to prospective customers as it shows you have taken the necessary steps to prepare for the unexpected, especially if you provide cloud-based applications.

If you would like to find out more about how Software Escrow protection can protect your business, please get in touch to speak to one of our specialists. 

 © Financechain Limited trading as SES and ses-escrow.co.uk, 2019. Unauthorised use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Financechain Limited trading as SES and ses-escrow.co.uk, with appropriate and specific direction to the original content.  

Speak to a specialist

Please use the form below to get in touch, one of our specialists will get back to you within one business day.