Escrow Without the Enterprise Toolkit: A Small-Team Plan for Vendor Failure

Software escrow has a reputation problem. It sounds like something a bank buys from another bank, with a legal team on each side and a filing cabinet somewhere in the City. For a small UK team running on a niche CRM, a bespoke stock tool or a specialist practice-management system, that image is enough to put the whole subject in the too-hard box.

That is a mistake. The smaller the team, the less room there is to absorb a vendor going under, being acquired, or quietly sunsetting the product you built your operations around. You do not need an enterprise escrow programme to reduce that risk. You need a clear arrangement, a short test and a diary reminder.

Why small teams are more exposed, not less

Large organisations have leverage. They have procurement teams, legal counsel and, often, a migration budget. A five-person UK firm relying on a niche tool has none of those things. If the vendor stops trading, the immediate problem is not who owns the intellectual property. It is who can get the data out, who can keep the service running, and who can fix the thing when it breaks.

Vendor failure is also broader than insolvency. It includes acquisition followed by product withdrawal, a founder retiring, support being moved offshore and quietly degraded, or a bespoke developer disappearing. Any of those can leave you with a working system one month and a dead one the next.

What actually belongs in escrow

The classic answer is source code. That is necessary but rarely sufficient. A practical deposit for a small team should include the things a competent developer would need to stand the system up without the original vendor.

For on-premise or bespoke software, that means source code, build scripts, dependency manifests, database schema and migration files, configuration templates, deployment instructions, administrator guides and a list of third-party components with their licence terms. If the vendor hosts the system, source code alone may be close to useless. You cannot run a SaaS product from a zip file. In that case, the priority shifts to data export, transition assistance and continuity of service.

For SaaS tools, ask for a data export specification, a sample export, a documented restore process and a commitment to provide transition assistance for a set period if the service ends. Escrow of the code is not a substitute for being able to get your own data out in a usable format.

Testing without a legal team

An escrow arrangement you have never tested is a promise, not a plan. You do not need a law firm to run a basic check. Once a year, ask the escrow agent or vendor for a test release. Open the archive. Read the manifest. Try to build or restore in a clean environment, or ask a friendly developer to do it. Check that the deposit matches the version you are actually running. Note what is missing and send the list back.

The test does not need to be theatrical. A half-day review with a checklist is enough to catch the common failures: no build instructions, outdated dependencies, missing database migrations, or a deposit that has not been updated since the vendor's second release. Keep the evidence. If the arrangement is ever needed, you will want to show what you checked and when.

The clauses that turn a promise into a safety net

A vague statement that the vendor 'has escrow' is not worth much. The contract should name the triggers for release. Common ones include insolvency, administration, cessation of business, material breach that is not fixed within a set period, and failure to provide support for a defined number of days. Check that the trigger is objective and that you can initiate a release, not just the vendor.

The licence matters as much as the deposit. On release, you need the right to use, modify and maintain the software, and to appoint a third party to do that work. If the deposit includes third-party components, the vendor should confirm that those components can be used on release, or provide workable alternatives. Also check update obligations, verification rights, who pays the agent, and which law governs the arrangement. For a UK team, England and Wales is the sensible default unless there is a good reason otherwise.

Lightweight alternatives worth considering

Full escrow is not always the right answer. For a low-cost SaaS tool with easy exports, a contractual exit plan may be enough: data export rights, a deletion certificate, transition assistance and a named contact. For a critical bespoke system, a specialist escrow agent with a small-team plan is often more practical than a DIY arrangement. Some vendors will agree to a source-code deposit with a nominated solicitor, but that is usually weaker than a proper agent because verification and release are less structured.

Whatever route you choose, keep your own documentation. A current data map, an export you have tested and a list of who does what will buy you time when a vendor wobbles.

A starter plan for this quarter

List the vendors whose failure would stop you operating. For each one, decide whether you need escrow, a data-export plan or both. Ask for the current deposit and the sub-processor list. Add the release triggers and licence rights at the next renewal. Put an annual test in the calendar. Keep the evidence in one folder.

Escrow is a fire drill, not a certificate. Small UK teams can arrange a useful one without an enterprise toolkit, as long as they test it before they need it.