Technology escrow agreements are intended to provide end users with application continuity for mission critical, expensive or difficult to replace software and SaaS applications if the software vendor fails to perform, goes out of business or other pre-negotiated circumstances. All of the risks outlined below have been successfully addressed in escrow agreements in the past.
Risks – Below is a list of risks that our clients have used for evaluating each software and SaaS provider.
Importance – Market advantages provided by emerging technology can be significant and in some cases central to a company’s value proposition, customer satisfaction, security and even profitability. Each technology may warrant consideration. A “YES” answer to any of these questions typically indicates that some level of escrow protection is warranted.
- Mission critical – Is this application mission critical to the business unit?
- Profitability – Does this functionality enhance profitability of the business unit?
- Expensive – Have we invested significant financial and internal resources in this application?
- Is it expensive to replace? Retrain users?
- Is finding / deploying a suitable replacement difficult / impossible?
- Would our auditors or board expect that we have an escrow for this technology?
Financial Strength – Software companies are capital intensive and the industry is extremely competitive. Additionally, established on premise software companies that attempt to transition to a SaaS model often struggle financially under development costs combined with lower initial revenues and competitive pressures.
- What is the financial heath of this vendor?
- Is this vendor privately held or public?
- Is this vendor profitable?
- Angel or venture funded? If so, what is the history of these funding sources?
- What is our plan if they go out of business?
Performance – The initial performance and ongoing support of a software or SaaS vendor represent significant risks for enterprise end user organizations.
- What is the cost of downtime (per hour, day, week, month)?
- Are the deliverables (i.e. uptime, performance, support) clearly defined in our agreement? Are they objective enough that we can make non-performance a “release condition” under the escrow agreement?
- Can we add clearly defined release conditions to an escrow agreement to address concerns that were missed in the license or subscription agreement?
- Do we need them to make forward looking innovations? Are those clearly defined?
Cessation of Business / Bankruptcy – According to Fast Company Magazine 75% of venture funded companies fail http://bit.ly/2Akxjbi. Acknowledging this risk and negotiating contingency plans are the crux of an escrow agreement.
- What are the implications for our organization if the vendor files for bankruptcy?
- Does our escrow agreement contain a source code license protected under the bankruptcy code?
Acquisition – Many technology companies are acquired, some are acquired multiple times throughout their lifecycle.
- What risks do we face if our vendor is acquired? Can we opt out?
- What if our vendor is acquired by one of our competitors?
- What if the acquiring company changes pricing? Or delivery model (i.e. move from on-premise to SaaS)?
- What if the acquiring company “sunsets” the application we are using?
Development Methodology – The vast majority of software developers today have switched from waterfall development (release of major versions 1-2 times annually) to agile development (release of new features frequently, often weekly or monthly). Despite this mega shift in software development, most escrow agents do not provide reasonable solutions for frequent updating of escrow materials.
- Does your vendor employ agile development practices?
- How often are code level changes made?
- How often are the escrow deposit materials updated?
Data – Obviously you need ready access to your complete data. Vendor failure brings on data specific risks.
- Do we have access to our data now?
- Where is it backed up? How frequently is it backed up? Have we tested the data?
- Is our data commingled with data from the vendors other customers? If so, can they readily separate our data?
- Is our vendor storing our data in a manner and location that meets compliance regulations relevant in our industry?
Hosting / Redundancy – Hosted applications, SaaS or cloud applications present significant additional risks because downtime can be instant and permanent.
- Do we know where the application is hosted? Is the environment redundant?
- Do we know the account number and contact details for our instance at the hosting company? Can we take over the hosted environment if our vendor fails?
- What happens if our vendor stops paying the hosting fees?
- Do we have a plan for prolonged downtime?
- How long would it take for us to activate the escrow and recreate the application across all users?
- Can we have a colocation or “hot site” as part of the solution to eliminate downtime?
Alternative Providers – switching to another provider is an obvious plan should one vendor fail but this present many risks.
- Are suitable alternatives readily available?
- What is the migration process? How long does it take?
- Can the data be fully migrated? What are the costs? Timeframes?
- What is the impact of this migration on the business?
- What are the financial costs of the migration?
- How do we operate during the migration?
Mitigation of the risks outlined above generally fit into one of the three positions (Legal Protection, Tech Protection & Continuance Planning) detailed on the continuum below.
Risk Mitigation – Below are categories of risk mitigation that we have seen successfully used in escrow agreements and solutions in the past.
Legal Protection – The escrow agreement itself is a powerful tool when customized to address specific concerns related to each technology procurement, technology related partnership or investment. PRAXIS provides many customizable escrow agreement templates to suit a wide range of technology transactions. http://praxisescrow.com/resource-center-home/
- Deposit Materials – The escrow agreement provides an opportunity to define exactly what must be deposited under the escrow agreement.
- Updates – Technology typically changes over time (in many cases weekly or even daily) and thus escrow deposit materials often need to be refreshed or updated frequently. Defining the obligation to update the materials and specifying the frequency can have a major impact on the quality of the escrow materials and ultimately the success or failure of the application continuity plan.
- Release Conditions – These terms dictate under what circumstances your organization may receive the escrow deposit materials. These terms are typically written to address general and very specific concerns, many of which are detailed above in the risks section.
- Timeframes – Time frames related to the escrow depositing frequency, the duration of the release process and other processes can be critical and should be customized to address specific concerns. (Example: with SaaS applications it is widely accepted that the release process must be shortened to provide for rapid access to the escrow deposit materials because downtime can be immediate and permanent.)
- Transition Planning – Increasingly, escrow agreements include some form of transition services agreement between the software vendor and end user in the event that a release condition should occur.
- Licensing – Every escrow agreement should include a license for the beneficiary to have and use the escrow deposit which is typically not provided for in the license or subscription agreement. Can the end user expand their use of the technology upon a release? Are license fees still due? Does the beneficiary own the deposit materials following a release? All of these issues are often addressed in an escrow agreement.
- Key personnel – Many escrow agreements today require the identification of and the right to hire key personnel that are familiar with the technology and can easily support the transition to a new vendor or support the technology on an ongoing basis. Language is typically added that voids noncompete and nonsolicitation restrictions in license and subscription agreements in the event of a release condition.
- Hosting – In the case of hosted software applications or SaaS many clients add language to the escrow agreement requiring the Depositor to disclose full contact and contractual details on the hosting provider as well as grant permission for the Beneficiary to “take over” the hosted instance if a release condition occurs. This process is relatively simple with “private cloud” instances and more complex in true multi-tenant environments where data is comingled.
- Data – Many applications regardless of their delivery model (on premise of SaaS) hold some or all of the end user’s data. Many escrow contracts now include provisions for the data to be provide to the Beneficiary on an ongoing basis and in some cases the data can be stored with the escrow agent.
Technology Protection – Once the legal protection is in place and the escrow deposit materials have been received, the technology, in most cases, can be reviewed and / or tested by some qualified escrow agents, to determine the completeness, quality and functionality of the escrow deposit.
- Escrow Deposit Materials – The technology is very different for each application and thus the definition of the escrow deposit materials should be customized to reflect what would be needed for a “reasonably skilled” engineer to reproduce and support the technology in each situation. Also, requiring a broad range of additional items makes success more likely in a release scenario.
- Deposit Material Evaluation (“DME”) – Performed quarterly, a DME is a more detailed inventory of the escrow deposit, a test to make sure that all files are accessible, ensure credential functionality/accessibility, check for the presence of Source Code, create a file listing, etc.
- Code Review
- Testing / Technical Verification
- User Testing
Continuance Planning
- Hotsite / Colocation
- Data