Escrow looks like a safety net until a deal tests it. What a source code escrow actually protects, when it releases, and the checks a buyer makes before close.
Change of control and source code escrow intersect at a point most deal teams overlook until it is too late. A source code escrow is an arrangement where a software vendor lodges a copy of its source code and build materials with a neutral agent, so the customer can keep the product running if the vendor goes under or stops supporting it. When a buyer acquires a business that depends on escrowed software, change of control and source code escrow questions surface together: does the deal trigger a release, does it void the arrangement, and is the deposited code current enough to be worth anything at all. The honest answer in most estates is that the escrow looks reassuring on paper and protects far less than the buyer assumes.
An escrow is a three party arrangement between the software vendor, the customer, and an escrow agent. The vendor deposits source code, build instructions, and sometimes documentation. The agent holds the materials and releases them only on defined conditions. The customer pays for the comfort of knowing that if the vendor fails, the business can maintain the software itself or hire someone to do so. The release conditions are the heart of the arrangement, and they vary widely. Vendor insolvency is almost always a trigger. Failure to provide contracted support is common. A change of control of the vendor sometimes triggers release and sometimes does the opposite by voiding the agreement. A change of control of the customer, which is the event a buyer cares about, is frequently not a release condition at all, and can instead sit under the same anti assignment restrictions that govern the underlying licence, covered in anti assignment clauses in software contracts.
The most expensive assumption in diligence is that an escrow agreement means working code sits ready for release. In practice deposits decay. The vendor ships new releases every quarter but lodges a fresh deposit once a year or never. The build instructions reference tools and libraries that have moved on. Third party dependencies that the product needs are not in the deposit because the vendor never had the right to lodge them. When the release finally happens, the customer receives a snapshot that will not compile and cannot be maintained without months of reverse engineering. A buyer that is relying on an escrow as a mitigation for a critical, hard to replace system should confirm that the deposit is current and that verification, where the agent actually builds the deposited code and confirms it runs, has been performed and passed. Without that, the escrow is a line item that buys comfort and delivers little.
| Release trigger | What it covers | What the buyer should check |
|---|---|---|
| Vendor insolvency | Bankruptcy, liquidation, or ceasing to trade | Whether the clause survives a change of control of the vendor |
| Failure to support | Vendor stops maintaining or patching the product | How support failure is defined and who decides it occurred |
| Change of control of the vendor | Acquisition of the supplier by a third party | Whether this is a release event or instead voids the agreement |
| Material breach | Vendor breaches the licence or service terms | Notice and cure periods before release can be requested |
| Verification on demand | Buyer right to test that the deposit builds | Whether verification has ever been exercised and passed |
Deal structure decides which clauses bite, and escrow is no exception. In a stock purchase the customer entity usually continues to exist, so an escrow tied to that entity may carry across untouched, though a change of control clause in the escrow or the underlying licence can still require notice or consent. In an asset purchase the escrow arrangement has to be assigned to the buyer entity along with the licence it supports, and the agent and vendor may both need to agree. In a carve out the escrow may have covered software used across the wider seller group, and the carved out business may have no standalone right to the deposit at all. The mechanics of how structure changes the analysis are set out in how deal structure limits assignment problems, and the escrow should be mapped against the same structure decision rather than treated as a separate question.
A recurring error is to treat the existence of an escrow as a reason to relax about consent. The two address different risks. Consent and assignment analysis answers whether the buyer has the right to keep using and to take over the licence after the deal. Escrow answers what happens if the vendor itself fails. A buyer can hold a perfect escrow and still face a vendor that refuses consent, reprices the licence on the transaction, or asserts a termination right, which is why escrow never removes the need for the clause review described in termination rights triggered by a transaction. The escrow is a backstop for a narrow failure mode. It does not protect the buyer against the publisher behaviour that drives most post deal exposure, and it should be priced and planned accordingly. The legal effect of any escrow or licence clause is a matter for the buyer own counsel.
Consider an anonymised composite: a private equity buyer acquiring a 900 employee logistics software business that ran its core routing engine on a product licensed from a small specialist vendor, backed by a source code escrow. Standard diligence noted the escrow and treated the dependency as mitigated. A focused review found three problems. The deposit had last been refreshed two years earlier and predated a major architecture change, so the code on deposit no longer matched the running system. The escrow agreement listed vendor insolvency as the only release trigger and was silent on failure to support, so a slow decline rather than a bankruptcy would not release anything. And the underlying licence carried a change of control clause that required vendor consent on a stock purchase, which the escrow did nothing to address. The buyer negotiated a refreshed and verified deposit as a closing condition, added a support failure trigger, and ran the consent process in parallel. The lesson for buyers is that an escrow is only as good as its deposit and its release conditions, and a change of control tests both.
We read the escrow agreements in the target estate, check whether the deposits are current and whether a change of control releases or voids them, and tell you where the safety net has holes.
Request a change of control clause review