A backup plan helps only when its trigger can actually be reached.
On Monday morning, the booking system stops working. The developer has gone silent, the hosting account is in the supplier’s name, and the client has only a login for the finished product—not the code behind it. Sales, appointments, and customer records may all be tied to something the business cannot repair.
A source-code escrow arrangement can sound reassuring: a copy of the code sits with a neutral third party and may be released if defined events occur. That is valuable contingency protection, but it is not day-to-day control. Release conditions can be narrow, evidence may be required, and the deposited files may be incomplete or hard to run. Real ownership usually includes the legal right and practical access to inspect, modify, host, and hand the software to another team. The distinction is worth checking early, while choices are still available.
- Escrow protects against specified failure events; ownership supports ordinary maintenance and change.
- A deposit is useful only if it includes source code, build instructions, dependencies, and current documentation.
A released repository is not a transfer of power
Source code escrow
A supplier places named code, build scripts, documentation, and sometimes credentials with an escrow agent. The customer may receive that package only after a release event written into the agreement.
Ownership
Ownership or an assignment decides who holds the copyright and other rights over time. It can allow the holder to copy, alter, license, sell, or replace the software, subject to the contract and third-party components.
Release licence
Most escrow releases grant a limited licence rather than ownership. It may permit internal use and maintenance solely to keep the existing system running, while banning resale, public distribution, or use in new products.
Deposited materials
The deposit is only what the schedule requires. A folder of source files may omit the deployment pipeline, database schema, dependency versions, keys, cloud configuration, and the notes needed to make it work.
Practical control
Even broad legal rights need usable materials and capable people. A clean, tested deposit with build instructions can be more valuable in an emergency than nominal rights to an incomplete codebase.
Files can arrive without full freedom to use them
Release commonly grants a conditional, limited licence; copyright can remain with the supplier.
The customer may maintain the application but still lack authority to sell it, reuse modules elsewhere, or hand it to an affiliate.
Only the listed deposit is promised, and updates may be deposited on a schedule.
An old snapshot without environment details can turn a release into a difficult recovery project.
Escrow helps after specific triggers, such as insolvency or a failure to support. It does not provide day-to-day decision-making power.
The supplier may still control the roadmap, hosting accounts, trademarks, and access to specialist knowledge until a trigger occurs.
What a workable escrow arrangement looks like
An escrow arrangement begins with an agreement between the customer, the software supplier, and an independent escrow agent. The supplier deposits specified materials; the agent holds them and releases them only if a stated event occurs. Typical triggers include insolvency, a sustained failure to provide contracted support, or abandonment of the product.
The agreement should name more than a source repository. A usable deposit may include:
- source code and build instructions
- dependency versions, libraries, and licences
- deployment scripts and configuration templates
- database schemas, documentation, and test data where permitted
- credentials or a practical handover method for essential third-party services
A deposit made once is quickly outdated. The strongest arrangements require deposits after each release or on a regular schedule, plus verification. An agent or appointed reviewer can check that the package opens, builds, and matches the running version. This does not guarantee an easy takeover, but it turns a paper safeguard into something far more credible.
Release terms also need to be precise. “Supplier failure” invites argument; a measurable trigger—such as a missed support deadline after formal notice—gives the agent a clearer basis to act.
Ask for a recent verification report, not merely confirmation that a deposit exists. A current, buildable package is the part that can keep operations moving when a supplier cannot.
Ownership keeps options open
Direct ownership can give a business far more room to move when a supplier exits, is acquired, or simply becomes the wrong fit. Subject to the agreement, it may be able to keep running the software, fix defects, add features, move it to another host, and hire a new developer without waiting for a release trigger.
That freedom is practical, not merely legal. A replacement team can read the code, use the build instructions, access deployment settings, and continue serving customers. Ownership also makes a planned transition easier: work can be handed over while the original supplier is still available to answer questions.
Ownership has boundaries
Not every file in a project can be owned outright. The product may include:
- Open-source components, which remain subject to their licenses and notice requirements.
- Third-party libraries or APIs, often licensed for use rather than transferable ownership.
- Subcontractor work, unless the supplier has secured valid assignments.
- Vendor tools and pre-existing code, which a supplier may retain while granting a license to use them.
The contract should name what is assigned, list the exclusions, and state the rights needed for each exclusion: use, modify, maintain, and let a replacement provider work on it. Review the contract ownership provisions that make those rights real, including delivery of source code, documentation, credentials, and a promise that contributors have assigned their rights. Clear wording turns ownership from a reassuring label into a workable exit plan.
Match the deal to the dependency
A sensible choice starts with four questions: How essential is the tool? How tailored is it? How hard is replacement? And what rights must the supplier reasonably keep? The answers rarely point to one rule for every purchase.
Standard SaaS
For a broadly available service—email marketing, bookkeeping, ticketing, or CRM—ownership is usually unrealistic and unnecessary. The practical protections are exportable data, documented integrations, a transition plan, and a credible alternative provider. Escrow may add little if the product could be replaced within a manageable period.
One-off commissioned software
A bespoke website, mobile app, or workflow built specifically for one organization is different. Its value lies in the commissioned result, not in a vendor’s reusable platform. Ownership of the custom code, designs, deployment materials, and documentation is often the cleanest arrangement, while the developer can retain pre-existing libraries and general know-how.
Critical internal tools
An internal system can look modest yet become indispensable: a scheduling script, pricing engine, or operations dashboard. If daily work stops without it and replacement would take months, direct ownership or a strongly verified escrow plan deserves serious attention. Recovery also needs credentials, infrastructure notes, build instructions, and data access—not merely source files.
Customized shared products
Many suppliers sell one core product while tailoring it for each customer. Here, demanding ownership of the whole platform may be unfair and commercially impractical. A balanced contract can leave the shared product with the supplier while granting rights to customer-specific customizations, data, and continuity use after defined failures.
The goal is not to acquire code by default. It is to reduce a dependency to a level the organization can actually survive.
Put an escrow proposal through this practical test
-
Confirm what is actually deposited
The deposit should include source code, build scripts, dependency lists, configuration templates, documentation, database schemas, and deployment notes. A source archive without the pieces needed to run it is rarely enough.
-
Check how freshness is enforced
Set a cadence tied to releases or meaningful changes, not an annual promise. Ask for dated deposit records and a clear remedy when the supplier misses an update.
-
Require an independent build check
A neutral party should periodically retrieve the deposit and attempt a documented build or restore. This is the strongest early warning that recovery may fail when it matters.
-
Read release events word by word
Triggers should cover insolvency, prolonged support failure, and material breach, with measurable deadlines. Vague phrases such as “failure to perform” can invite a dispute at the worst moment.
-
Map the decision and the rights afterward
Establish who can request release, what evidence is needed, who decides contested cases, and how quickly access follows. Then confirm the released license permits the maintenance access needed after the vendor relationship ends, including fixes, hosting, and use of contractors.
A current deposit is only a package. Verification shows whether it can be used; release language shows whether it can be reached. If either point is weak, escrow may provide reassurance without a realistic path to keeping the service running.
A small trial recovery—building the software from the deposit and reviewing the release path—can expose gaps before a dependency becomes a crisis.
Code is only one dependency
A source archive can be complete and still fail to restart the service. Modern applications depend on assets held elsewhere: cloud subscriptions, domain records, signing keys, build pipelines, third-party APIs, monitoring tools, and production data. If those remain under a supplier’s control, released code may be little more than a blueprint.
Map what must move
A practical continuity plan lists each dependency, its owner, renewal date, and recovery path. It should cover:
- Infrastructure: hosting accounts, DNS, backups, certificates, and deployment access.
- Data: export formats, retention rules, encryption keys, and a tested restore procedure.
- Tooling: source control, package registries, CI/CD configuration, licences, and paid services.
- Commercial rights: vendor contracts, subcontractor agreements, and permission to transfer or replace services.
- Working knowledge: architecture notes, runbooks, credentials process, and named handover contacts.
Exit terms should require timely access to these materials, not merely delivery of files. A short handover period can matter enormously: the departing team explains releases, known faults, and the fastest safe route to a new operator. Testing that handover before a dispute turns a paper promise into a credible fallback.
A useful test is simple: could an independent team deploy, restore, and support the system from the agreed materials within a stated timeframe? If not, the continuity plan is incomplete.
Negotiate for the failure that matters
- Put recovery testing, update frequency, and release rights in the contract—not in sales assurances.
- Treat the dependency inventory as a living record whenever the supplier changes hosting, tooling, or subcontractors.
- Use technical and legal reviewers before signature; neither review can reliably replace the other.
Start with a blunt question: what happens if the supplier cannot operate tomorrow? If the result is inconvenience and a realistic substitute exists, a lighter escrow or migration plan may be enough. If operations, customer commitments, or regulated records would stall, the agreement needs a credible continuity route. If the organisation must direct the product’s future, alter it freely, or move it without permission, it needs genuine control—not merely a release event.
That distinction creates a stronger negotiating position. List every dependency required to run the service: source, build instructions, credentials and access arrangements, infrastructure definitions, data exports, third-party licences, documentation, and named support contacts. Then ask what rights and handover each item requires. Have someone technically minded test whether the package could actually be used, and have qualified legal review confirm that the promised rights survive the failure scenario. Escrow can be valuable protection, but only a negotiated, tested, and legally usable plan turns protection into resilience.
