Source Code Escrow

Most software customers receive a working product, not the source code used to build it, so if a critical supplier stops supporting the product they may have little ability to maintain it themselves. Escrow creates a controlled backup in which the supplier deposits materials with a third party, usually retaining its intellectual property rights.

Escode's FAQ describes the three-party agreement, regular deposits, release terms and verification testing, and its verification guide discusses checking whether the deposited material can rebuild the application. The contract names the parties, so supplier, beneficiary and escrow agent should be identified, along with the specific application and versions covered.

Define release events, since insolvency, long support failure or another agreed event may qualify and vague wording can lead to disputes when speed matters. Set a release process too, because the beneficiary may need to provide evidence and the supplier may have a right to object, so understand the timing before a crisis.

Define what is deposited, because source code may not be enough and build scripts, dependencies, documentation, keys and configuration information may be needed, with secrets handled securely. Check third-party rights, since the supplier may use libraries or components it cannot transfer and the release licence needs to address what the beneficiary can actually use.

Set permitted use as well, because release may permit maintenance for the customer's own operations, not commercial resale or publication, so respect the exact licence. Update the deposit, because a code archive from launch may not match the version running two years later, so agree an update cadence and verify compliance.

Verify usability: a basic check confirms files exist, a deeper test attempts a build or deployment, and the chosen level should match the application's importance. Review after product changes, since new architecture, acquisition or cloud migration can make an old deposit incomplete, so update scope and test again.

Plan staffing, because even perfect code does not maintain itself and the customer needs engineers or another supplier who can use it lawfully, and test the surrounding plan, since backup data, alternative vendors and manual workarounds may be needed while code is rebuilt. Consider hosted software too: a SaaS service depends on infrastructure, data and operational processes as well as code, so a conventional source archive may not restore service, and a SaaS continuity plan might include data exports, deployment instructions and cloud environment details, with privacy and security checked before depositing them.

Do not assume escrow covers ordinary dissatisfaction or replaces support, because the agreed release triggers control, a customer cannot take the code merely because it wants a different price, and the arrangement is a contingency, not day-to-day patching or a guarantee of future development. Agree cost responsibility, since setup, storage, updates and verification can be paid by the supplier, the customer or both, and a fee is worth comparing with the risk protected.

A simple fee ratio is not a standard decision rule: if escrow costs $15,000 per year against a $300,000 software contract, it is 5%, but exposure from an outage may be far more relevant. Check agent independence too, because a custodian should have a clear process for safeguarding materials, confirming deposits and handling contested release, and for an owner source code escrow can reduce supplier continuity risk, but only when the deposit, licence and release process match the real dependency.