3 Initial Steps to Define Your Software Escrow Plan

Iron Mountain
Contact

“When you don’t know where you’re going, any road will get you there.” Lewis Carroll’s famous quote from Alice in Wonderland is an accurate representation of some of the haphazard mistakes I’ve seen when managing software/source code escrow relationships.

In this blog post I’ll introduce three fundamental steps that I use in initial software escrow discussions with customers. They will help to define an effective escrow plan that will improve every escrow relationship, regardless of the software or technology solution being protected.

Step 1: Establish a Goal

When a licensee decides to include a software escrow arrangement along with their business agreement, they first need to think about their reasons:

  • Does the application perform business-critical operations?
  • Is the vendor small or unproven, and is there a fear of financial instability, bankruptcy, or acquisition?
  • Is the application customized, and would replacing it require a significant amount of time and/or effort?
  • Was a substantial investment made in the solution, making it hard to replace?
  • My Essential Checklist post covers more detailed reasons on why an escrow agreement may be needed.

To determine the goal for the escrow agreement, the licensee should imagine their fears coming to fruition. They should then walk through an “emergency procedure” as if the emergency actually happened. For example:

  • What information would they need access to? — Is it just the software source code because the licensee runs the application in-house? Or is it the source code, data, and the environment because the SaaS application is hosted in the cloud?
  • How long can the licensee function effectively without access to this application?

Next, they should create a plan as if the escrow material is being released.

  • Is all the necessary information available? (Ex. Files, tools, supporting documents, etc.)
  • Have the escrow materials been verified?
  • Will they recreate the application in-house or with the support of a third party?
  • How long will it take to get everything up and running?

(In our experience, the buyer or licensee usually drives the escrow requirement which is why Step 1 is focused on licensees. However, savvy developers are wise to offer escrow proactively as an assurance to their customers. If a developer is setting the goal, they should put themselves in their customer’s shoes.)

Step 2: What are the Necessary Materials?

A software escrow plan is more effective if all of the right materials are deposited. Only the developer can determine the requirements necessary to achieve the licensee’s goal, since they are responsible for providing the software solution and making the deposits into the escrow account. The licensee should review their goal with the developer to make sure the plan is realistic — and that is “everything” is included.

This often gets into a discussion about “What is everything?” Many licensees want to write long, specific lists of materials, however, I always caution again listing specific tools. Since technology is constantly changing, and the licensee could be limiting their capabilities by listing specific tools to deposit into the escrow account.

Instead, we recommend standard contract language that would be more comprehensive. For example, “the developer agrees to provide the source code, and all the files, tools, and supporting documents for their licensee to compile their source code.”

Step 3: How often do the Materials Change?

After a realistic goal is defined and the escrow materials are determined, both parties need to agree on a regular deposit schedule. No plan will work effectively if it is neglected and never updated. Both the licensee and the developer have a stake in making this agreement work properly, and to do so, complete deposits must be made in a timely manner. The escrow agent’s role is to facilitate that process and provide notices and tools to manage the escrow account.

Most developers will admit that their solution is constantly changing; or that they have plans for changes in the near future. We all know that the value of software is determined by its potential (i.e. future releases).

In order to determine the frequency of your escrow deposits, the parties should review the development plans for the application. If this is an Agile development application, then the escrow deposits should be frequent (weekly or monthly). If the software has a long development cycle, then the deposits should be a little less frequent (quarterly or biannually).

Conclusion

In summary, it’s always wise to start thinking about software escrow from a strategic viewpoint. How will it help? Will the developer provide all the necessary supporting materials? How can it be verified? What needs to be done to keep the agreement up to date? From there, the specifics can be determined for a successful escrow agreement.

[View source.]

Written by:

Iron Mountain
Contact
more
less

Iron Mountain on:

Reporters on Deadline

"My best business intelligence, in one easy email…"

Your first step to building a free, personalized, morning email brief covering pertinent authors and topics on JD Supra:
*By using the service, you signify your acceptance of JD Supra's Privacy Policy.
Custom Email Digest
- hide
- hide

This website uses cookies to improve user experience, track anonymous site usage, store authorization tokens and permit sharing on social media networks. By continuing to browse this website you accept the use of cookies. Click here to read more about how we use cookies.