Negotiating escrow is not about adding a reassuring sentence to a software contract. The arrangement must identify the continuity risk, the material needed to recover and a release process that can work under pressure.
Commercial and legal specialists should review the final agreement. The business team should first define the operational outcome it expects.
Begin with a recovery scenario
Describe the event escrow is intended to address. For example:
- the supplier becomes insolvent;
- the supplier permanently stops supporting the product;
- a serious contractual failure remains unresolved;
- the product is discontinued while the business still depends on it.
Then ask what the organisation would need during the first day, first week and first month. This prevents negotiation from focusing solely on a code archive.
Define the deposit schedule
| Deposit item | Negotiation point |
|---|---|
| Source repository | Full current code, relevant branches, tags and history rather than an occasional folder export. |
| Build material | Dependency manifests, tool versions, build scripts and reproducible instructions. |
| Database material | Schema, migrations and any required reference-data process. |
| Deployment information | Pipelines, infrastructure definitions and environment requirements. |
| Documentation | Architecture, integrations, administration, recovery and known limitations. |
| Third-party dependencies | Licences, provider accounts and components that cannot simply be released. |
Set an update mechanism
An agreement covering an obsolete version may be almost worthless. Agree:
- deposit frequency;
- events requiring an additional deposit, such as major releases;
- evidence that a deposit occurred;
- consequences of missed or defective deposits;
- how changes to repositories and platforms are handled.
Automated or repository-connected deposits may reduce administrative gaps, but they still need governance and verification.
Choose verification that matches criticality
Verification can include inventory checks, malware scanning, dependency review, build testing or deployment into a controlled environment. A critical system may justify more extensive verification than a low-risk internal tool.
Specify what the verification report should state, who receives it and how defects are corrected.
Draft release conditions around practical failure
Release conditions should be objective enough to operate and broad enough to cover the intended risk. Review:
- insolvency and cessation events;
- permanent failure to provide contracted support;
- material breach and cure periods;
- product discontinuation;
- supplier objection and dispute procedures;
- emergency interim measures where delay would cause serious harm.
Ensure the escrow terms align with the main licence, support agreement and termination clauses.
Secure post-release rights
Receiving code without the right to use it is insufficient. The customer may need a licence that becomes effective on release and permits:
- internal operation;
- copying and modification;
- use by a replacement supplier;
- hosting in a replacement environment;
- creation of necessary fixes and updates.
Rights in third-party components may not be controlled by the supplier, so record the separate position for each material dependency.
Allocate costs and administration
Agree who pays setup, annual, update and verification charges. Also define who owns day-to-day administration, receives notices and reviews reports. An unpaid invoice or outdated contact should not silently terminate the protection.
Do not ignore SaaS dependencies
For a hosted platform, source code alone may not preserve the service. Consider data, tenant configuration, infrastructure definitions, encryption keys, identity services, scheduled jobs and provider accounts. In some cases a SaaS continuity or environment escrow arrangement may be more appropriate than traditional source-code escrow.
Negotiation checklist
- Named product, version and repositories.
- Complete deposit schedule.
- Update frequency and missed-deposit remedy.
- Verification scope and correction process.
- Objective release conditions.
- Usable licence rights after release.
- Third-party and cloud dependencies.
- Fees, notices, renewal and termination.
- Named recovery team or mobilisation plan.
Validate the negotiated arrangement
Ask a technical lead to review the proposed deposit schedule and attempt to describe how a replacement team would build the application from it. Ask a legal adviser to review the release and post-release rights. Escrow is ready only when both reviews support the same recovery plan.