Source code escrow: when to agree to it, and the cheaper alternatives

A client asking for source code escrow is asking one question: “What happens to us if you disappear?” It is a fair question. Agencies fold, get acquired, or lose the two people who understood the system. The trouble with escrow as the answer is that it is slow, it costs money every year, and in most agency engagements a simpler arrangement gives the client more protection.

This page explains what escrow is, when the request is reasonable, how release triggers work, who pays, and what I agree to. It belongs to the contracts hub, alongside the statement of work template and the other documents that govern the build.

What escrow is

Escrow is a three-party agreement. The software owner (you) deposits the source code with a neutral escrow agent. The beneficiary (the client) gets the right to receive that deposit if specific release events occur. Until then the agent holds it and nobody touches it.

A proper deposit is more than a zip of the repository. To be any use, it has to include:

• the full source code for the current release
• build scripts and configuration, with secrets removed
• a list of dependencies and their versions
• database schemas and migration scripts
• written build and deployment instructions that a competent stranger could follow

Deposits get updated on a schedule, typically at each major release or every quarter. Escrow agents also sell verification, ranging from a file inventory to a full test build by their own engineers. Without some verification, the client is paying to store a package nobody has checked.

When a client asks for it, and when the request makes sense

Escrow answers a specific situation: the client depends on software and does not have the source.

That is the case under a license model, where the agency owns the code and the client is licensed to use it. It is also the case when you deploy your own platform or product for a client, and when the deliverable sits on top of a substantial piece of your background IP that you ship compiled or hosted. The three ownership models are laid out in who owns the code.

It is the wrong tool when the client owns the deliverables. If your software development agreement assigns the code on payment and the client has access to the repository, the client already holds everything an escrow agent would ever release. I have had procurement teams demand escrow on projects where the client’s own engineers were committing to the codebase weekly. The request comes from a checklist. The right response is to explain, politely, that the client already has what escrow would give it, and to offer to confirm that in writing.

Release triggers

The triggers are the whole negotiation. A release event should be something objective, serious and rare.

Triggers I accept:

(a) Licensor ceases to carry on business in the ordinary course without a successor that assumes Licensor’s obligations under the License Agreement; (b) Licensor becomes subject to bankruptcy or insolvency proceedings that are not dismissed within 60 days; or (c) Licensor fails to provide the support services required by the License Agreement and does not remedy the failure within 30 days after written notice from Licensee specifying the failure.

Triggers I refuse:

• Any breach of the agreement. A disputed invoice or a late milestone should never release your source code.
• Change of control. Being acquired is a normal event in an agency’s life. A trigger here hands every licensed client your code on the day you sell, which a buyer will find in diligence and price accordingly. If the client fears a competitor buying you, offer a trigger limited to acquisition by a named competitor followed by a failure to support.
• Failure to meet a service level. Service credits are the remedy for missed service levels.
• Release on the client’s say-so. The agreement needs a procedure: the client sends a notice to the agent, you get a period to object, typically 10 business days, and a contested release goes to the dispute process in the contract.

One legal note for US readers. A trigger that fires purely because a bankruptcy petition was filed may not be enforceable once a bankruptcy case is underway, and US bankruptcy law separately gives licensees of intellectual property some protection to keep using what they licensed. Both points are reasons for the client’s lawyer to draft triggers around operational facts, such as support stopping, and both are worth ten minutes with your own lawyer before you sign.

What the client can do after a release

A release gives the client the code. The agreement has to say what it may do with it.

Upon release, Licensee may use, copy and modify the Deposit Materials solely to maintain and support the Software for Licensee’s own internal business purposes. Licensee will treat the Deposit Materials as Licensor’s Confidential Information. Ownership of the Deposit Materials remains with Licensor.

Three limits are in that paragraph and all three matter. The use is maintenance for the client’s own business. The code stays confidential. Title stays with you. A release clause that transfers ownership turns a continuity arrangement into a contingent sale of your product, and you would be giving that away for nothing.

Who pays

The client pays. Escrow is insurance for the client’s benefit, and the party that wants insurance buys it. Escrow agents charge a setup fee and an annual fee, and verification is priced separately according to depth.

The standard positions:

• The client pays setup and annual fees directly to the agent.
• Verification is paid by whoever requests it.
• Your time preparing and updating deposits is billable, or built into the license or support fee. Preparing a deposit a stranger can build from takes real hours the first time, and an hour or two at each update.

When a client asks you to absorb the cost, quote it as a line item. Many escrow requests end at that point, which tells you how much the client valued the protection.

Cheaper alternatives that protect the client better

Escrow protects against one scenario and does it slowly. A release can take weeks, and what arrives is a snapshot from the last deposit. For most agency work, one of these does more for less.

Client-owned repository. The code lives in a repository under the client’s own account from the first commit, and your team works in it as collaborators. If you vanish, the client loses nothing. This is my default on any project where the client will own the deliverables, and it ends the escrow conversation before it starts.

Read access or a mirror. Where you host the repository, give the client read access or push a mirror to its account on a schedule. Put it in the contract in one sentence.

Source delivery at each milestone. Each paid milestone comes with a source drop, licensed for evaluation until final payment and assigned after. The client holds current code throughout.

A license with step-in rights. For license models, this is escrow without the agent. The client holds a copy of the source, bound by contract to leave it untouched, and may use it only if a trigger occurs.

Licensor will deliver to Licensee a copy of the source code for each release of the Software. Licensee will hold the source code in confidence and will not access or use it unless a Step-In Event occurs. On a Step-In Event, Licensee may use and modify the source code solely to maintain the Software for its internal business purposes.

Step-in rights require trust that the client will leave the copy alone. With a client I have worked with for years, I offer it. With a new client, I use the agent.

A transition clause. A commitment that on termination or wind-down you will provide a set number of hours of handover at your standard rate. This addresses the real risk, which is knowledge, far better than a code deposit does. If the engagement includes embedded staff, as in staff augmentation, the handover is already half done.

What I agree to

My position when escrow is a reasonable request:

1. Yes to escrow with a reputable neutral agent, using the agent’s standard three-party agreement as the base.
2. Triggers limited to ceasing business, undismissed insolvency, and uncured failure to support.
3. A notice and objection procedure before any release.
4. Post-release rights limited to internal maintenance, with confidentiality and no transfer of ownership.
5. The client pays agent fees. Deposit preparation is billable.
6. Deposits at major releases, with secrets and credentials stripped out.
7. The escrow ends when the license ends or when the client stops paying for it.

And when the client would own the code anyway, I offer the client-owned repository and move on.

What the request tells you about your own position

An escrow request is a reminder of where you stand. A client only asks for it when you are the owner and it is the licensee. That position has value beyond the one deal: the code is your property, you can deploy it for the next client, and you can license it to others on a non-exclusive basis while you keep it. Protect that position in the escrow terms by keeping title with you after any release.

If you kept ownership of what you built, it is worth knowing what that code is worth. See what your repositories are worth.

The reverse also holds. Code the client owns is outside anything you can license, with or without escrow. The contract is what separates the two, and the IP clause is where that line is drawn. For the valuation side, see what your old code is worth.