Posts in Cloud Computing
Winding Down a Cloud Computing Engagement

Like any other professional business engagement, a cloud computing relationship will come to an end at some point and it's important that both parties give consideration to what happens at that point. The contract end may be triggered by the expiration of the governing agreement term or it could be a result of a dispute between the parties leading to an early termination. As with many of these sorts of issues, the best time to consider and negotiate the end-game terms between the parties is before formation of the formal relationship. It's not to either party's advantage to wait until the expiration of the agreement is pending or the working relationship is badly frayed before discussing how to separate their interests.

On the other hand, there are several provisions related to the termination of a cloud computing engagement that may not necessarily apply in other transactions or that are of particular importance given the nature of the cloud computing transaction.

Ownership of Data

The governing agreement should contain clear language regarding ownership of the data contained within the cloud. In most cases, between the cloud services provider and the customer, the customer will have clear ownership of all data they move or otherwise input into the service provider's systems. In some cases there may also be proprietary data that is generated within the servece provider's software that the service provider does not intend to allow the customer to retain following termination or expiration of the agreement. In that event, that specific data and the expectations of whether that data can be downloaded and retained in any form must be discussed prior to signing the agreement.

Finally, the service provider may also wish to retain some form of the customer's data going forward as part of their core service offering or as part of an ancillary service. For example, an online payment processor may wish to retain information related to buying trends over the life of the engagement and use that information to address other markets or even sell that data to third parties. In any case, the customer must consider any such retention rights carefully and even where the service provider agrees to retain only "de-identified" information, the customer will want to consider any potential issues.

Data Extracts

When a cloud computing relationship is winding down, the customer must be fully aware that it most likely has valuable data -- and data that cannot otherwise be recreated -- present entirely in the service provider's cloud. Generally, the customer should have clear rights to extract all of their data (but see the possible exceptions above) from the service provider system upon termination of the agreement. The customer may also consider extending those rights beyond the termination of the agreement to allow a period of time for their team to confirm what information is needed and to ensure all data is obtained. It may also be desirable but perhaps not necessary to allow for a data extract at any time during the normal life of the agreement.

One important consideration regarding any data extract is that the customer must specify that the data will be provided in a format that will be useful to the customer in the future. Either a platform-agnostic format such as XML or an industry-standard format may be appropriate. Allowing the data to be provided in the service provider's preferred format may otherwise result in data that is of no value following ending of the relationship.

Transition Services

In addition to the rights to customer data, there may be a need for the assistance of the service provider in transitioning to substitute services. The customer may otherwise find it very difficult to map the service provider's data into the a new system. Discussions between the parties will be necessary to consider whether such services are to be provided at no cost to the customer (perhaps in the event the agreement is terminated due to the service provider's breach) or whether the service provider is to be compensated for their services, in which case the rates and reimbursable expenses should also be considered. Of course, the best time to negotiate the appropriate structure and rates is before the relationship turns sour.

Destruction of Data

Directly related to the provisions regarding ownership of the data and the service provider's possible right to retain some portion of the data, the agreement should also address requirements for destruction of any non-retained data following termination or expiration of the relationship. The service provider should be obligated to destroy any such data in its possession (except that it may rightfully retain) within a specified time period. The destruction should include any such data that may be contained on archival or backup storage. In addition, depending on the nature of the data in question, the service provider may also be required to follow specific destruction protocols to minimize the chances of future recovery. The customer will likely wish to have any such data destruction activities documented and verified in writing by the service provider.

Audits and Records Retention

Finally, although it usually not necessary to provide the cloud service provider with audit rights, in some cases the agreement may contain those sorts of provisions anyway. If so, the customer should confirm they have the proper internal procedures to retain the data and usage statistics that may be subject to an audit for whatever period of time the audit rights are available.

Service Levels: A Better System Availability Service Level

As I've pointed out previously, one of the primary service levels in just about any cloud computing / SaaS agreement is system availability. While there may be an exception in some cases where the availability of the system to the customer is far outweighed by other performance factors, it's rare that the availability service level is not considered the primary measure by which the vendor's performance is measured. This makes perfect sense since the customer's use of the system in a hosted environment is wholly dependent on the vendor keeping the system available and performing appropriately.

Is the System "Unavailable"?

The vendor's standard service level agreement most likely contains a default availability standard with service level credits in the case where the service level is not met over the period of measurement. For example, we might see a 99.9% System Availability Service Level measured 24 x 7 over each month. In this case, if the system is "unavailable" more than about 43.8 minutes in a month, the corresponding service level credit will be triggered. There are a number of items to look at closely when considering the appropriateness of this service level, but for the purposes of this post I'll focus on the term "unavailable."

With the vendor's starting language, "unavailable" is typically defined along the lines of "The Customer is unable to access the Services, excluding any downtime caused by an event outside of vendor's reasonable control." In some cases, the vendor may even require the customer to report a period of downtime before it will affect the service level. But this definition doesn't begin to capture the customer's needs for system availability.

A Better Definition

To begin, the concept of system unavailability cannot be dependent on the customer's reporting of the outage to the vendor. The vendor may try to persuade the customer that this makes sense because an outage that the customer is not aware of doesn't really affect the customer and therefore shouldn't trigger a potential credit. But one must remember that many systems may be used across company divisions by a large number of employees. An employee trying to complete the week's payroll entries in the accounting department in Poughkeepsie may experience an outage that doesn't allow her to complete her work yet may have no idea that the outage should be reported to the vendor or even where to begin to report it. Instead, the vendor is best suited to continuously monitor the system availability and report the metric to the customer.

Second, unavailability must be tied not only to the entire system but to the significant operations of the system. For example, it's entirely possible that a system is up and running but the availability to transmit electronic financial transactions isn't working. If that function is key to the customer's use of the system, then its unavailability should trigger the downtime remedies just as if the entire system were down.

Finally, as I'll discuss in more detail in a future post, a force majeure event should generally not provide an exception to meeting the availability service level. Essentially, a force majeure exception avoids the essential purpose of the system availability service level.

Sample Language

Here's an example of an availability service level that meets the customer's needs:

Vendor will provide at least 99.9% System Availability, measured on a per calendar-month basis. "System Availability" is defined as the ability of a Customer user to (a) access and transmit electronic payment information using the System, (b) record employee payroll information, and (c) generate ad hoc and month-end management reports. Loss of Service Availability caused by (i) Customer’s acts or omissions; (ii) Customer’s Internet connectivity; or (iii) Vendor's regularly scheduled maintenance windows as defined below will be excluded from Service Availability calculations.

Addressing Scope Creep

Software implementation projects can be difficult to complete on budget and on schedule and there are a number of ways projects can go off track. One potential issue to watch for is sometimes referred to as "scope creep," that is, the addition of functionality, interfaces, or other tasks to the project that weren't included in the original project plan. As the project progresses through the implementation cycle, it is almost a certainty that, at some point, the customer and software vendor will realize there are additional tasks needed that weren't clearly defined at the inception of the project.

There is no way to eliminate scope creep issues entirely from a project, but, as with many of the issues faced during the life of the project, scope creep is best addressed early to help minimize the chances of it occurring and its ultimate impact to the project timeline and cost. Here are a few ways I've found that should be considered prior to project initiation, during the RFP process and through contract negotiation.

/1/ Begin by Getting the Get the RFP Right

Without getting into detail on the procurement process, oftentimes, when a customer looks to acquire a large software system, the first step is development and distribution of a Request for Proposal. That RFP provides a detailed description of the customer's needs related to the new software: what problems the customer is hoping to solve, what functions the software must provide, needed interfaces, etc.

A more detailed and accurate RFP can be invaluable. If the customer spends extra time on the development of the RFP, that more detailed system description can be used to not only ensure a better understanding by the vendor, but can also be used to define the project scope to make it clear what the vendor is obligated to perform for the agreed cost. To achieve that, the RFP itself must be incorporated into the signed agreement; either in its entirety or the specific requirements set forth in the RFP can be included in the Statement of Work drafted by the parties and attached to the agreement.

/2/ Perform Additional Due Diligence Up Front

As a complement to the RFP, a clearer understanding of the entire project scope at the start will result in a more accurate project plan. Between the vendor and the customer, the party that best knows the licensed software's capabilities and limitations is the vendor itself. So, while the customer may have provided a well-written RFP, without applying the vendor's special knowledge to the equation, we've only seen half the solution.

It's in the both parties' best interest to make sure adequate due diligence has been performed by the vendor prior to contract signing to allow the vendor to probe more deeply into the customer requirements, needed interfaces, source and target systems, and similar considerations that may affect the project scope. The result of this due diligence work must then be included in the contract requirements document and also reflected in the project timeline and milestones.

In some cases, a vendor may be hesitant to expend additional effort prior to contract signing since the vendor is typically doing this work at its expense. In that case, the parties should consider splitting the project into an initial "Scope Definition" phase, in which the vendor performs additional work to define the project scope and the vendor and customer share some of the costs related to that work. Although the customer must commit not only monetary but also employee resources during to the scope definition phase, the potential reduction in risk to the greater project may be worth it. Following its completion, the customer then has a clearer view of the overall project and can make a more informed "go/no go" decision.

/3/ Put Some Teeth in the Project Estimates

If the implementation phase of the project is presented on an estimated cost basis -- rather than fixed price -- the risk of cost overruns due to scope creep must be looked at closely. In many cases, the estimates are used to "draw a box" around the scope of the project and any additional work over what is estimated falls into the project change control process. The change control process described in the agreement will often contemplate that the cost of overruns is to be apportioned to whichever party is the cause of the delay or additional work. But what often happens is that the parties argue about whether a given function should be considered either "in scope" or "out of scope" based on the project requirements (which may include the RFP, the vendor's response, the system documentation and more). More often than not, it will not be easy to agree on which party is at fault.

Instead, it's in the customer's best interest to make the vendor's project estimates have real meaning. That may mean converting them into true, fixed-price estimates or providing a strong incentive for the vendor to meet the estimates. The latter may be achieved by providing clear contract language stating that, unless the delay or additional work is the result of the customer failing to meet obligations described in the agreement, then the cost for additional work is either borne entirely by the vendor or done at a greatly reduced rate.

There are surely many other ways to address scope creep in a project. From the perspective of a customer or an attorney representing the customer in a negotiation, the tips above are worth keeping in mind throughout the development of the agreement.