LinkedIn Twitter Facebook

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. His business interests include a diverse range of industries from manufacturing to property to technology. As a technology commentator he has a broad presence both in the traditional media and extensively online. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

More about Ben here.

11 responses to “SaaS Certainty – Escrow is the Answer”

  1. Pete Clouston

    Ben, this seems a great way to increase confidence around accessibility of SaaS data in the event of the vendor failing. However, with an unprecedented collection of SaaS customer data respositories, hosted in one place, multiplied by x SaaS products, probably with medium-high value to a disreputable party, security of the escrow repository itself would be at the top of my mind.

  2. Ben Kepes

    Pete – fair comment… escrow services backed by security assessment and accreditation?

  3. Lincoln Murphy


    Just like SaaS vendors need to drop the baggage of the legacy software model to fully benefit from the SaaS Business Architecture, so too must Business Continuity providers if they wish to attract SaaS vendors and their clients. Legacy business continuity methods, including escrow and “data vaults” are a relic of the legacy software business. The value proposition of source code escrow, if the vendor goes away or otherwise violates some SLA (the “trigger event”) then the client gets access to the source code and can run and modify the software themselves, fundamentally violates key elements of the SaaS value proposition.

    If I am leveraging a SaaS vendor, one of the things I am probably interested in (not always, but often) is that I don’t have to runt he application myself. What these legacy methods of business continuity give me is assurance that when something goes wrong, everything falls back into my lap. No thank you.

    The big problem is that just as in the SaaS world, where vendors use virtualized desktop, single-instance apps spun up on a VM (ASP 2.0?), etc. to “SaaS-ify” legacy apps, we have legacy business continuity vendors doing the same thing. Some vendors bundle their escrow service with online data backups and call it “SaaS Escrow” or something crazy. Regardless of how well they handle multi-tenant systems (I want app-level meta data and just my tenant data, please?), the reality is that I don’t want the raw data and source code. In most cases, I want Application Continuity which leads to the continuity of my business. (Remember: Business Continuity refers to the clients of the vendor, not the vendor)

    There are some vendors in the source code management and escrow space who are starting to move in the right direction. Chaperon, for example, has a real-time service they sell to legacy escrow companies that ensures the source code in the vault that is protected by the escrow agreement is up to date by hooking directly into SVN, git, etc. repositories. Chaperon basically allows escrow companies to come into the “agile” world. But at the end of the day, the “escrow model” is a non-starter in the SaaS world.

    OpSource and Servoy (announcement should be made in a week or two) both have interesting approaches to application continuity. I don’t know all of the particulars, but they will essentially keep the application running if the vendor goes away or otherwise defaults on payment. Whether this is for long-term continuity or just to enable clients a controlled off-boarding, it is more aligned with the expectations of the SaaS clients (which is who we are here to serve, right?). Again, not sure of the inner workings of the agreements between those companies and the SaaS vendors they work with, but for the clients, this is much better than getting a DVD with some source or object code and a data dump or even a fully functioning VM image of the app… I just don’t want it running on my premises.

    None of this, however, takes into consideration that a SaaS “product” is often the entire business for pure-play SaaS vendors. There is a lot more to a SaaS product than its core application. At Sixteen Ventures we say that the SaaS Business Architecture is a commingling of Marketing, Intellectual Property, Technology, and Business Model. When you look at it this way, its easy to see that, like most things in this business, providing business continuity for a SaaS vendor’s clients is not a technology problem after all.

    – Lincoln Murphy (
    Sixteen Ventures

  4. Pete Clouston

    Agreed…for me it would all hook on third party security accreditation. Some caution will still be needed given the unacceptable volume of data breaches.

    Lincoln mentioned ‘the “escrow model” is a non-starter in the SaaS world’. I’d have to disagree, Lincoln.

    Surely some recourse of action has to be available for the client in the case of a SaaS vendor failing?

  5. Suresh Sambandam

    I would agree 100% with Lincoln. The customers are coming to SaaS for no-hassle to run on premise. I once jokingly said in a panel discussion that the developers themselves are finding it hard to fix bugs in the source code they created and what would a customer do with the escrow source code. I don’t think source code is IP. Source code is just text files without the team behind it.

    We are PaaS provider. We deploy our application on ‘Google App Engine’ infrastructure. We use GAE as a ‘Cloud OS’ and we are like a middleware on top of it. One of the tenancy options we have among others, is to create a separate GAE account for the customer and deploy the app in that GAE account. This way the application keeps running for its life time (Okay, till Google’s Lifetime) as long as they pay the GAE bills.

    This is somewhat like opsource example, but is surely a better choice that Escrow!

  6. Lincoln Murphy

    The clients of SaaS vendors are indeed the end-users and as I mentioned in the previous comment, the idea that, in the event of a trigger event (not meeting an SLA, bankruptcy, something in between), you give a client a DVD with source or object code and a data dump seems to be counter to one of the main reasons why the client chose to use your SaaS in the first place. I like the idea of spinning up an instance in GAE or some other PaaS or IaaS for a client, at least for a controlled off-boarding, but for a sophisticated SaaS vendor, I’m not sure that is the right answer either…. read on.

    Other than completely violating the SaaS value proposition, source code escrow is just fundamentally flawed when it comes to SaaS in many ways. First of all, SaaS is not just technology. For pure-play vendors, SaaS is their only business. The business is directly tied to the application and vice versa. There are inter-dependencies not only with various technologies, but also various technology providers. So again, I might be able to take a snapshot of the operating environment and put it in my data center or on a VM in the cloud, but I will not get everything that was provided by the SaaS vendor. So tack on “ecosystem contracts” as yet another point that must be managed by someone looking to offer SaaS business continuity.

    How does this relate to PaaS as brought up by @suresh? Because if the SaaS vendor uses a PaaS, that is another business relationship that must be managed. But what happens if the PaaS goes away? The SaaS vendor is okay, and the underlying IaaS or Hosting company is still there, but the PaaS company fails (read: Coghead). Again, the answer to this scenario is also as clear as mud.

    For starters, the clients of the SaaS vendor have no transparency into the value chain that ultimately makes up the service they subscribe to. The SaaS vendor could leverage a PaaS that sits on an IaaS that is perhaps leveraging yet another vendor’s physical data center. The SaaS vendor could also leverage a third-party billing/metering system, single sign on service, and various commercial data feeds. The PaaS could leverage third-party monitoring systems, integration services, etc. that they provided to the SaaS vendor, who leverages that as part of the value-add for their clients.

    What is the answer? That is the $64M question that hopefully someone out there is attempting to answer. SaaS, or perhaps more appropriately Cloud, Business Continuity must take into consideration everything, including the source code, object code, database, infrastructure, ecosystem relationships, contracts, SLAs, etc. Complete visibility into all levels of supporting services, from the SaaS provider, through the PaaS, API proxies, IaaS, and down to the physical data center is probably what is required not just when determining business continuity but also when conducting due diligence on a SaaS vendor. The problem is, many of those relationships are part of the “secret sauce” so gaining that visibility will be difficult. There has to be an incentive for vendors to pull back the curtain.

    Just my $0.02…

    – Lincoln Murphy
    Sixteen Ventures

  7. jigordon

    Escrow doesn’t solve ANY SaaS issues unless the SaaS vendor is Microsoft, Sun, Apple (or running entirely on a linux platform)… because the problem with Escrow (as it existed in the past all the way through today) is that you don’t get all of the third party infrastructure needed to bring up the service/application. And even if you do have the infrastructure vendor as the SaaS vendor, chances are that your escrow agreement doesn’t provide all of the infrastructure apps necessary to run the service/app – you ONLY get the service/app code (and maybe your data – which you should have regardless and not have to pay extra for).

    As a side note: in the decade plus that I’ve been doing IT-related contract negotiations, and the decade before that when I was solely on the sysadmin side of things, I have never seen a successful escrow release.

  8. Alex Houseman

    You are all talking yourself into knots here. The answer entirely depends on what the Service IS that you are purchasing. Sometimes Escrow might work – other times a regular dump of the data might be enough to keep you going if the vendor folds. If this is totally business critical you’ll need alternative suppliers – as any sensible business will do with critical resources. Thinking that there is one size fits all is the usual sloppy mistake we continue to make. It means we still need Architects though!

  9. kirsty

    I liked your analysis. We did a similar one here you might be interested in reading:

  10. Chris Smith

    Having worked in the software & technology escrow industry for the past 12 years, I would be the first to agree that not every technology transaction would benefit from an escrow agreement. However, certain situations can benefit immensely from having an escrow agreement in place as part of a business continuance plan. SaaS has provided new challenges for the technology escrow community but it has not rendered the concept obsolete. Instead, we are seeing a larger percentage of our clients use SaaS escrow agreements and I believe that the argument can be made that the difference between the on premise solution and the SaaS model actually make an escrow more important.

    The primary differences (as related to software escrow agreements) that we see between a traditional on-premise installation and a SaaS delivery model are:

    Application, data & source code – with a SaaS escrow many of our clients are relying upon us to give them access to the application, their data AND the source code should a release condition occur. The addition of the object code and data to the escrow equation significantly raises the importance of the escrow if the beneficiary is relying upon us for access to the run time environment.

    Timing is more critical – with a hosted application downtime means immediate pain. Whereas, with an on-premise solution, many stable environments can continue to run for months even years with out direct support / involvement from the software provider. While the typical release process for an on-premise application might be 40 days the SaaS escrow must move much faster to prevent significant downtime and associated losses to the end-user. The typical SaaS escrow is released in a few days as opposed to weeks or months.

    Access to data – the common assumption among SaaS end-user’s is that they can just switch providers if their SaaS vendor fails. The trouble with that plan lies in the migration path and the timing related to the migration. Do I have my data? If not, how can I get it? Is there a suitable replacement provider? How long will the data migration take? What is the cost of interim downtime?

    Support – most successful escrow release stories involve support from “key personnel” from the then defunct software vendor. This is why including “key personnel” contact information in the escrow deposit is more relevant and critical than ever.

    Hosting – if a release condition occurs who will host the application? Is there a way to engage the current hosting provider to continue hosting the application short term while I make long term arrangements? Can my software escrow agent help with this?

    Testing – testing the SaaS application in escrow is both more complex and more important. However, testing the SaaS application is escrow with your data is the ONLY way to have a fool proof business continuance plan.

    As an escrow agent I love read discussions about the relevance of software escrow today. It’s a galvanizing question. Some people believe while others do not. Each person’s experience is unique and each situation is unique. I have been teaching attorneys and “C” level executives about our industry and the possibilities for years and while some of the details have changed the questions and answers remain the same. Not every SaaS solution would benefit from having an escrow in place but an escrow will help if it’s done correctly. And, like any insurance, you plan it well, put it in place and hope you never use it!