Having signed two more cloud contracts this month, it feels like a good time to share what I consider to be my top 10 considerations in negotiating a cloud vendor contract. As I was writing this, I had a hard time culling the list down to just 10. I’ve learned a lot over the years and have scars to prove it. There will be different views on this depending on whether you’re talking about SaaS, IaaS or one of the other horizontals in the space (PaaS, DRaaS,..), , but these 10 are generally applicable. So, here it goes:
1. Limit price increases – There is a lot of debate on whether or not moving to the cloud is actually cheaper than on-prem applications, and my answer is that “it depends”. There are many factors that must be considered (personnel time, upgrades, etc..), but license cost is a big one. What is a fact though, is that the longer the time horizon, the more expensive the cloud alternative can become. You’re paying a constant expense stream which can blow-up any ROI analysis over time. Other than negotiating the lowest initial price you can get, the best way to limit the cost over time is to reduce the pace and amount of future price increases. There are a few ways to approach this; the first being to go for as long a stretch as possible before the first and subsequent price increases. Most vendors will give you price breaks for longer contract terms. You might think this a risky approach as you’re committing yourself to a longer contract, but I’m assuming you’ve done your due diligence and are confident you’ve picked the right vendor. Even if things don’t work out as planned, which you absolutely need to consider, you’ll not likely be in a position to actually move off completely for 2-3 years. If negotiated right, the price increases will be tied to the contract length. The second part of this is to then ensure that each increase is as low as possible. I once negotiated a 0% first anniversary increase on a 3 year contract, basically holding my per user price flat for 6 years. I also negotiated a 5 year term with a 30 day out clause. No increase for 5 years and I can leave at any time. So my long-term contract risk is……..nothing. Try it; you never know what you can get.
2. Access to Data, Integrations and SSO – Some vendors are charging different prices depending on the availability of integration connectors or API’s, while others don’t charge extra for this capability. Even if you’re not starting out with a lot of integrations on day 1, you have to be prepared for the high likelihood of needing to get data in or out early on. Even SSO connections can sometimes cost extra to set up, or not be supported at all. If your cloud vendor is relatively new and doesn’t have published SSO connectors, make sure you include this capability in the contract at no charge. It’s in the vendor’s best interest to get this done and will help them in future contracts, so there is no reason for them not to include this. Integration and connectors are key for most successful cloud implementations, and a must for many, so it is frustrating that some vendors are charging extra for these. I get the tiered, a la carte approach that helps with revenue, but I think this is one area to focus on in your contract negotiations.
3. Flexibility on your license growth – On the software and platform side, the number of users will be a key factor in the ongoing cost. Having a good understanding upfront of your one and three-year growth scenarios will help you lock in lower prices on future growth. If you’ve hit a wall on the initial price, negotiating favorable discount tiers can help in the long run. The focus should be on having a low ceiling on your initial tier.
4. Exit strategy for data and access to data if the vendor fails – One difference in having your data in the cloud is the amount of control you have over it. So what happens if the vendor does go bankrupt? What if you do decide to move off to a competitor? A vendor failing isn’t a big concern for many of the top-tier providers, but it is something you need to think through and account for. I’m lumping this into your exit strategy for getting data out as it’s a similar issue. You need to understand how you’ll get access to the data and what your options are for getting copies. Ensure that you have some time to get your data out after your contract ends, in addition to language that ensures assistance from the vendor. Once you implement and once you get data integration up and settled, you’re already a step ahead in this process.
5. Development/Sandbox environments – If you’ll be making configuration changes to your SaaS app, or rolling out new apps or pages under a platform model, it’s important to understand the availability of sandbox or dev environments. The need is really no different than on-prem apps, but the type, freshness, availability and size of the data available are important, and can vary or be an extra price. Some vendors will apply this increase to all your licenses, so pay close attention to this and push hard to get as much included for free as possible.
6. Security – This is a very broad topic, so I’ll narrow it down to encryption and masking. Is data encrypted at rest? Is confidential data masked to those who don’t have proper access? For products that rely heavily on built-in uploading/downloading (storage and synch solutions), is the data encrypted during transmission? These are key considerations in comparing vendors, and you’ll find a wide variety of options available. Don’t assume that the biggest vendors are the most secure or encrypt your data at rest. It’s not as common as you would think. Data masking is also important for internal controls to ensure PII or confidential data is not visible. Not every vendor has this capability as standard.
7. Data Center Location – If you’re a U.S company doing business solely in the U.S., then your data center location will likely be in a region close to where you do business, if you’re dealing with one of the larger SaaS providers. For some of the smaller ones, you may not have much choice in the matter. For SaaS products, I have generally found the location to be not much of an issue within the U.S. It becomes much more complicated if you’re a non-US company or you do business or have offices in other countries as two issues then arise. First, latency in accessing your data becomes something you need to worry about so ensure you understand where your key users are for the app in question, in relation to where the vendor has its data centers. The second issue is around data residency and the various legal restrictions on where your data can be stored. This has always been something to consider, especially in the EU. However, the U.S. government data snooping scandal has changed the dialogue on this and made it a critical item to consider and deal with. It’s a topic that deserves its own write-up, so I won’t dive into the specifics here, but it needs to be on your consideration list.
8. Disaster Recovery Capabilities – Having applications in the cloud means you don’t need to deal with backups and disaster recovery yourself, but it doesn’t mean you don’t need to worry about it. Understanding your vendor’s approach and processes is important. Do they backup to facilities in other geographic locations? How long do they keep backups for? What are their RPO and RTO’s? Don’t ignore this just because you won’t be managing it on a daily basis.
9. SLA’s and Support – Up-time or issue resolution SLA’s are very important, but don’t expect a lot of flexibility in this area. The larger the company, the less likely you’ll get any movement. The top-tier vendors typically exceed their SLA’s but most will not budge from relatively low up-time percentages in the contract. Issue resolution response times vary widely, with many charging extra for quicker response. As a consumer of the service, I hate that model. They want to tell me my default is 2 business days for support unless I pay more. Really?
10. Storage and growth – The amount of storage is becoming a much smaller issue than it used to be, but it’s something you still need to understand and account for. If storage is a key part of the product, then you’ll likely be getting 1TB, or an “unlimited” amount of storage per user. However, some vendors still charge for storage. As with the growth of license counts, you need to understand your initial and future requirements so your future storage needs are accounted for up front. You’ll never have the same leverage as you do in the initial contract negotiations, so go overboard on growth requirements up front to be safe.
These are just some of the key items to consider. I know you’ll have others you feel strongly about, so feel free to chime in here or on twitter.
BusinessTech 