There has been a lot of talk about software as a service (SaaS) recently, and companies seem keen to jump on the SaaS bandwagon for good reason: it’s a subscription based service, so if it doesn’t meet your needs or expectations, you can simply cancel the service.However, there is more to consider when selecting a SaaS solution than simply trading in your traditional enterprise software. Users have to consider SaaS from a legal and business practicality standpoint because by using a SaaS solution, you effectively outsource part of your IT and, in some cases, business processes, which were previously managed internally. This raises a number of considerations and also changes many aspects of the buying cycle compared to the purchase of installed, on-premise software.

In this article we will explore several of these considerations in detail:escrow, service level agreements (SLAs), business continuity, privacy and relationship with IT.


Enterprise software purchases often include an agreement to place source code in escrow - to be released if the vendor discontinues operations. The purpose is to protect a customer in the event that a vendor meets its demise.

Even in the enterprise software space, these escrow accounts have a number of problems. From the vendor’s perspective, they are in effect writing an insurance policy that by definition the vendor will not see enforced. The more serious problem is that, until the vendor is insolvent and the source code is released, a customer has no way of knowing if every important portion of the code has been included and is up to date.

Additionally, while escrow covers a vendor going belly up, it does not cover the more likely scenario that a vendor withdraws a product from the market or discontinues support. Still, given the relatively low cost of escrow and the common acceptance of it, a customer might rightly conclude it’s worth having.

All of the previous comments are applicable in principle to SaaS vendors, but there are also important additions that effectively nullify the value of escrow in any realistic scenario.

With on-premise software, if the vendor disappears, the system may continue to run undisturbed for many years on the customer’s site. Once the system has been in use for a while, the number of new bugs discovered tends to zero. With a running system in house, the customer can examine the escrowed source code at their leisure, fix any problem and compile a corrected version.

With a SaaS system, the system goes away the day the vendor does. There is no option to continue running while you get the escrow code and review it. In any SaaS business, a large portion of the value is related to the actual operation of the service. The customer has no responsibility for the servers, upgrades, integration or maintenance. In other words, once the escrow clause is exercised, the customer will be the recipient of the software application, but nothing else. Not only will the software have to be installed, first an infrastructure needs to be put in place. It is difficult to see that this would be desirable when a data migration to another vendor is the alternative.

Also, while the SaaS system looks very much like any other application to the customer, the vendor has a very different perspective as they will be running an operation geared to support many hundreds or thousands of customers.

As you may imagine, this is a significant investment and requires a lot of sophisticated software. As a general rule of thumb, for every line of code you access as a customer, there is an equivalent amount of code acting to manage the multitenancy environment. This systems management and support code is typically very closely coupled and leads to the obvious question, is this included in the source escrow? Also, what about installation instructions? Even with full access to the code, it would simply not be possible to create your own installation of a service like without an enormous effort and specialized knowledge that is almost certainly not in escrow.

Take Away: With SaaS, there is no value in escrow.

Service Level Agreements

Most companies want to define the terms of service of a SaaS agreement and to also define expectations of service availability. In some cases, customers formalize these expectations into SLAswith penalties in place for nonconformance.

Customers find it difficult, however, to agree to the terms of a penalty clause that constitutes proportional compensation for loss of service absorbed as a business risk by the vendor.

It is misleading to compare the practice of penalty clauses in large outsourcing contracts, because their vastly larger scope and size enables realistic penalties to be absorbed. Also, there is typically a bonus structure that offsets the penalty structure upon over-performance. SaaS contracts may be only $20 to $50 per user per month, and this simply does not provide sufficient margin to hedge against a reasonable penalty clause.

The best approach is to review the vendors’ track record of availability. Also, the customer should always have a backup plan to migrate to an alternate vendor or solution should the service provided not be acceptable.

Take away:Don’t rely on SLAs. Instead, research your vendor’s track record.

Business Continuity

In my opinion, customers should always satisfy the effectiveness of their vendors’ business continuity plans. The practicalities of both SLAs and the lack of escrow place an additional emphasis on business continuity and imply that the customer has a business continuity plan to switch SaaS vendors if required.

It may not require anything as dramatic as the collapse of a vendor to force a system migration. All companies are continually rationalizing product lines. Getting out of markets can be as important as getting into markets. In fact, product lines do not even have to be unsuccessful in the market’s eyes. They can be very successful, but if they fail to make a profitable contribution or are otherwise deemed nonstrategic, they can be dropped by the vendor in an instant. That means a customer should be prepared to swap out the application/service as a complete unit if required.

This means taking care to ensure that there is a number-two supplier. It doesn’t need to be functionally complete, just good enough to tide you over if your preferred supplier or product line goes away. More importantly, it requires that you maintain an adequate and verified backup cycle, where any unique content is backed up and stored commercially, legally and, practically speaking, independently of the SaaS vendor, by the customer themselves.

Take away:Products go away. Have a backup plan.


Privacy is top of mind for all companies. It is important to ensure that content privacy and ownership rights are not abused by the SaaS vendor. Unfortunately, this is most often a problem for SaaS vendors who rely upon a business model based on advertising. It is not uncommon for employees to use a service like this for company business without considering the ramifications.

Google is perhaps the best known example (but far from unique), and their business model is the aggregation of the world’s content, providing users with easy access paid for via a model that targets advertisements based on content. Google has become world famous because of their effectiveness in that mission, but what is sometimes overlooked is that the model is predicated on Google’s and Google parties’ ability to read information about you.

The license agreement for Google Docs ( (section 11) puts this in black and white:

By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services.

You agree that this license includes a right for Google to make such Content available to other companies, organizations or individuals with whom Google has relationships for the provision of syndicated services, and to use such Content in connection with the provision of those services.

Apart from commercial breaches of privacy, an increasing amount of litigation has relied upon electronic discovery, and this has a number of implications for SaaS providers holding your content.

Because all SaaS vendors are multitenancy and share a certain number of resources, does this mean that if federal investigators demand access to company X’s data, they would also see company Y’s?The jurisdiction applicable to your SaaS vendor may affect the form and notification of disclosure of subpoenas. An important part of any due diligence process is to satisfactorily answer these questions.

Take away:Understand your vendor’s privacy policy. Your data is at stake.

Relationship with IT

IT is responsible for many things - hardware, networks, software, installations, projects, service levels and applications. Suddenly business professionals can get all of these with little more than an Internet connection and a credit card. This might legitimately give IT pause about the impact of the model on its own profession.Articles such as “Does IT Matter?” by Nicholas Carr (Harvard Business School) reinforce these concerns.

In some companies, business users may try and use SaaS as a way to run around IT, but this is rarely a good idea. IT should have a central role in the critical evaluation of SaaS applications to make sure the vendor chosen will meet their standards, especially with regard to security.

Take away:IT is your friend when selecting a SaaS vendor.Include them in the evaluation process.

There is no question that SaaS provides companies with a wealth of new opportunities to cut costs and increase operational efficiencies. But, at the same time, SaaS represents a new business model that requires customers to change their evaluation practices.

Customers should ignore penalty clauses and escrow as insurance policies and instead take a proactive approach to business continuity at the vendor level. This means taking their own backups of unique content and having a migration plan to an alternate vendor in mind. Finally, while many things change with SaaS, many things stay the same. IT’s involvement is crucial to assist with due diligence and in ensuring that adequate security and privacy provisions are in place.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access