Although it's possible to make substantial savings with cloud migrations, an unfavourable contract can spoil everything.
The internal "customers" of an organisation's IT group don't really care whether a particular application or service runs in-house or in the cloud. All they know is that it is IT's fault if a problem arises.
And those problems don't just involve the availability and performance of systems — the unauthorised access to, or leaking of corporate data or customers' data are also high on the list of concerns. This means it is important to get cloud deals right from the outset.
Despite the immature cloud industry falling back on "take it or leave it contracts", larger companies should push for their own terms to avoid being left in a sticky situation, according to Gilbert & Tobin partner Sheila McGregor.
ZDNet Australia goes through some of the areas companies should think about when negotiating their contract.
To prepare for a cloud migration, companies have to look at their own processes and data to make sure they are cloud ready and rewrite their request for proposal template.
The IT team will have been keeping a tab on systems, but will its monitoring tools work in a cloud environment? If so, the team needs to be sure that the provider will agree to the installation of any necessary software. If not, the team needs to work out how it will perform the required monitoring, according to Cindy McKenzie, senior vice president enterprise application management at Fox Entertainment Group.
Gilbert & Tobin's McGregor points out that companies need to be very clear about what type of data is going into the cloud. Data classification is always important, but takes on particular significance when dealing with cloud providers as companies lose direct control over how the data is protected.
The use of cloud services may spread through an organisation. What was right for a pilot project is probably not right for mission critical systems. McGregor advises that internal processes be designed to control that creep.
The customer is ready to migrate to the cloud, but is the provider suitable? Before going any further, due diligence is the order of the day.
Michael Overly, partner IT and outsourcing at Foley & Lardner, recommends that stakeholders be involved in the development of a standard questionnaire that covers all the issues important to the organisation, including (but not restricted to) insurance, security and the training given to the provider's employees. That makes it easy to compare the responses of different providers, and the selected provider's response should be incorporated into the contract.
The company needs to ascertain where the cloud provider will be keeping the data. If this is a concern, the contract should specify where data will be located (at least at the country level), and that it cannot be moved elsewhere without explicit approval.
Off-site backup can be prudent, but companies will still want to ensure the destination is acceptable.
Is the company relying on other providers? For example, some cloud providers rely on Amazon S3 for storage or Amazon EC2 for processing. It's no use saying your data needs to be held in a certain place if the company's subcontractor doesn't operate there, according to McGregor.
Is the provider about to go broke? Apart from the obvious matter of continuity of service, McGregor says you don't want to get into the position of having to argue about access to your data with a liquidator. If the provider is a private company and therefore not subject to ongoing disclosure rules, companies should require it to provide regular reports on its financial position, and retain the right to terminate the contract if they aren't satisfied. That should give them flexibility and lead time needed to switch vendors before the provider gets into serious trouble.
Does the provider hold information security certifications? If so, it should be obliged to hold its certifications for the duration of the contract, McGregor says.
Clauses requiring the provider's employees to be of "good character" aren't unusual, and some organisations interpret certain legislation (eg, against money laundering) to mean that screening of everyone involved is necessary.
"You don't often see much resistance [to certification]," says James Deady, senior associate at Hall & Wilcox, but adds that background checks "can be a bit harder [to negotiate]" unless the company deals with particularly sensitive or valuable information.
Companies also shouldn't think that's where the issue ends: organisations should routinely check that the provider remains in compliance. This means that contracts should provide the ability to perform audits and security tests, although McKenzie admits that the last point has been a hard one to negotiate.
Fox's practice is to have its own security team conduct checks on each provider once a year, but without notice.
It is important that issues around data ownership and privacy are covered by the contract.
There should be no doubt that all data remains the company's property.
McGregor points out that you need both the technical means and the contractual right to access your data in order to comply with government regulations, audit requirements and legal discovery.
"You need that provision regardless of whether there's a technical problem," she says.
McKenzie says that the contract should state which party is responsible for the cost of data breach notifications (in the event that either party is in a jurisdiction that mandates such notifications), pointing out that such regulations may be enacted during the life of the contract.
The contract should also require the provider to follow a timetable for the return of the data and deletion of all other copies of it at the end of the contract.
Data destruction following termination of the contract should be a standard provision, according to Deady.
"You want the data back in a particular form ... [and] assurances that it will be deleted."
Sometimes companies may ask for a statutory declaration confirming this has happened, and may also seek the right to inspect the systems.
"What do you mean by 'delete'?" asks Overly, suggesting that companies probably mean secure deletion to a relevant standard to prevent subsequent recovery, and that this process should also apply when a device is serviced.
But jurisdictional issues may come into play, he warns. For example, he was involved in a lawsuit where data had been transferred to Korea, where he said the law doesn't allow files to be scrubbed.
Cloud providers tend to ask for access to aggregated data, says Overly, who suggests that that should only be allowed if the data is completely de-identified: aggregated must mean aggregated such that identification by the selection of very small subsets is prevented.
When using cloud services it is important to document the steps taken to protect personally identifiable information, he says, especially in jurisdictions that require "reasonable" precautions.
McKenzie suggests spelling out exactly what information security precautions and data loss protection measures the company expects a provider to follow. The level of detail can be as fine as requiring the provider's internal systems use password compliance rules that are at least as strict as your own, or specifying the encryption algorithm used to protect data.
When looking at the fine print, there's often a pitfall or two that would be easy to fall into. But it doesn't have to be that way.
Providers may attempt to include material (such as a service level agreement) in a contract by referencing a URL. The problem is that such material can be unilaterally changed at any time, so it is wise to include the full text as an appendix to the contract. Those terms should also describe how performance is to be reported, says McKenzie.
The second issue is that users may be presented with additional terms and conditions when they use the service. The question then is whether or not an employee clicking through that window binds the organisation.
McGregor suggests that the contract should prohibit the provider from trying to amend terms with individual users or employees without the organisation's consent, and then go on to provide that if the provider tried to do that, the amended terms would be ineffective.
One of the key features of cloud services that make them appeal to businesses is elasticity — when you need more, you buy more; when you need less, you buy less. But that's not how it works in practice, McKenzie says. While scaling up is normally allowed, none of the contracts she's seen provide for scaling down.
"They don't want you to do that," she says. This point is especially important to her company, which routinely divests parts of its business. As for persuading such providers to modify their contracts to suit such behaviour, "let's just say it's not easy", says McKenzie. Her company has been able to gain scale-down provisions for divestitures, but not for situations where it has simply laid off part of its workforce.
Even if such provisions aren't part of the contract, Deady says it may make sense for the provider to agree to a downward variation during the term to maintain a good relationship.
Companies are used to negotiating contracts that define permissible price escalations during their term, but with cloud services it is important to consider what happens when the contract comes to an end. If there's no provision for a transitional period, the provider has the company over a barrel.
"It is really important to deal with [the transitional period] in the contract ... the time to negotiate that is at the start," says Deady.
McGregor suggests customers should expect the price of cloud services to fall over the term of a contract, as providers increasingly benefit from economies of scale and the general trend for IT costs to fall. This means the customer should be able to negotiate a better deal for contract extension.
Deady and McGregor agree that contracts should set out the responsibilities of each party when the relationship is unwound, and identify any charges the customer will face. Deady also recommends provision for a temporary continuation of service on the previous terms in case more time is needed to complete the move to another provider or a return to in-house operation.
McGregor says "it's a pretty standard condition" for the provider to be allowed to assign the contract to another company without the customer's consent. She suggests it may be sensible to list the companies that the customer regards as acceptable assignees rather than giving open slather to the provider.
The best relationships may go wrong. In these cases, the contract can serve as a "prenup".
A big client may be able to insist on an escrow clause that potentially allows the software to be moved to alternative servers in the event the provider goes out of business, although Overly says this provides very little protection in practice.
Terms that provide for automatic failover to another provider are also useful, but companies must remember that the service will then be provided under that provider's default terms, he says, which normally gives little contract protection to the customer.
Some contracts offered by providers make credit the sole remedy for outages, warns Overly, which severely restricts the customer's options.
"30 per cent of a monthly fee ... may be insufficient compensation if something serious happens," says Deady.
McKenzie recommends insisting on a clause that gives you the right to terminate the contract if agreed service levels are not met, while McGregor points out that you are unlikely to be offered any restitution beyond credit.
She notes that you wouldn't have any protection if an in-house operation failed, and that providers' margins are so low they are reluctant to accept any responsibility other than redelivering a similar amount of service at no further charge. One possibility is to insure against losses caused by a cloud provider's failure to meet agreed service levels.
If you want the option of claiming beyond credit, Deady suggests removing the "sole remedy" clause as a starting point, but warns that there may be interactions with other clauses designed to limit or exclude the provider's liability.
Watch out for service level agreements that are often couched in terms such as "try" or "best efforts", Deady warns.
When the negotiations are over, companies may find that the contract still leaves something to be desired.
Before they sign on the dotted line, McKenzie recommends that companies be sure that they reduce their expectations for the service if there are gaps between the functionality they need and that which is offered.
They may also be upset with the level of effort that was required to achieve the customised contract. Some work is underway to bring a degree of standardisation to cloud contracts, McGregor says, and if the needs of providers and their customers are taken into account that could reduce the amount of negotiation required.
If the cloud provider isn't prepared to negotiate for a contract at all, Overly suggests making outside arrangements to cover any shortcomings; for example, by making sure they can quickly switch to another provider.