5 Reasons Why Software Escrow Won't Work For You
Posted by Chris Smith on Thu, Sep 23, 2010
Most software escrow vendors focus on helping you better understand why software escrow will work and though we share the same practices, we also want you to better understand why it would not work for you.
Don't get us wrong, we absolutely feel software escrow agreements are a necessity! On the same note, if you want to have a successful experience, you need to consider these pitfalls to avoid.
Software Escrow Won't Work For You If . . .
1) You don’t require it during the Licensing Agreement.
Why is this a problem?
While working with the Depositor, the End-User needs to complete the Licensing Agreement and Software Escrow Agreement simultaneously because:
- it's easier to come to agreement before the money changes hands and the project begins; and
- sometimes parties are unwilling to negotiate and / or implement the escrow later; and
- a license to utilize the escrow deposit materials is included in the escrow agreement. If the Depositor should file bankruptcy later they cannot extend this license.
2) You agree to do it after the license agreement is signed.
Why is this a problem?
It's often too late to request a software escrow agreement after the license agreement has been signed because the Depositor may simply refuse. Incentive to negotiate often changes once money has changed hands.
3) You do not create a detailed list (i.e. source code, name and address of key engineers, list of third party software, build instruction, etc.) of what you want included in your software escrow deposit.
Why is this a problem?
Think of it this way, would you buy a puzzle that was missing pieces? Chances are no, you wouldn't. So why would an End-User want an incomplete software escrow deposit that would result in an unsuccessful release? A Depositor would also want to include all necessary documentation to expedite the escrow process and to build a solid reputation and trust with clients and future clients.
4) You neglect to require a technical verification of the software escrow deposit materials to insure their completeness and functionality.
Why is this a problem?
More often than not, there is something missing from a deposit. We're not throwing the Developers under the bus, but human error is something we have to acknowledge. Missing passwords, incorrect build documentation, and missing code are just a few examples of critical data that technical verification would insure was included with your deposit.
5) You do not include a comprehensive list of “Release Conditions” that adequately address all risk management concerns.
Why is this a problem?
Without a well defined group of release conditions the End-User stands the chance of loosing enormous profitability and productivity. Imagine what would happen if some of your most important software used to run your business were down for days or even weeks, then what?