Software escrow protects your business by storing critical source code and documentation with a neutral third party. But protection only matters if you can access those materials when vendor relationships break down.
That's where release conditions come in. These are the specific triggers written into your escrow agreement that determine exactly when you can access the protected materials. Without properly structured release conditions, even the most comprehensive escrow arrangement may not help you when you need it.
Below, we discuss what software escrow release triggers are and how to set up balanced terms that benefit both parties. We also look at how the release process works and what happens after a software escrow release.
» Explore our software escrow agreement templates
Release conditions are the specific circumstances written into your escrow agreement that determine when you can access the protected source code and materials. They define exactly what situations must occur before the escrow agent will release the materials to you — events like vendor bankruptcy, failure to provide support, or discontinuation of your software product.
These conditions cover everything from obvious scenarios such as vendor insolvency to more subtle situations like chronic support failures or changes in ownership that threaten your software investment. They also establish the process for how releases work, including notice periods, dispute resolution procedures, and what evidence is required to prove trigger conditions have been met.
The key is being careful when you set up these conditions. If they're too narrow, you might not get protection when you need it. If they're too broad, vendors may refuse to agree to the escrow arrangement. Getting the balance right requires understanding your specific risks and negotiating conditions that provide genuine protection while being fair to your vendor.
» Create a custom escrow agreement for your situation
When you're setting up software escrow, you need to know what situations will trigger the release of your protected materials. These nine triggers cover the most common scenarios that threaten software-dependent businesses.
When your software vendor can no longer pay their debts or files for bankruptcy protection, they lose the ability to maintain your software or provide ongoing support. To activate this trigger, you notify the escrow agent and provide legal documentation like bankruptcy court filings or insolvency proceedings. The escrow agent verifies these documents before releasing your materials.
This trigger protects you from the most obvious vendor failure scenario: Complete financial collapse that eliminates all future support.
Your vendor might stay in business but stop providing the technical support they promised in your contract. This could mean ignoring your support tickets, taking weeks to respond to critical issues, or providing inadequate fixes that don't resolve problems.
To use this trigger, you document these support failures and formally notify both your vendor and the escrow agent. Your vendor gets a specified period — usually 30 to 60 days — to fix their support problems. If they don't improve, you can access your escrow materials to handle support issues independently.
Software vendors often decide to stop supporting older products to focus resources on newer offerings. They might announce end-of-life dates, stop releasing updates, or completely discontinue your software product. When this happens, you're left with software that will become increasingly vulnerable and outdated.
This trigger activates when you notify the escrow agent that your vendor has officially announced discontinuation. You'll need to provide evidence like vendor communications, public announcements, or formal notices. Unlike other triggers, there's no cure period because discontinuation is typically a permanent business decision.
This covers situations where your vendor fails to meet specific obligations written into your software contract. Examples include consistently missing promised update deadlines, refusing to fix critical bugs within agreed timeframes, failing to deliver features they committed to, or not maintaining promised service levels.
To activate this trigger, you must document the specific breaches, formally notify your vendor of their failures, and inform the escrow agent. Most agreements include a cure period that gives vendors time to fix their breaches before you can access the escrowed materials.
When your software vendor gets bought by another company, your relationship can change dramatically. The acquiring company might be a competitor who wants to eliminate your software, a company with different support standards, or an organization that simply doesn't want to honor existing customer commitments.
This trigger protects you when ownership changes threaten your software investment. You notify the escrow agent when acquisitions or mergers occur and provide documentation showing how the change impacts your relationship or threatens continued support.
» Learn how to use software escrow to manage vendor risks
Many software contracts include specific, measurable performance commitments like "respond to critical issues within 4 hours" or "maintain 99.9% uptime." When vendors consistently fail to meet these measurable standards, you have grounds for escrow release.
This trigger requires you to document specific SLA violations over time, formally notify your vendor of their failures, and inform the escrow agent. The vendor typically gets opportunity to improve their performance before release occurs, but persistent SLA breaches demonstrate they can't meet their commitments.
Sometimes vendors sell the intellectual property rights to your software to other companies who may not want to continue supporting existing customers. This could happen when vendors need cash, want to exit the market, or sell assets to competitors. The new IP owner might have no obligation to honor your existing support agreement, leaving you without recourse.
This trigger activates when you learn about IP transfers that could affect your support relationship. You notify the escrow agent and provide documentation of the transfer and evidence that it threatens your continued access to support or updates.
Not all business failures involve formal bankruptcy proceedings. Companies can simply stop operating, abandon their offices, stop answering phones, or cease all business activities without legal formalities. When your vendor becomes completely unresponsive and appears to have stopped doing business, you need access to your software materials to maintain operations.
This trigger covers these "soft failures" where vendors disappear from the market. You notify the escrow agent when your vendor becomes unresponsive and provide evidence that they've stopped conducting business.
Different industries face unique software risks that standard triggers don't address.
Healthcare organizations might need protection when software vendors lose FDA approvals or HIPAA compliance certifications. Financial services companies might require triggers for loss of regulatory authorizations or security certifications. Manufacturing companies might need protection when vendors lose industry-specific quality certifications.
These custom triggers let you address risks specific to your industry or business model. You work with the escrow agent to define these triggers clearly and establish what documentation proves the triggering condition has occurred.
The release process involves specific steps, timelines, and procedures that can make the difference between getting immediate access to your software materials or waiting weeks while your business operations suffer.
When you believe release conditions have been met, you send written notice to the escrow agent explaining what happened and providing supporting documentation. This documentation might include bankruptcy court filings, official business closure notices, records of ignored support requests, or evidence of missed SLA commitments. The escrow agent evaluates this objective evidence to determine whether your claim is valid.
Codekeeper, the escrow agent, takes over and manages the entire release process without requiring your vendor's permission or cooperation. This neutral management means your business continuity protection works even when your vendor relationship has completely broken down. The process focuses on objective evidence rather than opinions about vendor performance.
Your vendor receives formal notification of the release request and gets a specified response period — typically 10 to 30 business days — to either fix the underlying problem or provide evidence that release conditions haven't actually been met. This formal dispute resolution period protects both you and your vendor while ensuring quick resolution.
During the response period, vendors can take corrective action to address the issues you've raised. For example, they might restore support services, provide overdue updates, or cure contract breaches.
However, if vendors can't provide objective evidence that release conditions haven't been met, or if they fail to fix the problems within the specified timeframe, the release process moves forward regardless of whether the vendor wants it to happen.
If the vendor doesn't resolve the issues or disputes the release unsuccessfully, the escrow agent releases all protected materials to you. This balanced approach protects vendors from frivolous release requests while ensuring you don't get stuck waiting indefinitely for vendors who can't or won't resolve legitimate problems.
» Find out what you need to know about software escrow
To establish release conditions that actually protect your business, follow these critical steps:
What happens after a software escrow release?
When escrow materials are released, you receive everything needed to maintain your software independently. Released packages include source code, complete documentation, build instructions, dependency information, environment specifications, and verification reports that prove the materials work.
Software maintenance requires specialized knowledge, which is why planning for post-release support should be part of your initial escrow setup rather than something you figure out after a crisis occurs. Many companies that receive escrow releases hire former developers from their original vendor to help maintain the systems.
Software escrow release conditions determine whether your protection works when vendor relationships fail. The key is negotiating triggers that match your real operational risks while establishing a release process that functions quickly and objectively when you need it most.
Take time to review your current escrow agreements to ensure release conditions cover the scenarios that could affect your business. If you don't have software escrow protection yet, focus on getting the trigger conditions right from the start. It's much easier than trying to renegotiate them later when problems arise.
» Contact Codekeeper to establish release conditions that provide genuine protection