At every conference or gathering of IT executives, the topic of contracting with Cloud vendors is brought up. It’s fairly obvious after listening to the conversations that there is little ‘real’ experience negotiating solid cloud contracts that protect our interests, but there is collective angst over contract areas like service level agreements, security, data protection, data ownership, insurance, liability, and many other topics. I think it’s important IT professionals share their best practices from negotiating cloud contracts, so that we can all improve the overall cloud industry by ensuring the vendors are delivering solutions with contractual terms that will allow all of us to embrace the cloud for servicing our customers. Therefore, to start the sharing activity, I’ll share my experience on two contract areas.
One of the tenants of cloud computing is ‘demand pricing’, which basically means paying for what you use. In reality, very few cloud providers support demand pricing that flexes both up and down. The vendors are very interested in negotiating terms for flexing up (e.g. adding more services and cost), but are reticent to negotiate any ability to flex down (e.g. reduce services and cost).
With our on-premise vendors we, as an industry, long ago lost the ability to buy software that allowed us to reduce our costs or maintenance fees, if demand decreased. That’s a tragedy we can ill afford to repeat. Therefore we must ensure we force all cloud vendors to build in true demand based pricing into our contracts, which allows a reduction of costs based on reduced demand or actual use of their cloud services. The key is to ensure our cloud contracts dictate how frequently we can reduce services based on our demand need, and that the reduction in services must reduce our costs.
Many cloud providers continue to negotiate contracts based on number of users, pooled users, or other legacy on-premise software criteria. Even if your cloud provider still tries to contract using on-premise terms, make sure you negotiate the ability to reduce demand on a pre-determined timeframe (ideally quarterly, but at least annually), and make sure you pre-negotiate the basis for reduction (e.g. how to measure changes) and the resulting cost reduction.
Don’t listen to the inevitable vendor cry of “revenue recognition” as their excuse why this flexibility can’t be negotiated. That is baloney. Revenue recognition is the vendor’s problem, and it’s a problem the vendor can solve on a quarterly basis with their quarterly financial statements, so frankly it’s not your problem. If the Cloud vendor isn’t willing to negotiate downward flexibility, you should look elsewhere because you aren’t talking to a cloud vendor, you are talking to an ASP.
Data ownership is relatively easy to negotiate, but there are some interesting nuances. The simple part is ensuring that the terms dictate you own the data. An important addition is negotiating the ability to get your data if you terminate or exit the contract. Make sure you can get your data in a format you can use. The best solution I’ve seen is to negotiate terms such that the vendor is to provide you with regular exports of your cloud data that you can then store on premise at your organization. The good news is most cloud vendors have data export features, so even if you can’t negotiate for the vendor to automatically provide these services to you, you can still manually implement local exports/backup of your the data from the cloud environment and store it locally, preferably encrypted on your SAN.
Also be sure you can get your data delivered to you during the contract, during any breach of contract, and if you exit the contract for any reason, including if the vendor exercises their right to exit the contract. Also make sure you can get your data if the company files for receivership, bankruptcy, or is bought/sold, or sells any of its assets that support your service and your data which is stored in the cloud.
Lastly, ensure the contract allows you a “transition period” to move your data to a new cloud or other provider if you plan to exit the contract or not renew the contract at term end. I’d suggest a 6-month transition period, but that really depends on the complexity involved in moving whatever the service is.
Next blog I’ll discuss security and service level agreements.