SaaS Escrows – useful or pointless?

Friday, 26 November 2010

I keep getting called by traditional software escrow companies who are looking to move into providing such a service for vendors and customers of SaaS products. However, despite the glossy brochures I just don’t see how it can work.

With a traditional software escrow a trusted third party, such as lawyer or specialist escrow like the NCC, would hold a copy of the source code in trust for subscribing customers. If the escrow was triggered, by the vendor going out of business or even simply ceasing to support the product, the  customers could apply to the escrow company to release them the source code. All this made sense when the software product cost 100k or more, the escrow subscription cost the customer a few hundred and the customer had a large in-house team of programmers who could, in theory, maintain the inherited code. In practice I can’t think of a single example where an escrow was triggered, and I pity the poor programmer who would have had two million lines of COBOL dumped on him or her and told to update the system for a new tax rate.

But for SaaS the story is more complex. SaaS customers purchase a service, not a product, and what they would ideally like to know is that should the SaaS vendor go out of business then their application will keep running. To deliver the service you need the whole hardware & software stack: servers, firewalls, load balancers, operating system(s), web server, backend databases, plus a whole pile of add-ins for charting, pdf generation etc. And of  an up-to-date copy of the data, ideally sync’ed in real time. To make sure that all this would work in the event of an escrow being triggered the whole stack would have to built and tested, otherwise the chances of it working on the day are minimal. And, just to make life more interesting, whereas traditional software worked on a six month or yearly release cycle, SaaS systems get updated much more frequently, almost every day in our case. So what you end up with is a replicated datacentre that has to be tested every week to make sure that it still works. Which is basically what we at Really Simple Systems do, keeping a complete system on hot standby for instant switchover.

Doing all this is a lot more work than keeping a CD in a safe, and that cost would have to borne by either the SaaS vendor or their customers. As most customers are paying very little for their SaaS solution (because that’s the point!), paying the same again for an escrow protection doesn’t seem great value. And as customers aren’t clamouring for such a protection, it is hard to see why SaaS vendors would stump up a lot of money for something that their customers’ don’t see the value in.

A better solution is for SaaS vendors to put in their contracts that should their businesses fail, then the data legally belongs to the customer. After all, it is the data that is the most important asset in most systems – once you have the CRM data, then moving into another CRM system is not such a large task and could be done within a few days, even for the largest systems.

Which (he said smugly) is exactly what we do here at Really Simple Systems.