A large customer buying critical software from a smaller vendor eventually asks what happens if that vendor disappears. Source code escrow is the traditional answer: the source is deposited with a neutral third party and released to the customer on defined trigger events — insolvency, cessation of business, or persistent failure to meet support obligations. As a way of making a procurement committee comfortable, it works. As a way of actually recovering a system, it usually does not, and it is worth understanding why before either side signs.
The reason is that source code is the smallest part of what you need. A modern system is source plus build configuration, plus dependency versions, plus infrastructure definitions, plus secrets and credentials that obviously cannot be deposited, plus schema and migration state, plus the accumulated operational knowledge of the people who run it. An escrow containing a zip of the repository as it stood eighteen months ago gives a recovering customer a starting point and very little else.
If you are the customer, the clause worth negotiating is not the deposit itself but its verification. Escrow agents offer verification services that confirm the deposit compiles into a working artefact from a clean environment. That costs more and it is the only part of the arrangement that reliably tells you whether the thing you are paying to store is worth anything. Insist also on a deposit cadence tied to releases rather than an annual refresh, and on the deposit including build instructions and infrastructure definitions, not only application code.
If you are the vendor, do not treat the request as hostile. It is a signal that the customer considers your software important enough to plan around losing, which is a compliment with paperwork attached. What you should push back on is a trigger definition loose enough to be invoked during an ordinary commercial dispute — "material breach" without a cure period is the clause that turns escrow from insurance into leverage.
There is a cheaper arrangement that suits many relationships better, particularly for custom development rather than licensed product. Rather than escrowing, the customer holds the repository from the start, with the vendor working inside it. The continuity question then largely disappears, because there is nothing to release — the customer already has everything, continuously, in its current state. This does not suit a vendor selling the same product to many customers, but for bespoke work it removes the problem instead of insuring against it.
Whichever route, the question the arrangement should be tested against is the same one that matters in any continuity plan: if it were invoked this morning, how long until the system is running under new hands, and who exactly would do that work? An escrow agreement that has never been tested against that question is a document that makes people feel safe rather than one that makes them safe.
