Published OnApril 19, 2019This blog will help you determine your need for source code escrow agreements and the specific release conditions that are right for you.
It doesn’t matter who you are or what you do for a living, one thing is certain – technology is constantly changing. If you purchase the “latest and greatest” consumer technology gadget today, it will be outdated in less than 12 months. Now, think about your company’s relationships with your software vendors. In order to thrive, technology vendors must continually innovate for their applications to stay relevant in their market. For example, version 2 of a software application needs to be better than version 1 … and version 3 better be on its way!
Think of it this way: the value of your mission-critical software is constantly depreciating as your need and usage grow. Therefore, you must be vigilant to protect the important software applications you use.
This blog is part one of a three-part checklist. The steps outlined here will help you determine your need for source code escrow (also known as software escrow or technology escrow) agreements and the specific release conditions that are right for you.
Step 1: Do I need a Source Code Escrow Agreement?
When I work with clients who are new to the concept of escrow, I am commonly asked, “Why do we even have an escrow agreement?” And, although I can explain how Iron Mountain protects software source code and why this is important, only you will know the specifics of why escrow is needed for your software applications. The purpose for an escrow agreement is to mitigate the risk if an unforeseen problem occurs with your software vendor. Here is a qualitative equation that can help you think about your company’s risk tolerance for a particular application:
Operational Dependencies + Costs + Vendor Assessment x Investment of Time = Risk Factor
Delving in a bit more, here are four areas you should consider when identifying your software risk.
Operational Dependencies: If you lost access to your software application, consider the number of employees who utilize that application, the impact the application has on your customers, and the amount of lost productivity and/or lost revenue. Some organizations – such as emergency responders and hospitals – could put public safety at risk if an application is unavailable.
Costs: There are multiple costs involved with software, from the initial investment in development or customization to recurring license fees to installation and maintenance. If you need to switch vendors, retraining and reprogramming costs are involved.
Vendor Assessment: Each time you onboard a new technology vendor, you need to assess that vendor’s stability, track record, product offerings, and staff. A vendor’s longevity and funding also play into this assessment. If your software vendor goes out of business or is acquired, where does that leave you?
Investment of Time: In addition to operational downtime, consider the investment of time to replace a current software vendor. How long will it take to find a substitute application to replace your existing application? How long will it take to recode the software if it’s customized or embedded in other applications? Lastly, how long will it take to negotiate and review a new licensing agreement with a new vendor?
Thinking about this top-level equation should give you an idea of the magnitude of your risk and dependence on the application. It can help you assess your risk and decide on the need for a software escrow agreement for the application.
Step 2: Should I Modify my Escrow Release Conditions?
I’m sure when your organization started working with a new software vendor, a primary concern was around financial stability. How confident were you regarding the vendor’s ability to maintain funding? Were you afraid that the company would be bought by a competitor looking to gain market share?
Chances are, these concerns lessen as the vendor grows. However, a remaining and very real concern for many companies today is around lack of support. As technology changes, your vendor will continue to introduce new solutions and may eventually discontinue maintaining older solutions. Iron Mountain recommends that you review your release conditions on an annual basis to ensure your initial concerns are still concerns today. Chances are, your priorities may shift as your company becomes familiar with the vendor and their application, along with how much data you have in the system.
Bottom line: your dependency on the solution typically grows over time as your usage grows. So, you need to ensure your vendor is willing to continue supporting the application that your company relies on, even if it isn’t the very latest version of that technology. If your vendor decides to discontinue support, software escrow can provide a lifeline to keep your business up and running. This is why it is critical to ensure your escrow provisions are in line with your company’s growing concerns, year after year.
In part two of the Source Code Escrow Essentials checklist, I will discuss the importance of updating the contact information for an escrow agreement’s “designated contacts,” how to determine all of the necessary materials are present in the escrow deposit account, along with steps you can take to course correct any issues you identify if you believe your vendor has failed to provide information. Stay tuned …
Note: The chart above shows the risk factors for on-premises software applications. If you’re interested in one for SaaS risk factors, please contact me at firstname.lastname@example.org