Explainer · Escrow

Source escrow rarely saves an estate on its own.

Released mainframe source you cannot build is a comfort, not a protection. The rights that keep you running through a vendor failure or acquisition are perpetual fallback licenses, verified deposits, and support transition terms. Escrow is one part of continuity, not the whole of it.

№ 01

What escrow is, and what it is not

DepositContinuity

Software escrow places source code and build materials with a neutral agent, to be released to you if a defined event occurs: vendor bankruptcy, product discontinuation, or a failure to maintain. The promise is continuity. If the vendor disappears, you hold the means to keep the software alive. That is the theory, and it reads well in a risk register.

The reality on the mainframe is harder. Mainframe products commonly depend on specialized build chains, proprietary assemblers, and deep platform skills that few buyers still keep in house. A source deposit you cannot compile, or could compile but never safely change, protects nothing. Escrow earns its place only when the deposit is verified and buildable and you have a real right to use it. Otherwise it is a line item that feels like insurance without being it.

№ 02

The five continuity rights that matter

Rights matrix

Continuity is a bundle of rights, not a single escrow agreement. The matrix below ranks the five that do the real work, with what each protects and the drafting weakness to watch. Source escrow sits among them, not above them.

Continuity rights · what protects you when a vendor fails or sells
RightWhat it protectsCommon weakness
Perpetual fallback licenseRight to keep running after terminationDrafted to lapse on termination
Current version use rightsIndefinite use of the deployed releaseTied to active maintenance only
Verified source escrowMeans to maintain if vendor disappearsUnverified, stale, or unbuildable deposit
Support transition obligationKnowledge transfer and run book handoverNo defined period or deliverables
Change of control protectionTerms survive an acquisition intactAssignment freely permitted to acquirer

The single most valuable right for most buyers is the perpetual fallback license, the right to keep running the current version even after the contract ends. It protects continuity without ever needing the source. Escrow becomes meaningful only once that base is secured and the deposit is independently verified as complete and buildable.

№ 03

Which scenario calls for which right

Decision tree
Matching the protection to the risk you actually carry
ScenarioPrimary protectionWhy
Vendor acquired by a competitorChange of control and fallback licenseAcquirer may sunset or reprice the product
Vendor ceases tradingVerified escrow plus current version rightsYou must self maintain or freeze safely
Product discontinued, vendor survivesSupport transition obligationYou need an orderly handover, not source
Maintenance dispute, vendor livePerpetual fallback licenseKeep running while the dispute resolves

Most real continuity events are acquisitions and discontinuations, not bankruptcies, which is exactly where a bare source escrow helps least. Matching the right to the scenario you actually face, rather than buying escrow reflexively, is the difference between protection and paperwork.

№ 04

Where it bites, and how to optimize

AcquisitionsLeverage

Continuity gaps bite at acquisition time, and the mainframe market has seen plenty of consolidation. When a tool changes hands, the new owner often revisits pricing, support, and roadmap. Buyers who negotiated only an unverified escrow find they have a deposit they cannot use and no fallback license to keep running on their own terms. The optimization is to treat continuity as a negotiated bundle at signing, weighted toward the rights that keep you operating.

Buyer side levers

  • Secure a perpetual fallback license that explicitly survives termination and lets you keep running the current version
  • Decouple use rights from active maintenance so a lapsed support contract does not strand your deployed release
  • If you take escrow, require independent verification that the deposit is complete and buildable, refreshed on each major release
  • Write a support transition obligation with a defined period and concrete deliverables, not a vague best efforts clause
  • Add change of control protection so terms survive an acquisition and the buyer cannot reprice you through the back door
№ 05

Frequently asked

FAQ
Q1
What is software escrow?A deposit of source and build materials with a neutral agent, released to you on a defined trigger such as vendor bankruptcy or discontinuation. The aim is continuity, but its value depends on whether the deposit is usable.
Q2
Does escrow protect a mainframe estate?Rarely on its own. Mainframe builds need specialized environments and skills, so released source can be unusable. It helps only when verified and buildable and paired with real use rights.
Q3
What triggers a release?Typically bankruptcy, ceasing to trade, discontinuation, or a material maintenance failure. The trigger only helps if drafted for the risks you fear and if the release cannot be stalled.
Q4
What should I negotiate instead?A perpetual fallback license, indefinite current version rights, verified escrow, a defined support transition, and change of control protection. These keep you running, which is the real goal.

Protect the right to keep running.

Audit notice or renewal under 18 months out? We mobilize within 48 hours.

Continuity is a bundle of rights. We will weight it correctly.

Get expert help