Software escrow agreements: when an agency actually needs one

Reference article · 5 min read

When counsel reviews a software contract, one question surfaces reliably: whether the agency should require source code escrow. It usually arrives late, after selection, and gets answered by inserting a clause rather than by deciding what risk the agency is covering. Escrow is a narrow tool. It addresses one scenario well and several others poorly, and a clause that no one maintains gives an agency paperwork rather than protection.

A source code escrow arrangement is a three party agreement. The vendor deposits source code and supporting materials with an independent escrow agent, and the agency is named as a beneficiary. If a defined event occurs, the agent releases the deposit so the agency can maintain the software itself or hire someone else to do it. The agent is a custodian, not a referee on a vendor dispute.

What actually belongs in the deposit

Source code by itself rarely keeps a system running. A deposit is useful only if a developer who has never seen the product could take it and produce the same working software the agency is using. The deposit list belongs in the contract rather than in the vendor's discretion.

• The code for the version in production. Including any agency specific branches, customizations, or patches, not only the general release.
• Build instructions and build tooling. Compiler and runtime versions, build scripts, and the steps to produce a deployable package.
• Third party dependencies. Libraries and components, their versions, and the license terms that govern the agency's continued use of them.
• Database schemas and data dictionaries. Table structures, migration scripts, stored procedures, and enough documentation to understand what the data means.
• Configuration, environment, and operational detail. Server requirements, integration endpoints, scheduled jobs, administrator guides, and known issues.

Keys, certificates, and production credentials need separate handling and should not sit in escrow as live secrets.

Release conditions

The release conditions decide whether the arrangement is worth anything. Common triggers include vendor bankruptcy or insolvency, discontinuation of the product or of support for the licensed version, assignment to a party that will not honor the agreement, and material failure to meet maintenance obligations after written notice and a cure period.

Two details matter more than the list itself. First, the release procedure: who notifies the agent, how long the vendor has to object, and what happens while an objection is pending. An arrangement that lets a vendor freeze a release indefinitely by filing a dispute is close to useless. Second, the license that follows release. The agency needs the written right to use, modify, and maintain the released code, and to hand it to a contractor for that purpose. How escrow and software licenses are treated in insolvency under federal bankruptcy law is a specialized question, and counsel should confirm how the specific agreement is structured.

The failure mode agencies discover too late

The common pattern is an agency that held escrow for years and could not use it. The deposit was made once at signing and never refreshed, so the code predates several upgrades. Build instructions were missing, dependencies were named but not included, and schema documentation never existed. The agency paid annual fees for a sealed container nobody checked.

Escrow agents offer verification at different depths. The lightest confirms a deposit exists and inventories it. A stronger level confirms the code compiles using the supplied instructions. The strongest reproduces a working installation and compares it against the running product. Verification costs money and needs vendor cooperation, so negotiate it before award. Tie deposit updates to events, such as each major release or at least annually, with the agent confirming receipt in writing.

When something else protects the agency better

Escrow fits a specific case: licensed software installed on infrastructure the agency or its contractor controls, where losing the vendor means losing the ability to fix the product. Other situations call for different terms.

• Hosted or subscription software. Source code for a multi tenant platform is usually unusable outside the vendor's environment. The agency needs guaranteed data export in a documented format, defined transition assistance, a run out period at known pricing, and continuity commitments if the vendor is acquired.
• Custom development the agency paid for. Ownership terms serve better than escrow. Require that deliverables belong to the agency, with source delivered continuously into a repository the agency controls.
• Data, which is often the real concern. Counsel often asks about escrow when the underlying worry is losing records. Export rights, retention terms, and a tested extract handle that directly.
• Commodity products with a deep market. If comparable replacements exist, replacement planning is cheaper than maintaining escrow.

What to ask and what to require

Ask vendors these before award, while there is leverage:

1. Is there an existing escrow with a named agent, and can the agency be added as a beneficiary?
2. What is deposited, and when was it last updated?
3. Has any deposit ever been verified, and at what level?
4. Which release conditions does the vendor accept, and what objection process applies?
5. Who pays the agent's fees and the cost of verification?

In the contract, name the agent and the beneficiary, list the deposit contents, set the update schedule, specify the verification level and who pays, define release conditions and the objection window, and grant the post release license to use, modify, and engage contractors. Then assign an owner inside the agency, because escrow nobody tracks quietly expires.

HQT works with state and local agencies on software development and technology advisory work, including technical review of escrow deposits and transition planning for systems moving between vendors.

Frequently asked questions