Software Continuity and Escrow Toolkit: Vendor Failure, Support Rights, and Exit

By Casey Scott McKay · 2026-03-01

Software escrow is the most commonly purchased and least commonly useful continuity control in technology contracting, and the reason is that companies buy the deposit without buying anything that makes it usable. This toolkit works what escrow actually delivers, what verification levels exist and which are worth paying for, and why a source code deposit for a hosted service protects almost nothing without the infrastructure, data, and operational knowledge that runs alongside it. It sets out the bankruptcy position - what rejection does, what Section 365(n) preserves, and what Mission Product Holdings changed for trademark rights - and the security interest and recordation questions that determine whether an escrow survives a secured creditor. It closes with the continuity planning that actually works.

IP and Technology > Information Technology | Toolkit | Published 1 March 2026 - Updated 23 July 2026 | Casey Scott McKay - marksy.us

Summary. Software escrow is the most commonly purchased and least commonly useful continuity control in technology contracting, and the reason is that companies buy the deposit without buying anything that makes it usable. This toolkit works what escrow actually delivers, what verification levels exist and which are worth paying for, and why a source code deposit for a hosted service protects almost nothing without the infrastructure, data, and operational knowledge that runs alongside it. It sets out the bankruptcy position — what rejection does, what Section 365(n) preserves, and what Mission Product Holdings changed for trademark rights — and the security interest and recordation questions that determine whether an escrow survives a secured creditor. It closes with the continuity planning that actually works.

Keywords: software escrow · source code escrow · release conditions · verification testing · SaaS continuity · hosted application escrow · data export and portability · transition assistance · bankruptcy rejection · section 365(n) · Mission Product Holdings · intellectual property definition · trademark licenses in bankruptcy · security interests in software · step-in rights · support and maintenance obligations · business continuity planning · concentration risk · exit planning

Start Here

A vendor supplying software critical to a company's operations files for bankruptcy protection. The customer's counsel pulls the file and finds a source code escrow agreement, executed six years earlier, with annual fees paid on time.

The deposit is released. It contains source code from four years ago, no build scripts, no documentation of the deployment architecture, and no credentials for the third-party services the application calls. Nobody at the customer has ever compiled it.

The escrow cost the company a modest annual fee and delivered nothing, because the deposit was never verified, never updated, and never usable without operational knowledge that was not deposited and could not be.

This toolkit answers three questions.

What does escrow actually protect against, and what does it not? Less than clients assume, and almost nothing for hosted services without additional arrangements.
What happens in bankruptcy? Rejection, the protections at Section 365(n), and the gap for trademarks.
What continuity arrangements actually work? Data portability, transition assistance, and reducing the dependency.

If you read only one thing, read When Your Licensor Goes Bankrupt. It works the rejection framework and the differing treatment of copyright and trademark rights.

What Escrow Delivers

The structure. The vendor deposits source code and related materials with an agent. On a defined release condition, the agent releases them to the beneficiary, who receives a licence to use them for a defined purpose.

Three agreements in one. The deposit obligation between vendor and agent. The release conditions among all three. And the licence granted to the beneficiary on release, which is what determines whether the released material can lawfully be used.

The licence is the part that matters and the part most often thin. A release with no licence, or a licence limited to internal maintenance where the customer needs to continue operating a customer-facing service, delivers less than the customer expected.

Release conditions. Typically bankruptcy or insolvency, cessation of business, failure to provide maintenance or support as required, and material breach of support obligations. Each needs to be defined in a way that can be established by the agent without adjudication.

Which is the drafting problem. An agent will not decide whether a material breach occurred. Conditions must be objectively verifiable — a filed petition, an assignment for the benefit of creditors, a failure to respond to a defined notice within a defined period, or a certification with a dispute window.

Deposit contents. Source code alone is insufficient. The deposit should include build scripts and the build environment specification, third-party components and their licences, database schemas, configuration and deployment documentation, test suites, and the technical documentation an engineer would need to compile and run the application.

Update cadence. Quarterly or on each major release, with a verification that the deposit was actually made. Vendors miss deposits, and agents report the fact only if asked.

Escrow does not create rights the licence never gave. Where the underlying agreement grants no right to modify or to run the software on the customer's own infrastructure, the escrow licence must grant it expressly.

Verification

The step that distinguishes an escrow that works from one that is decoration.

Level one: inventory. The agent confirms the media is readable and lists the file structure. This confirms something was deposited and nothing else.

Level two: build. An engineer compiles the deposit in a clean environment, using only the deposited materials, and confirms it produces a working binary. This is where most deposits fail, and it is the level worth paying for.

Level three: functional. The built application is deployed and tested against defined functionality, confirming it runs and does what it should.

Level four: full. Including environment recreation, third-party dependency resolution, and data migration testing.

What verification finds. Missing build scripts. Undocumented dependencies. Hard-coded credentials. Components the vendor licensed and cannot sublicense. Build environments that no longer exist. Every one of those makes the deposit unusable and every one is fixable while the vendor is solvent.

Frequency. Initial verification at deposit, then periodically — annually for critical dependencies — because applications change and deposits drift.

Cost. Level two verification is a real expense and it is the difference between a control and a comfort. A company paying for escrow without verification is paying for the appearance of continuity.

The honest test. Ask whether anyone at the company has ever compiled the deposited code. If the answer is no, the escrow is untested and should be assumed not to work.

Hosted Services

Where escrow is most often purchased and least often useful.

The problem. A source code deposit for a hosted application gives the customer code it cannot run. The service depends on infrastructure the customer does not have, data the customer cannot export, third-party services the vendor holds contracts with, and operational knowledge that exists in people.

What the customer actually needs. Its own data, in a usable form, continuously. The ability to run or have run an equivalent service. And enough time to transition.

Data export is the first control. Not on request at termination, but available continuously in a documented, usable format. A vendor that can only produce a proprietary dump on ninety days' notice has given the customer nothing.

Format matters. Structured, documented, complete, and including the relationships between records. An export that loses referential structure is data the customer cannot use.

Frequency. For critical services, a regular automated export the customer retains, so that vendor failure does not mean data loss.

Infrastructure escrow. Some arrangements deposit deployment artefacts, container images, infrastructure definitions, and runbooks alongside source. This is materially more useful than source alone and materially more expensive.

Third-party dependencies. The service may depend on other vendors under contracts the customer cannot assume. Identify them, and where a dependency is critical, address assignment or direct contracting.

Continuity providers. Some escrow agents offer to operate the service temporarily on release. This is the arrangement that most closely matches what a customer of a hosted service actually needs, and it should be priced against the alternative.

Transition assistance. A contractual obligation to provide defined assistance for a defined period on termination — including data export, documentation, and knowledge transfer — is frequently worth more than any escrow.

And reducing the dependency. Where a hosted service is genuinely critical and genuinely unreplaceable, that is a business risk to be managed by architecture rather than by contract.

Bankruptcy

Rejection. 11 U.S.C. § 365 permits a debtor in possession or trustee to reject an executory contract, subject to court approval on a business judgment standard.

What rejection is. Mission Product Holdings v. Tempnology holds that rejection constitutes a breach, not a rescission — it does not terminate the contract or revoke rights already granted. The counterparty has a claim for damages and retains whatever rights the contract conferred.

Why that mattered. Lubrizol Enterprises v. Richmond Metal Finishers had held that rejection terminated a licensee's rights, which prompted the enactment of the protections now at 11 U.S.C. § 365(n).

Section 365(n). Where a debtor rejects a contract under which it is a licensor of a right to intellectual property, the licensee may elect to retain its rights under the contract as they existed immediately before the case commenced, for the remaining term including extensions the licensee may elect.

The price of election. The licensee must continue making royalty payments and is deemed to waive setoff rights and administrative claims.

What the licensee retains. The right to use the intellectual property. The debtor must, on written request, provide the intellectual property held by it and not interfere with the licensee's rights — including rights to obtain it from an escrow agent.

Which is the provision that makes escrow work in bankruptcy. Section 365(n) expressly preserves the licensee's right to obtain deposited materials from an escrow agent notwithstanding rejection.

But what the licensee does not retain. Specific performance of affirmative obligations — support, maintenance, updates, and future development. The licensee keeps the rights it had; it does not keep the vendor's services.

Trademarks are excluded. 11 U.S.C. § 101 defines intellectual property for these purposes as trade secrets, patents and applications, plant variety protections, copyrights, and mask works — not trademarks. Section 365(n) therefore does not protect trademark licensees.

Mission Product Holdings fills part of that gap by holding that rejection is breach rather than rescission, so a trademark licensee's rights are not automatically terminated — though the licensor's quality control obligations under 15 U.S.C. § 1127 create a different problem.

Cross-border. In re Qimonda AG addressed recognition of a foreign proceeding and the protection of licensees, holding that relief inconsistent with the licensee protections could be refused. For licences from foreign vendors, the analysis is more complex and the protection less certain.

Sale free and clear. 11 U.S.C. § 363 permits sale of estate assets, and a licensee's position on a sale of the underlying intellectual property is a distinct and contested question worth addressing in the licence.

The automatic stay. 11 U.S.C. § 362 stays actions against the debtor, which means an escrow release condition triggered by bankruptcy must be exercisable against the agent rather than requiring action against the vendor.

Security Interests

The question that determines whether the deposit survives a lender.

Software is a general intangible for secured transactions purposes, and a lender takes a security interest in it under Uniform Commercial Code Article 9, perfected by filing.

Federal recordation for the registered rights. Copyright security interests in registered works are recorded at the Copyright Office under 17 U.S.C. § 205, and there is a body of law on whether Article 9 filing suffices for unregistered works. Patent interests are recorded under 35 U.S.C. § 261 and trademark interests under 15 U.S.C. § 1060, principally for notice purposes.

What that means for a licensee. A licence granted after a security interest attached may be subject to it, and a foreclosing lender's position relative to the licensee depends on the timing, the perfection, and the terms.

Which is why non-disturbance matters. A lender acknowledgement that the licensee's rights survive foreclosure is available in negotiated transactions and is worth requesting where the dependency is critical.

Escrow deposits and the estate. Materials held by an escrow agent are generally not property of the estate under 11 U.S.C. § 541 where the arrangement is properly structured, but the underlying intellectual property rights are, which is why the licence granted on release matters more than the physical deposit.

Diligence on the vendor. Search for filed financing statements and recorded federal interests before relying on an escrow. A heavily encumbered vendor is a different risk from an unencumbered one.

Change of control. A vendor acquired by a competitor is a continuity risk that escrow does not address, and the answer is a change of control termination right with transition assistance.

Practical position. Escrow addresses vendor failure. It does not address vendor acquisition, vendor pivot, product discontinuation, or a lender foreclosing — and each of those is more likely than bankruptcy.

What Actually Works

Ranked by value per dollar, which is close to the inverse of how companies spend.

One: continuous data export. The customer's own data, in a documented and complete format, retained by the customer on a regular cadence. This addresses vendor failure, vendor acquisition, product discontinuation, and a decision to leave — every scenario, not just insolvency.

Two: exit and transition assistance. A contractual obligation to provide defined assistance for a defined period after termination for any reason, at defined rates, including export, documentation, and knowledge transfer. Enforceable while the vendor is solvent, which is when most exits happen.

Three: reducing the dependency. Architecture that permits substitution — standard interfaces, abstracted integrations, and avoiding proprietary formats where alternatives exist. This is a product decision with a legal consequence, and it is worth more than any contract term.

Four: change of control rights. Termination on acquisition by a competitor, with transition assistance. More likely to be exercised than any escrow release.

Five: the licence granted on release. Where escrow is used, the licence must permit what the customer would actually need to do. This costs nothing to negotiate and is frequently defective.

Six: verified escrow. Level two verification at minimum, refreshed periodically. Expensive, and worth it for genuinely critical dependencies.

Seven: continuity operation arrangements, where an agent or a third party can operate the service on release. Expensive, and the only thing that truly answers hosted service failure.

Eight: unverified escrow. A deposit nobody has tested. This is where most escrow spending goes and it is the least valuable item on the list.

The reallocation most companies should make. Take the escrow budget for non-critical vendors, spend it on continuous data export and verified escrow for the two or three dependencies that would actually stop the business, and drop the rest.

Worked Example: The Critical Dependency

A logistics company depends on a routing platform from a fifteen-person vendor. If it stops, deliveries stop.

The dependency assessment. Criticality: highest. Substitutability: two competitors exist, with an estimated six-month migration. Vendor financial position: venture-backed, not profitable, eighteen months of runway.

The existing arrangement. A standard escrow, deposited twice in four years, never verified, with a release licence permitting internal use only. Annual cost modest; value approximately zero.

What is built instead. A nightly data export in a documented format, retained by the customer. This alone converts vendor failure from an existential event into a six-month migration.

Transition assistance. Ninety days of defined assistance on termination for any reason at agreed rates, with named personnel and specified deliverables — export, documentation, and architecture walkthrough.

Change of control. Termination right on acquisition, with the transition assistance triggered.

The escrow, rebuilt. Deposit contents specified to include build scripts, dependency manifests, deployment definitions, and runbooks. Quarterly deposits with agent confirmation. Level two verification at deposit and annually. Release licence rewritten to permit operation on the customer's infrastructure, modification, and engagement of contractors.

The first verification. Fails. The build depends on an internal package registry the customer cannot reach and on two commercial components the vendor cannot sublicense. Both are fixed while the vendor is solvent — the registry contents added to the deposit, and sublicensing rights obtained for one component with a substitution identified for the other.

Which is the point of verification. Those two defects would have made the escrow worthless, and they were discovered at a cost of one verification exercise rather than during an insolvency.

The architecture change. Over the following year, the integration is abstracted behind an internal interface, reducing the migration estimate from six months to ten weeks.

Total spend. More than the original escrow and less than one month of the disruption it protects against.

The board reporting. One line in the dependency register: criticality highest, continuity arrangement verified, data export continuous, estimated transition ten weeks.

Drafting Notes

Release conditions. Objectively verifiable events the agent can confirm from a document — a filed petition, a dissolution certificate, a written admission of inability to pay, or a certified notice of uncured support failure with a dispute window. Avoid conditions requiring the agent to determine whether a breach is material.

The dispute window. A short period in which the vendor may object, with release proceeding automatically absent objection and an expedited mechanism where objection is made. Without it, a solvent vendor can block release indefinitely.

Deposit contents specification. An exhibit listing what must be deposited, by category, with enough specificity that a missing item is identifiable. "Source code" is not a specification.

Deposit cadence and confirmation. Quarterly or per release, with the agent confirming receipt to the beneficiary. Vendors miss deposits, and beneficiaries learn of it only if the agreement requires notice.

Verification level and frequency, stated, with the cost allocation agreed.

The release licence. Perpetual, irrevocable, worldwide, and permitting: use, reproduction, modification, and creation of derivative works; operation on the beneficiary's or a third party's infrastructure; engagement of contractors and service providers under confidentiality; and continued provision of the beneficiary's own services to its customers. Confidentiality obligations survive.

Third-party components. A representation that the deposit includes or identifies all third-party components, with their licences, and that the beneficiary may exercise the release licence without further third-party consent — or a list of those requiring it.

Bankruptcy language. An express acknowledgement that the agreement is a licence of intellectual property for 11 U.S.C. § 365(n) purposes, that the beneficiary may elect to retain its rights, and that the escrow materials are among the embodiments the beneficiary may obtain from the agent.

Non-disturbance. Where the vendor is encumbered, an acknowledgement from the lender that the licence and escrow survive foreclosure.

Assignment. The escrow follows the underlying agreement, and a change of control on either side is addressed.

Fees and term. Who pays, what happens on non-payment, and a notice obligation to the beneficiary before the agreement lapses for non-payment — because a lapsed escrow discovered at release is the worst outcome available.

Agent obligations. Duty to notify on missed deposits, on fee non-payment, and on any release request.

Diligence Questions

What software dependencies would stop the business if they stopped? Rank them; the answer is usually three to five items, not fifty.

For each: what is the substitution path and the estimated migration time?

Is there a continuous data export? In what format, how complete, and retained where?

Are there transition assistance obligations? For what period, at what rates, with what deliverables?

Is there a change of control termination right?

Is there an escrow? When was it last deposited, and has the deposit ever been verified?

What does the release licence permit? Read it; internal-use-only licences are common and inadequate.

Are release conditions objectively verifiable by the agent?

Does the deposit include build scripts, dependencies, deployment definitions, and runbooks?

Are the escrow fees current, and who pays them?

What is the vendor's financial position, and are there filed financing statements or recorded federal security interests?

Has 11 U.S.C. § 365(n) language been included in the underlying licence?

For hosted services: what would the company actually do on the day the service stops? If there is no answer, the continuity arrangement does not exist regardless of what has been signed.

Common Mistakes

Buying escrow instead of thinking about continuity. The purchase substitutes for the analysis, and the analysis is what identifies that data export matters more.

Never verifying the deposit. The single most common defect, and the one that makes every other term irrelevant.

A release licence limited to internal use, when the customer needs to keep serving its own customers.

Release conditions requiring the agent to adjudicate. Agents will not decide whether a material breach occurred, so the condition never triggers.

No dispute window, so a solvent vendor can block release by objecting.

Deposits that stop. Two deposits in four years is the pattern, and nobody notices because the agreement does not require notice.

Source code with no build environment. Code that cannot be compiled is not a continuity arrangement.

Third-party components the vendor cannot sublicense, discovered on release.

Escrow for a hosted service with no infrastructure, no data export, and no operational documentation.

No data export, which is the control that addresses every failure scenario rather than only insolvency.

Assuming Section 365(n) preserves support. 11 U.S.C. § 365(n) preserves rights, not services. The licensee keeps the licence and loses the vendor.

Assuming it covers trademarks. 11 U.S.C. § 101 excludes them; Mission Product Holdings v. Tempnology supplies a different and partial answer.

Ignoring security interests, so a foreclosing lender's position relative to the licensee is unknown.

Escrow fees lapsing, with the arrangement discovered to be terminated at the moment of release.

No change of control right, when acquisition is more likely than bankruptcy.

Treating this as a legal matter. The substitution path and the migration estimate are engineering answers, and legal cannot produce them alone.

Building the Programme

Start with the dependency register. Every software dependency, with a criticality rating, a substitution path, an estimated migration time, and the current continuity arrangement. Three to five entries will be genuinely critical.

For the critical set, in order. Continuous data export. Transition assistance obligations. Change of control rights. A properly drafted release licence. Verified escrow. And, where the service is hosted and truly unreplaceable, a continuity operation arrangement.

For everything else. Data export where the data matters, exit terms, and nothing more. Escrow for a non-critical dependency is spending without a corresponding risk.

Test the export. Take an export, and have someone attempt to use it without vendor assistance. This is the equivalent of level two verification for hosted services and it fails as often.

Diary the verifications and the deposits. With a named owner, and with the agent's notice obligations in the agreement.

Review annually. Criticality ratings change as products change, vendors' financial positions change, and substitution paths open and close.

Report it. The dependency register, with criticality, arrangement, and estimated transition time, is a board-appropriate document and one of the few in technology contracting that a board can act on.

And revisit the architecture. The most effective continuity control is a dependency that can be replaced, and that is built rather than contracted.

Questions Clients Ask

Do we need escrow? For most dependencies, no. For the two or three that would stop the business, yes — and verified, with a proper release licence.

Does escrow work for a SaaS product? Source code alone, almost never. With infrastructure definitions, runbooks, and continuous data export, sometimes. With a continuity operation arrangement, better.

What happens if the vendor goes bankrupt? The contract may be rejected under 11 U.S.C. § 365. Mission Product Holdings v. Tempnology means rejection is breach rather than rescission, and 11 U.S.C. § 365(n) lets a licensee of intellectual property elect to retain its rights — including obtaining escrow materials — while continuing to pay royalties.

Do we still get support? No. Section 365(n) preserves rights, not services. The rejection ends the vendor's affirmative obligations.

Does it cover our trademark licence? No. 11 U.S.C. § 101 excludes trademarks from the definition, and the answer comes from Mission Product Holdings instead.

Can the lender take the software? Depends on perfection and timing. A licence granted after a security interest attached may be subject to it, which is why non-disturbance from the lender is worth asking for on critical dependencies.

Should we verify? Yes, if the escrow is meant to work. Level two at minimum. If the budget does not permit verification, it does not permit escrow either.

How often should deposits happen? Quarterly or per major release, with agent confirmation to the beneficiary.

What should the release licence say? That the beneficiary may run the software on its own or a third party's infrastructure, modify it, use contractors, and continue serving its own customers. Internal use only is the common and inadequate default.

Our vendor is being acquired. Does escrow help? No. That is what a change of control termination right with transition assistance is for.

What is the single most valuable thing? Continuous data export in a documented format that the company retains. It addresses every failure scenario, costs little, and is the item most often missing.

The One-Page Position

Continuity position — [company], [date]. Software dependencies inventoried: [N]; rated critical [N]. For each critical dependency: substitution path [identified / none], estimated migration [N] weeks. Data export: continuous for [N] of [N] critical dependencies; format documented for [N]; last tested by independent use [date], result [pass/fail]. Transition assistance obligations: in place for [N], period [N] days, deliverables specified [yes/no]. Change of control termination rights: [N] of [N]. Escrow: in place for [N]; last deposit [dates]; verification level [N], last performed [date], result [pass / defects: list]; release licence permits external operation and modification for [N] of [N]; release conditions objectively verifiable for [N]. Section 365(n) acknowledgement present in [N] underlying licences. Vendor encumbrance searches completed for [N]; non-disturbance obtained for [N]. Escrow fees current for [N]; agent notice obligations in place for [N]. Recommended actions: [build continuous export for dependency X / verify the deposit on Y / rewrite the release licence on Z / drop escrow on the non-critical set and reallocate].

The Vendor's Perspective

Firms act on both sides, and the vendor's position on these terms is legitimate rather than obstructive.

Escrow is a real cost. Agent fees, deposit preparation, and verification time, multiplied across a customer base, and it produces no revenue.

Verification exposes the codebase. Level two and above involve a third party building the software, which is a confidentiality exposure the vendor is entitled to manage through the agent's obligations.

Release conditions matter to the vendor too. A condition a customer can trigger unilaterally on an asserted breach is a hostage situation, which is why the dispute window protects both sides.

Broad release licences are a real concession. A licence permitting the customer to operate and modify the software indefinitely is close to a perpetual source licence, and vendors price accordingly.

Multi-beneficiary arrangements reduce the per-customer cost substantially, and vendors should offer them rather than negotiating bespoke escrows.

Transition assistance is easier to give than escrow and frequently satisfies the customer's actual concern at lower cost — defined hours, at defined rates, on termination for any reason.

Data export is easier still, and a vendor that builds a good export capability removes most of the pressure for escrow while improving its own product.

Which is the negotiation to aim for. A vendor offering continuous export, documented transition assistance, and a multi-beneficiary verified escrow for genuinely critical customers is offering more real continuity than one offering a bespoke unverified deposit, and at lower cost to both sides.

On bankruptcy language. Acknowledging that the agreement is a licence of intellectual property for 11 U.S.C. § 365(n) purposes costs the vendor nothing while solvent and is a meaningful comfort to the customer.

A Closing Note

Escrow persists because it is easy to buy and easy to point at. It appears on a diligence checklist, a procurement form asks whether it is in place, and a box gets ticked. Almost nobody asks whether the deposit compiles.

The useful reframing is to stop asking what happens if the vendor goes bankrupt and start asking what happens on the day the service stops — for any reason, including acquisition, discontinuation, a pricing change the company will not accept, or a decision to move.

That question has an operational answer or it does not, and the answer depends on whether the company holds its own data in a usable form, whether it has a substitution path, and how long the transition would take. Escrow contributes to that answer only in narrow circumstances and only when verified.

Which suggests the recommendation this toolkit ends on: build the dependency register, get the data out continuously, negotiate transition assistance, and reserve verified escrow for the small number of dependencies where nothing else will do.

Sector Notes

Financial services. Regulators expect documented continuity arrangements for critical service providers, including exit plans and testing, and the expectations exceed what a standard escrow provides. The safeguards framework at 16 C.F.R. § 314.4 and its sector analogues drive the vendor oversight programme this sits inside.

Healthcare. Continuity of access to systems holding patient records is both an operational and a regulatory concern, and business associate agreements should address data return on termination expressly under 45 C.F.R. § 164.504.

Manufacturing and industrial. Embedded software in equipment with a twenty-year service life outlasts most vendors, which makes source availability a genuine requirement rather than a comfort — and makes design patents, spare parts, and repair rights part of the same conversation.

Public sector suppliers. Government customers frequently require escrow by policy, and the data rights framework provides a parallel mechanism through delivery obligations. See Negotiating and Protecting Data Rights in Federal Contracts.

Startups depending on startups. The highest-risk pattern and the one where escrow is least likely to help, because a fifteen-person vendor's software depends on operational knowledge that cannot be deposited. Data export and a substitution path are the answers.

Enterprise buyers of AI services. Model vendors are young, dependencies are operational, and the deposit concept fits badly. Export of prompts, outputs, and fine-tuning artefacts, plus a substitution path to another model, is the equivalent control. See AI Procurement and Governance Toolkit.

Regulated infrastructure. Where an outage has consequences beyond the company, continuity planning is a supervisory expectation and the documentation standard is higher.

Anyone with a single point of failure. Concentration risk is a governance matter and belongs in board reporting, whatever the contract says.

Working With Other Advisers

Engineering leadership, who own the substitution path and the migration estimate. Legal cannot produce either, and without them the criticality rating is a guess.

Procurement, for the dependency register and for the standard continuity terms applied at contracting rather than negotiated at renewal.

Security, because the vendor register is shared and the diligence overlaps substantially. See Cybersecurity Governance and Disclosure Toolkit.

Finance, for the vendor financial assessment that determines which dependencies warrant the expensive controls.

Restructuring counsel, for the 11 U.S.C. § 365(n) election mechanics and the position on a sale under 11 U.S.C. § 363, engaged when a vendor's position deteriorates rather than after a filing.

Secured transactions counsel, for the encumbrance searches and the non-disturbance negotiation on critical dependencies.

The escrow agent, whose standard forms are negotiable on the points that matter — deposit specification, verification level, notice obligations, and the dispute window.

Business continuity planning, where one exists, because software dependency is one input to a broader analysis and the two exercises should share a register rather than duplicate one.

What This Costs

The dependency register. A day, drawing on procurement records and an engineering conversation, and it tells the company which of the following items are worth buying.

Continuous data export. Engineering work on the vendor's side, negotiated at contracting, and frequently available already for vendors that have built it. The cheapest meaningful control.

Transition assistance terms. Negotiation time, no ongoing cost, and enforceable in the scenario that actually occurs most often.

Change of control rights. Negotiation time only.

A properly drafted release licence. An hour of drafting, and it converts an escrow that would have failed into one that might work.

Verified escrow. Agent fees plus verification cost, recurring, and material. Reserve it for the genuinely critical set.

Continuity operation arrangements. The most expensive option and the only real answer for a hosted service that cannot be replaced.

Architecture that permits substitution. An engineering investment, and the one with the best long-run return, because it reduces the exposure rather than insuring against it.

Against that: the cost of an outage in a critical dependency, measured in the days the business cannot operate, plus the emergency migration that follows at whatever price the market offers under time pressure.

The reallocation is usually straightforward once the register exists: less escrow across many vendors, more data export and verification across a few.

A Suggested Reading Path

For the bankruptcy framework:

For the contracting:

For the security interest dimension:

Primary Authorities

| Authority | Proposition | |---|---| | 11 U.S.C. § 365 | Executory contracts; rejection; Section 365(n) | | 11 U.S.C. § 101 | Intellectual property definition excluding trademarks | | 11 U.S.C. § 362 | Automatic stay | | 11 U.S.C. § 363 | Sale free and clear | | 11 U.S.C. § 541 | Property of the estate | | Mission Product Holdings v. Tempnology | Rejection is breach, not rescission | | Lubrizol Enterprises v. Richmond Metal Finishers | The decision Section 365(n) responded to | | In re Qimonda AG | Cross-border recognition and licensee protection | | 17 U.S.C. § 117 | Copies made by the owner of a program copy | | 17 U.S.C. § 106 | Exclusive rights | | 17 U.S.C. § 109 | First sale | | 17 U.S.C. § 204 | Transfers in writing | | 17 U.S.C. § 205 | Recordation; priority | | 35 U.S.C. § 261 | Patent assignment and recordation | | 15 U.S.C. § 1060 | Trademark assignment and recordation | | 15 U.S.C. § 1127 | Abandonment; quality control | | Uniform Commercial Code Article 9 | Security interests in general intangibles | | 17 U.S.C. § 101 | Definitions; computer program |

Forms and Templates

Escrow arrangements produce three documents and the value is unevenly distributed among them. The escrow agreement itself is largely standard and the agent will resist deviation; the terms worth negotiating are the release conditions, the deposit contents specification, and the verification level. The License Agreement Template supplies the grant that matters most — the licence the beneficiary receives on release — and it should be drafted to permit exactly what the customer would need to do: run the software on its own or a third party's infrastructure, modify it, engage contractors to maintain it, and continue serving its own customers. A release licence limited to internal use is the most common defect and the least noticed. The Portfolio Inventory Template serves as the dependency register: one row per critical software dependency, with the vendor, the criticality rating, the continuity arrangement, the last verification date, the data export capability, and the estimated transition time. That register is what a board actually needs, and it is what makes concentration risk visible.

Related Toolkits and Checklists

The Technology Contracts Toolkit covers the underlying agreement architecture into which continuity provisions fit, and the exit terms there do more work than most escrows. The Technology Agreement Checklist runs the negotiation points in order. The IP Security Interests and Financing Toolkit covers the perfection and priority questions that determine whether a secured creditor can reach the deposited materials. The AI Procurement and Governance Toolkit covers the continuity dimension for model vendors, where the dependency is operational and the vendors are young. And the Cybersecurity Governance and Disclosure Toolkit covers the vendor register that the dependency analysis shares.