A software escrow agreement protects enterprise buyers from the catastrophic scenario of a vendor bankruptcy, acquisition, or product discontinuation that renders business-critical software unmaintainable. Without escrow, your organisation's dependence on proprietary source code could leave you unable to operate or maintain systems that underpin core business processes. This guide explains what escrow covers, how to negotiate meaningful protections, and how to avoid the common traps that make most escrow arrangements commercially worthless.
This article is part of our IT Contract Negotiation Strategy guide. Software escrow provisions are closely related to data portability and exit rights, termination for convenience clauses, and change of control provisions — all of which determine how much operational continuity an enterprise buyer can maintain when a software relationship ends unexpectedly. See also our software contract negotiation checklist for a comprehensive review framework.
A software escrow arrangement involves the deposit of source code (and associated materials) with an independent third-party escrow agent, who holds the deposit subject to instructions in a tripartite agreement between the licensor (vendor), licensee (buyer), and escrow agent. The escrow agent releases the deposit to the licensee only if defined release conditions (called release triggers) are met — typically events that indicate the licensor is unable to continue maintaining the software.
The commercial rationale is straightforward: enterprise buyers run business-critical applications on proprietary software for which they hold only a binary (compiled) licence. If the vendor ceases to exist or to support the software, the buyer cannot maintain, modify, or fix the software without access to the source code. Escrow provides a controlled mechanism for accessing the source code in these circumstances — subject to licence restrictions that typically limit its use to the buyer's internal maintenance of existing functionality.
The escrow framework does not give the buyer a right to use the source code for development, for resale, or for purposes beyond maintaining the existing application. It is a business continuity mechanism, not an IP transfer.
Software vendor consolidation has accelerated dramatically. Between 2020 and 2025, the enterprise software market saw over 2,000 significant acquisitions — many of which resulted in product discontinuation, forced migration, or support degradation for customers. The Broadcom acquisition of VMware (resulting in the end of perpetual licensing and the forcing of all customers onto subscription bundles) is a recent example of how an acquisition can fundamentally alter the commercial terms for existing licensees. Escrow alone does not protect against all of these scenarios, but combined with strong change-of-control and termination-for-convenience provisions, it significantly reduces operational risk.
Not every software relationship requires escrow. The business case for escrow is strongest when several risk factors combine. Buyers should seriously consider escrow when the software is genuinely business-critical (the organisation cannot operate core processes without it), the vendor is small, VC-backed, or financially distressed (where insolvency risk is meaningful), the software is heavily customised for the buyer's use case, migration to an alternative would be extremely costly and time-consuming, and source code access would genuinely enable the buyer to maintain the application independently.
Conversely, escrow provides limited value for: commodity SaaS applications where switching cost is low; software from large, financially stable vendors where insolvency risk is negligible; cloud infrastructure where the underlying compute and storage infrastructure is operated by a hyperscaler rather than the vendor; and software where the buyer lacks the internal technical capability to make use of source code even if released.
For applications in the first category — mission-critical, vendor-specific, technically complex — escrow should be treated as a non-negotiable requirement, and buyers should be prepared to walk away from contracts where vendors refuse to provide meaningful escrow protections.
The value of an escrow arrangement depends entirely on the completeness and usability of the deposited materials. The most common failure mode in software escrow is that the escrow deposit is technically present but practically useless — incomplete source code, missing build instructions, absent third-party component licences, or outdated versions that do not match the production software.
Buyers should negotiate for the deposit to include:
The update obligation is equally critical. The deposit must be updated to reflect each new production release, each major patch, and each significant customisation delivered to the buyer. A deposit that is 18 months out of date when released is of limited operational value. Contracts should specify a maximum deposit staleness period (typically 30–90 days after each production release) and an obligation to notify the escrow agent and buyer of each update.
Release triggers define the conditions under which the escrow agent releases the deposited materials to the buyer. They are the most commercially important element of the escrow framework — and the area of greatest negotiation tension.
Vendor-standard release triggers are narrow and difficult to invoke. Typical vendor language limits release to: vendor insolvency (usually defined narrowly to formal insolvency proceedings, excluding practical financial distress); cessation of business (defined as complete cessation, excluding product discontinuation or support degradation); or vendor material breach of the maintenance obligation that remains uncured for 60–90 days after notice. Each of these conditions is easy for a vendor to contest and difficult for a buyer to prove quickly enough to be operationally useful.
Buyer-favourable release triggers should include a broader set of conditions:
| Trigger | Vendor Position | Buyer Target |
|---|---|---|
| Formal insolvency (administration, liquidation) | Usually accepted | Accept; define broadly to include administration, provisional liquidation |
| Appointment of receiver or administrator | Sometimes accepted | Push to include — appointment alone, not just filing |
| Cessation of support for the licensed software | Narrowly defined (complete cessation only) | Include planned end-of-life announcement 12+ months in advance |
| Failure to provide support for 30 consecutive days | Resisted — will claim force majeure carve-out | Push hard; include carve-out only for genuine force majeure |
| Acquisition resulting in product discontinuation | Strongly resisted | Link to change-of-control clause; trigger on buyer's right not to consent |
| Material breach of licence agreement (uncured 30 days) | Sometimes accepted with 60–90 day cure period | 30-day cure period; automatic release if uncured |
| Vendor's failure to update escrow deposit within agreed period | Resisted | Include as trigger — incentivises deposit updates |
| Buyer's termination for convenience | Strongly resisted | Attempt to include — rarely achieved but worth negotiating |
Even a complete and well-maintained escrow deposit is commercially worthless if it cannot be compiled and deployed when needed. The time pressure at the point of release — typically a business continuity emergency — makes discovering that the source code cannot be built particularly costly.
Verification testing involves the escrow agent (or an independent technical firm) periodically compiling and deploying the deposited source code to verify that it can produce a working executable matching the production software. Buyers should negotiate for verification testing as a contractual right, with defined frequency (annually for critical applications), defined scope (compile, deploy, basic functionality test), and a remedy if verification reveals problems (typically an obligation on the vendor to correct the deposit within 30 days).
The cost of verification testing (typically £5,000–£25,000 per test, depending on complexity) is a legitimate business continuity cost that should be shared with or borne by the vendor for critical applications. Framing this as a quality assurance exercise that benefits both parties — and demonstrating what it would cost the buyer to remediate a non-functional deposit at a critical moment — is usually the most effective negotiation approach.
Studies of software escrow arrangements consistently find that 30–40% of escrow deposits, when tested, cannot be successfully compiled without vendor assistance. The most common failure modes are: missing or expired third-party library licences; build environment dependencies that are no longer available; incomplete source code (often because the deposit was created once and never updated); and missing configuration that is held separately from the source code. Annual verification testing is the only reliable way to catch and remediate these problems before they matter.
Traditional source code escrow was designed for on-premises software where the buyer received a binary licence to run on their own infrastructure. SaaS and cloud delivery models create fundamental challenges for escrow, because the buyer does not operate the infrastructure and the software may be architecturally inseparable from the vendor's cloud environment.
Several approaches to SaaS continuity protection have emerged, none of which is as clean as traditional escrow.
A SaaS escrow deposit should include not just source code but full documentation of the cloud infrastructure required to operate the application — including IaC (Infrastructure as Code) scripts, container images, cloud service dependencies, and configuration. The goal is to enable the buyer (or a third-party managed service provider) to reconstruct and operate the application independently in a buyer-controlled cloud environment if the vendor fails.
For SaaS applications where the software itself is less valuable than the data it holds, the escrow focus should shift from source code to data. Negotiating for automated, regular exports of the buyer's data in open, documented formats is more operationally important than source code access. See our data portability guide for detailed negotiation tactics on this point.
As an alternative to SaaS escrow, buyers can negotiate an operational continuity obligation — requiring the vendor to continue operating the SaaS service for a defined period (typically 12–24 months) following a triggering event, to allow the buyer time to migrate to an alternative. This is often more practically valuable than source code access, which few enterprise IT teams could deploy in an emergency.
Software vendors resist meaningful escrow provisions for understandable commercial reasons — source code represents their core IP, and release triggers that are too broad could expose it inappropriately. Buyers should be prepared for the following resistance patterns.
"Our escrow arrangements are standardised." Many vendors offer pre-negotiated escrow arrangements with specified escrow agents, at defined fees, with standard release triggers. These standardised arrangements almost always favour the vendor. Buyers should review the actual escrow agreement — not just the vendor's summary — and negotiate amendments where the standard terms are inadequate.
"Escrow is not appropriate for cloud/SaaS." There is a kernel of truth here, but vendors use this argument to avoid any form of continuity protection. The response is to acknowledge the architecture difference while insisting on equivalent protection through SaaS-specific mechanisms (data portability, operational continuity periods, IaC documentation escrow).
"We're a well-capitalised company — insolvency risk is negligible." Even financially stable vendors can be acquired, can discontinue products, or can make commercial decisions that are operationally damaging to customers. The risk being managed is not only insolvency.
"Escrow is very expensive." Basic escrow arrangements cost £2,000–£8,000 per year in escrow agent fees. For business-critical software with multi-million-pound contracts, this is a commercially trivial cost that vendors should bear or share.
Is your mission-critical software properly protected?
NCC Group Escrow (formerly EscrowTech) is one of the leading independent escrow agents for enterprise software, with strong capabilities in both traditional source code escrow and technology escrow for cloud environments. They offer standardised tripartite agreements and verification testing services.
Escrow London (now part of Primus Solutions) is a UK-based specialist with significant market share in enterprise software escrow arrangements. Their verification testing capabilities are particularly strong for complex applications.
Iron Mountain provides escrow services as part of their broader data management and records management offering. Their scale and geographic coverage make them appropriate for multi-jurisdiction arrangements.
SaaS Escrow services offered by firms such as Axway and cloud-native escrow providers have emerged to address the specific challenges of SaaS continuity protection, offering managed data export, configuration documentation, and operational continuity services.
When specifying the escrow agent in a contract, buyers should ensure the agent is genuinely independent, has appropriate financial stability of their own, carries professional indemnity insurance, and has technical capabilities sufficient to conduct meaningful verification testing for the relevant application.
| # | Tactic | Application |
|---|---|---|
| 1 | Make escrow a condition of signing | For business-critical applications, establish escrow as a hard requirement from the outset — not a nice-to-have that gets dropped under time pressure |
| 2 | Review the actual escrow agreement, not just the summary | Vendor escrow summaries are invariably more favourable than the underlying agreement; always review and negotiate the full tripartite escrow deed |
| 3 | Negotiate deposit specification as a schedule | Define exactly what must be deposited in a contract schedule, not in a general obligation — specificity prevents disputes about deposit completeness |
| 4 | Require annual verification testing | Without testing, escrow is a false comfort; annual testing at vendor's cost for critical applications is the only way to validate the deposit |
| 5 | Push for broad release triggers | Include product discontinuation announcement, acquisition resulting in material change, and failure to update deposit as triggers — not just insolvency |
| 6 | Require deposit update within 30 days of each release | Specify the update obligation in the main licence agreement as well as the escrow agreement, with a breach remedy |
| 7 | For SaaS, negotiate operational continuity periods instead | A 12–24 month operational continuity obligation post-trigger is often more practically valuable than source code access for cloud applications |
| 8 | Link escrow to change-of-control protections | Ensure that an acquisition constitutes a release trigger if the buyer exercises its right not to consent to assignment under the change of control clause |
For related guidance, see our articles on data portability negotiation, termination for convenience clauses, change of control protections, and software contract red flags. Our complete IT contract negotiation guide covers all aspects of enterprise software contract strategy.
Software escrow is one layer of a comprehensive vendor risk management strategy. Our advisors help enterprise buyers negotiate the full stack of continuity protections — from escrow to data portability to operational continuity obligations.