A Deposit Is Not a Delivery: Making Software Escrow Work When a Supplier Fails

The comfort of a certificate

Software escrow is often bought as reassurance. A buyer receives confirmation that source code has been deposited with an escrow agent and treats a significant continuity risk as addressed. The difficulty is that a deposit is not a delivery. A collection of files held by a third party rarely equates, on its own, to a system that the customer can build, deploy, maintain and support.

English law does not imply a right to use deposited code merely because a supplier has become insolvent or stopped providing support. The buyer’s rights depend on the escrow agreement, the underlying software licence and any step-in or exit provisions negotiated at the outset. Where those documents are thin, the deposit can become a contractual ornament rather than an operational lifeline.

What the deposit usually omits

Source code is only one component of a working software estate. A buyer may also need build scripts, configuration files, infrastructure-as-code, database schemas, deployment runbooks, administrative credentials, certificates, test data, technical documentation and details of application programming interfaces. Without those elements, even complete source code can be difficult or impossible to compile into a functioning environment.

Managed services add further layers. Support depends on staff know-how, monitoring tools, incident procedures, supplier relationships and access to third-party platforms. An escrow arrangement that captures only the application code may leave the customer with the intellectual equivalent of an engine without a chassis, wiring or fuel system.

Release triggers should reflect continuity, not merely insolvency

Many escrow agreements release the deposit only on insolvency or liquidation. Supplier failure often arrives earlier and less formally. A supplier may withdraw support, lose key technical staff, sell the business, cease development of a product or fail repeatedly to remedy a material breach. In administration, a supplier may continue trading under the control of insolvency practitioners, and a release event may be disputed or unavailable at the moment the customer most needs continuity.

Buyers should define release events by reference to the continuity outcome they require. That may include administration, liquidation, cessation of the relevant business, failure to provide support for a defined period, or an unremedied material breach of the software or services agreement. The clause should identify who may request release, what evidence is required, how notice is given, how disputes are resolved and to whom the deposit is released. A neutral custodian or technical adviser can reduce the risk of the supplier blocking access.

Verification is the difference between a box and a build

A common weakness is that verification tests the existence of files rather than the usability of the deposit. A more robust arrangement requires an independent technical adviser to establish whether a competent developer, acting reasonably, can build and run the software from the deposit alone. The test should be repeated annually or at defined intervals, with clear acceptance criteria, a remediation period and consequences if verification fails.

Verification costs money, but so does discovering at the point of failure that the deposit lacks a critical library or that no one can reproduce the production build. The escrow agreement should allocate verification costs and specify whether the supplier must remedy deficiencies within a set period. If the supplier cannot pass verification, the customer may need service credits, a termination right or an accelerated release mechanism.

Updates, completeness and the stale deposit problem

Escrow is only as good as its currency. A deposit made at go-live may bear little relation to the software in use two or three years later. The agreement should oblige the supplier to deposit each new release, including major and minor versions, within a defined period. The supplier should also confirm completeness and identify any components that are not included.

Audit rights matter. So do consequences. If the supplier fails to update the deposit, the customer should have a clear remedy, whether through service credits, a right to suspend payment, a termination right or an obligation to fund independent verification. Without those levers, update obligations tend to be honoured inconsistently.

Third-party rights are often the hidden obstacle

A supplier cannot escrow rights it does not have. Critical software frequently incorporates third-party libraries, commercial components, software development kits and open-source code. The supplier may own the application layer while licensing key elements from others. Release of the source code does not automatically grant the customer the right to use those third-party components, and the escrow agent cannot grant rights that the supplier itself lacks.

The customer should require warranties that the supplier has the right to deposit the code and to grant the intended release rights. A schedule of third-party components, licence terms and restrictions should be maintained. For critical dependencies, direct licence agreements or step-in rights with the third-party vendor may be necessary. Open-source compliance should also be addressed, because a deposit that cannot lawfully be deployed is of limited value.

Pair escrow with step-in and exit assistance

Escrow works best as part of a wider continuity plan. Step-in rights allow the customer, or a nominated replacement supplier, to assume support and maintenance responsibilities during a defined period. Exit assistance should cover access to environments, data export, documentation, training, knowledge transfer and reasonable cooperation during transition. It should specify duration, charges, security standards and the standard of performance.

Data protection needs attention too. Where personal data is involved, exit provisions should address return, deletion and transition in line with UK GDPR obligations. A right to receive source code is of little use if the customer cannot lawfully obtain the associated data or operate the service in compliance with its regulatory duties.

Drafting for the day the supplier fails

The practical question is not whether code has been deposited, but whether the customer can use it. That requires a map of critical software and dependencies, release events that match realistic failure scenarios, build-based verification, disciplined update obligations and a clear route to third-party rights. It also requires a tested exit plan. A deposit may be a useful component of continuity, but it is not a substitute for one.