What Is Software Escrow? A Plain-English Guide to Source Code and SaaS Escrow
Here’s a scenario that keeps some IT managers up at night. Your business runs on software built by a small vendor. Scheduling, billing, inventory- whatever it is, your team uses it every day. Then one morning you get an email saying the vendor is shutting down. Nobody is left to fix bugs, push security patches, or keep the servers running, and you don’t have the code.
Software escrow exists for exactly that moment. Most people don’t think about it until it’s too late, but for businesses that depend on software from smaller or riskier vendors, it can be the difference between a rough transition and a full-blown crisis. Below I’ll explain how it works, what goes into an escrow agreement, and why the arrangement is only as good as the details behind it.
I’m not a lawyer, and this is a general explainer, not legal advice. If you’re negotiating an escrow agreement for software your business can’t live without, bring in an attorney who handles technology contracts.
How Software Escrow Works
Software escrow involves three parties: the company that makes the software, the customer licensing it, and an independent escrow agent that sits between them. The vendor gives the agent a copy of its source code and supporting materials to hold. As long as the vendor keeps its commitments, those materials stay with the agent. If something covered by the agreement happens, such as the vendor closing its doors, the agent turns them over to the customer, who can then maintain the software in-house or bring in another developer to do it.
The reason this arrangement exists comes down to what customers normally receive. A software license typically gets you the working program, while the source code stays with the vendor. That code is usually the most valuable thing the vendor owns. It’s protected by copyright, often treated as a trade secret, and vendors understandably don’t want copies of it spread across their customer base. Escrow lets the vendor keep it private day to day while giving customers a path to it if the vendor can no longer support the product.
What Goes Into the Escrow Deposit
Source code by itself often isn’t enough to rebuild working software. A useful deposit usually includes the code, plus documentation, build instructions, a list of third-party libraries and tools the software depends on, database schemas, and anything else a competent developer would need to compile the program and get it running. UpCounsel’s overview of how software escrow protects licensees makes this point well, and it’s where many escrow arrangements fall short in practice. A folder of code with no instructions can take a new team months to understand.
The deposit also needs to stay current. Software changes constantly, and code deposited once at signing and never updated can be close to useless three years later. Most agreements require the vendor to update the deposit on a schedule, such as quarterly, or whenever a major release ships.
Release Conditions
Much of an escrow agreement’s value depends on its release conditions, which some contracts call trigger events. These are the situations in which the agent is allowed to give the deposited materials to the customer. The usual ones are the vendor filing for bankruptcy or becoming insolvent, shutting down its business, dropping the product, or no longer providing the support and maintenance it promised.
How those conditions are worded matters enormously. A vague trigger like “the vendor ceases to do business in the ordinary course” might sound clear until the vendor is sold to a competitor, or winds down slowly instead of shutting its doors overnight. Good agreements define the triggers precisely and lay out a process for what happens when the customer claims one has occurred, including how the vendor can dispute the claim and how quickly the agent has to act.
Bankruptcy deserves a special mention. A bankrupt company can sometimes reject contracts it no longer wants to perform. In the US, Section 365(n) of the Bankruptcy Code gives intellectual property licensees certain protections to keep using what they licensed, and escrow agreements are commonly drafted with that provision in mind. The details are technical, which is one more reason to have a lawyer review the agreement.
Verification: The Step People Skip
If I had to pick one thing to insist on, it would be verification. An escrow agent will store whatever the vendor sends, and it usually won’t check whether that material actually works unless someone pays for it. A customer can go through the whole release process after a vendor fails, finally get the files, and then learn they’re outdated, incomplete, or can’t be compiled.
Most agents sell verification in tiers. At the basic level, they confirm the files on the deposit list showed up and can be opened. The next level involves the agent’s engineers trying to build the code into a working program. At the top level, they go further and install and run the software to confirm it behaves the way the customer relies on it. The price rises with each tier. For software your business can’t function without, I think the build test is the minimum worth paying for, and the full test is worth considering if an outage would be costly.
SaaS Escrow
Traditional escrow was designed for software installed on a customer’s own computers or servers. If the vendor disappeared, the customer could take the code and keep running it in-house. Cloud software complicates that picture. With a SaaS product, the vendor hosts everything, and many customers share the same system. Even with the source code in hand, a customer might not have the servers, configuration, or expertise to get the service running again before its business grinds to a halt.
SaaS escrow tries to close that gap. Instead of just source code, the deposit can include infrastructure setup files, configuration, access credentials for the hosting environment, and regular backups of the customer’s data. Some providers go further and offer continuity arrangements where the hosting environment stays running for a period after a vendor failure, giving the customer time to migrate. For a customer with its own dedicated instance of a cloud application, that kind of arrangement can be very valuable.
For ordinary multi-tenant SaaS, where thousands of customers share one system, escrow is harder to make useful. In those cases, the most practical protection is often simpler: making sure you can regularly export your data in a usable format so you can move to another provider if needed.
Who Pays, and Is It Worth It?
Costs depend on the agent, the number of parties, and the level of verification. Basic arrangements can be fairly affordable, while agreements with full testing and SaaS continuity cost considerably more. Who pays is negotiable. Sometimes the customer covers it, sometimes the vendor does, and sometimes they split it. Vendors that sell to large enterprises often keep a standing escrow arrangement that new customers can join, which keeps costs down for everyone.
Whether it’s worth it depends on how much you rely on the software and how risky the vendor is. A small startup providing software that runs your core operations is a strong candidate. A mature, well-funded company selling a tool you could replace in a week probably isn’t. It also helps to remember that the rest of your contract won’t necessarily save you here. Even if the vendor breached its obligations, a limitation-of-liability clause may cap what you can recover, and money from a bankrupt company is hard to collect anyway. Escrow isn’t about getting paid. It’s about keeping your business running.
What I’d Look for in an Escrow Agreement
I’d want release conditions that are specific and tied to real risks, including failure to support the product, not just bankruptcy. I’d want the deposit to include everything needed to build and run the software, updated on a regular schedule. I’d pay for at least a build-level verification if the software matters to daily operations. And I’d check that the agreement gives me a license to actually use the released code, including modifying it and hiring outside developers to maintain it, since having the code without the right to use it doesn’t help much.
For cloud software, I’d also ask how data exports work and whether the vendor offers any continuity option for the hosted environment.
Final Thoughts
If your business relies on software that someone else builds and maintains, escrow gives you a way to keep using it if that vendor goes under or stops supporting it. The vendor hands its code and the materials needed to build it to an independent agent, and the agent passes them to you if one of the agreed conditions is met. With cloud software, the arrangement can also cover the hosting setup, access credentials, and backups of your data.
The weak spot is that nobody usually looks inside the deposit until something has already gone wrong. By then it’s too late to discover the code is two years out of date or missing the instructions needed to build it. If the software really matters to you, spend the time up front on precise release conditions, insist on regular updates to the deposit, and pay to have it tested. That’s what makes the difference when you actually need to use it.
