When You Actually Need Escrow
A software escrow agreement places a copy of a vendor's source code, build instructions, and data with an independent agent, to be released to you if the vendor can no longer support the product. It is not needed for every purchase — a commodity SaaS tool with easy substitutes does not warrant it. It is needed where three conditions coincide: the software is business-critical, switching costs are high, and the vendor carries meaningful continuity risk, such as a small private company, a recent acquisition target, or a single-source supplier with no viable alternative.
Broadcom's acquisition of VMware is the cautionary tale every IT leader now cites: continuity, support, and assignment terms that looked like boilerplate became the difference between a managed transition and a forced, expensive migration. Escrow belongs in the same continuity toolkit as the exit and assignment and transfer rights covered elsewhere in this cluster, and it should be assessed during vendor due diligence — not bolted on after a vendor wobbles. The VMware/Broadcom vendor hub documents how quickly continuity risk can crystallise.
Why SaaS Breaks Traditional Escrow
The model most enterprises still picture — source code in a vault, released on bankruptcy — was built for on-premise software. It does not fit SaaS. With a hosted service, the customer is at far greater risk of losing access than with installed software, yet traditional release conditions often require a waiting period, such as the provider ceasing operations for 60 days or more, before the agent may release the deposit. For a SaaS application, an outage of mere minutes can cause substantial business interruption; a 60-day release clock is useless.
Modern SaaS escrow therefore protects more than code. It captures the source code and build environment, the customer data held on the provider's servers, and the documentation and configuration needed to actually stand the service back up — increasingly with a verified ability to redeploy in a third-party cloud. Without the data and the run-book, source code alone cannot restore a live service. This continuity question is closely tied to data sovereignty, because where your data sits determines whether you can lawfully recover it elsewhere.
Source code in a vault does not restore a SaaS service. Without the customer data, the build environment, and a tested redeployment path, an escrow release gives you a box of files and no running system.
Release Triggers and What's Deposited
The value of an escrow agreement lives in its release conditions. Typical trigger events include the vendor's bankruptcy or insolvency, a sustained service disruption, failure to meet defined support or service levels, and abandonment of the product. The drafting detail matters enormously: a trigger tied only to formal bankruptcy will not fire when a vendor is acquired and the product is quietly deprecated — which is the far more common scenario. Negotiate triggers that include acquisition-driven discontinuation and persistent SLA failure, and define the release process so that materials reach you in days, not months.
Equally important is verification. A deposit that has never been tested may be incomplete or unbuildable. Insist on periodic verification — that the deposited materials compile and, for SaaS, that the service can be redeployed. Fold the deposit-update and verification obligations into your contract compliance monitoring so the escrow does not silently go stale as the product evolves.
Cost, and Whether It's Worth It
Escrow is inexpensive relative to what it protects. SaaS escrow typically costs $5,000 to $10,000 per year, depending on the size of the application and how many components are protected, with release-processing services charged separately — on the order of $199 per hour at one major provider. Set against the cost of an emergency migration off a business-critical platform, which routinely runs into seven figures, the premium is trivial.
The decision, then, is rarely about cost — it is about criticality. Reserve escrow for the systems whose sudden loss would halt operations or breach your own obligations to customers and regulators, and govern it within the wider framework in our compliance and governance guide and the CIO Contract Governance white paper. To assess which of your vendors genuinely warrant escrow — and to negotiate enforceable release terms — request a confidential briefing.
Verification, Exit Planning, and Governance
An escrow agreement that is never tested is a false comfort. Deposit materials drift out of date as the product evolves, build environments change, and dependencies break — so a release triggered three years into a contract may hand you a deposit that no longer compiles or deploys. The discipline that prevents this is verification, available in tiers: a basic check that the deposit exists and is complete; a build verification that the materials actually compile; and, for SaaS, a full redeployment test confirming the service can be stood up in an independent environment. The deeper tiers cost more, but for a system whose loss would halt operations, file-existence verification alone is close to worthless.
Escrow also belongs inside a wider exit plan rather than standing alone. The release mechanism is only useful if it sits beside the contractual right to obtain your data, the licence rights to continue using the software, and a realistic operational plan to run or migrate it. Treat escrow, exit, and assignment terms as one continuity package negotiated together, and place the deposit-update and verification obligations under active governance so they are checked on a fixed cadence rather than forgotten.
Finally, match the escrow model to how the software is actually delivered. For traditional on-premise software, source code, build scripts, and documentation may be enough to rebuild. For SaaS, the deposit must additionally capture the live customer data and the infrastructure-as-code needed to recreate the running environment, because the value the customer depends on is the operating service, not the codebase. Increasingly, providers offer a continuity option in which a pre-configured copy of the application can be activated in a third-party cloud within hours of a trigger — materially faster than rebuilding from a code deposit, and the only model that genuinely protects a real-time service. Reviewed this way, escrow stops being a line item bought once and ignored, and becomes a tested component of how the enterprise survives a vendor's failure.