In addition to being a technical challenge, the move to a software-as-a-service platform involves several important business-level concerns that require attention. Believe it or not, it's not all about cost.
What's often overlooked in a SaaS migration is the service-level agreement (SLA). This is a contract on what a customer can expect from the vendor regarding key services. An SLA often will be written in favor of the vendor, so an organization that is about to begin a relationship with a SaaS provider should make an effort to know what's in the contract and what to look for in the details.
An SLA can be confusing, so it's a good idea to compile a SaaS agreement checklist. Key items to include on your list are uptime, billing, service details, licensing and consumption metrics.
1. Check uptime
One of the most common pieces to an SLA is uptime, and this typically gets most of the focus. Watch out for how the vendor's contract words the uptime specifics. Are they referring to availability or durability?
- Availability. This refers to the system uptime. Are the systems running and available for use?
- Durability. This focuses on long-term protection. After downtime, will all data return intact and uncorrupted?
AWS tends to focus on durability over availability. The number of nines associated with durability is much higher than availability, so that becomes the focus. Also, AWS and other cloud services will rename services, so the uptime outage counter resets on the new service name. These things can make it difficult to always get a handle on uptime because the history can be skewed.
Also, what happens when there is an outage? Oftentimes, the provider compensates a customer for the time down but not for the cost or impact incurred by your business. This means if you pay $15,000 a month for the SaaS product and you're down for 24 hours, that would be $500 in credit. But what if you lost $10,000 or $100,000 in business during those 24 hours? It is possible your SLA covers the actual business impact, but you can't assume that.
2. Examine the contract framework
Be sure to scrutinize the contract framework for terms of renewal, cost adjustments and billing. While these things might seem more like accounting, they can spin out of control without IT's involvement.
A SaaS bill can be confusing for IT staff. Imagine the challenges faced by non-IT personnel. While you don't have to verify every line of an invoice, it's important to ensure that extra services were not added to your bill. This sometimes happens when a vendor offers a free trial with a certain number of services; when a customer shifts from the trial to an annual agreement, the services and costs might be more than anticipated.
The challenge is that a SaaS bill can vary from month to month based on usage. It's not always easy to see if something gets added. A monthly checklist may help.
Another key element is licensing consumption. This is about as exciting as billing, but it has a big impact on your renewals. Licensing is driven by demand, and demand fluctuates. If you don't pay attention, you will find yourself spending money on unused licenses or facing a big licensing cost to catch up. Unlike other aspects of billing, trends in licensing consumption might not be apparent right away. It might be something to monitor every quarter instead of every month. Still, be sure you are aware of your licensing costs.
3. Evaluate support options
Service response time and escalation should also be listed on your SLA and verified periodically. Not all problems are equal, and you need to know when to expect a response. This can be a surprise for customers who heard, "Oh, we are staffed 24/7" during the provider's sales pitch. On a weekend, the actual response might be an answering service that pages a tech who will respond a few hours later.
This process will be spelled out in the SLA, but likely it will not be mentioned in the initial sales pitch. It's up to you to put this on your SaaS agreement checklist. Keep in mind, a vendor may be staffed around the clock, but that doesn't mean you can call someone. After 5 p.m., the vendor might switch to support via email, and there may be no escalation of a problem until normal business hours.
These details should be defined in the SLA. Support requests are critical, so you need absolute clarity.
4. Go over metrics
You'll want to verify the metrics that the SaaS provider uses to assess key things, such as outages, performance and timing for service requests.
For example, it is easy to think a four-hour on-site/service provision means the provider won't let you suffer extended downtime. When you have a request for service, what will the vendor's actual response be? It might mean that a technician calls you or sends an email within those first four hours. The problem itself might take several more hours or days to resolve. If these specifics are in your SLA, they might be buried in the easy-to-overlook fine print.
Metrics are often provided for the benefit of the vendor and not for the consumer.
For example, a provider might be clear that it bills per minute or per hour. What's less clear is exactly when the billing starts. Is 1:01 the same billing as 1:59? The answer is often yes. It's not that a SaaS provider is being dishonest, but, again, you might have to really search an SLA to find these sorts of details.