Monday, August 18, 2008

Why Code Escrow provides no protection

Escrow provides little to no protection for a client. There I said it. 

The reasons for this are numerous, however here are a couple of the main reasons:

1.) If the company providing the service does default in some way and the customer receives the code in escrow there is very little chance they will have the ability to re-create that application. I realize in a perfect world the code would be so perfectly documented that anyone could re-constitute that application, however that just isn't the case. No matter how diligent and well meaning a development staff may be there is still so much knowledge that is institutionalized and not in any documentation that it would be impossible to simply take that escrow code and make it work

2.) Even if the code was perfectly documented it is unlikely the infrastructure is. As web-based applications become more complex, the ties to infrastructure become specific. Even if the client knew much about the particulars (for example what web server, application servers, OS, DB, framework, etc) the work effort to recreate it exactly would be far from cost-effective

3.) In a SaaS model the escrow code is most likely outdated by the time an customer would need to re-constitute anyway. In a perfect world this would also not be the case, but in reality this is just the truth. 

I could go on, but you get the idea. What an educated client really cares about is the data, or at least what an educated client should care about. If the customer owns the data, and receives it on a regular interval they stand the best chance of protecting themselves in the event an escrow clause would need to be invoked.

If a customer has their data they can either move to a competitor more easily, or evaluate what the work effort to internally build the application. In all likelihood the best choice would be to move to a competitor. If the customer were moving from one SaaS solution to another that work could most likely be leveraged across multiple clients for the new vendor, and as such the effort wouldn't be "one-time" work for the new vendor, if it wasn't done for a previous client already.. 

That provides protection for the client, but also the mechanism that most likely will get them up and running as soon as possible.

If the ultimate goal is to provide some level of protection, code escrow just isn't going to do it. If your SaaS vendor doesn't have a mechanism in place for a customer to get their data on a regular schedule through some process (self-serve, asynchronous or synchronous data transfer) then choose another vendor.