Skip to content
Can you ride the runaway costs ...
Can you ride the runaway costs ...

A Surprising Problem with SaaS/Cloud: Long-Term Cost Trends


When considering SaaS and Cloud solutions, you need to anticipate and acknowledge this important difference from on-premise systems; your ability to manage cost may be severely reduced.

I noticed something this week, in conversation with a number of folks about Software-as-a-Service (SaaS) and Cloud Computing offerings and contract terms. Everyone was complaining about a consistent, aggravating fact: SaaS contracts provide for an annual subscription fee increase – your costs will predictably, consistently go up.

Specifically, the typical terms I am seeing include an annual per-seat subscription cost increase; usually by a CPI multiplier, sometimes with an additional fixed amount – sometimes up to 5% (wow). Of course, when CPI is flat or negative, there is no provision for a cut in prices – some agreements even specifically say that the CPI impact can only increase the subscription cost. And the incremental 1-5% on top of CPI? Everyone is having a difficult time figuring out where that magic number comes from.

Permitted vs. Enacted

To be fair, many (but not all) “traditional” on-premise software licenses provide for annual CPI-type increases (in technical support / maintenance). However, I know of many long-term relationships where on-premise software vendors have never increased the annual maintenance fees. And, of course, both traditional maintenance and SaaS annual increases are subject to negotiation – again, I’ve worked with many who have had the conversations and worked with the vendors to reduce and/or eliminate the increases.

The Problem: An Expectation of an Increase

The cognitive dissonance I am experiencing has to do with the baseline expectation from the vendor that their revenue will go up every year. Even if our user count / transaction volume stays the same, we are contractually committing to a planned program of future price increase. Inflation based on … nothing; costs will increase every year.

In contrast, most IT departments are focused on cost reduction (previously lamented here), because the strong expectation is that the total budget (or at least unit cost-per-user) will go down every year. Heck, that’s not even limited to IT; the Operations folks are consistently applying Lean concepts to take costs out of the production process. Productivity is the magic justification for many IT projects, all based on the high-minded idea that I will amass productivity improvements across my team, and either lower costs (cut heads) or free up resources to do more work for the same cost.

So if iterative (year-over-year) cost cutting is an expectation when you internalize systems, why should I accept the opposite when I externalize (outsource / SaaS)?

More Features = More Cost; A Forced Decision

Ok, I already know the vendor counter-argument; the SaaS model delivers incremental benefit every time they do a version upgrade. And, the “great value-add” of SaaS is that they have the process down such that version upgrades are slipstreamed in – all customers get the same version upgrades seamlessly. Just like the apps on my iPad – I get new features and functionality every single day (whether I asked for them or not). Apparently, that’s the value that you are paying for when you get these CPI + x% cost increases.

I can argue this from many directions, but here’s the key point – we can do the same with on-premise software. Anyone can, if they want to take the time away from other projects. But in a typical organization, what really happens? Companies put off upgrades, version changes, new features, etc. because they make a cost/benefit decision every time the opportunity for change comes up – and often choose the path of delay and inaction, because business operations (or, perhaps people’s appetite for constant change) cannot afford the disruption and loss of focus.

Yes, this can be a problem when you get “very far behind”, but remember, this is a cost / benefit decision point that the SaaS solution takes away from me. I am forced to take the version upgrade – and so I am forced to take the price increase. Where is my option to keep costs flat by forgoing the upgrade, delaying the new release? Internally supported systems give you that option, externally supported systems do not.

Not a Luddite Whine, but a Teachable Moment

Don’t get me wrong – I am actually a fan of the flexibility, speed, and functionality that SaaS and the Cloud offers. I like the idea of buying a set of best practices, and I want the regular, incremental, ongoing design and development output of an organization dedicated to a vertical application. I am in the manufacturing business, not the [sales / marketing / HR / finance / data center / etc.] business.

But when evaluating a shift from internal to external sourcing for a system, service, or software application, it’s important to call out the full budget impact of the decision. Specifically, any cost justification must, for example, bake in the cost increases (even if you plan on negotiating away as much as you can when the time comes). Our frustration with our stale systems will go away, never to return – but the flat-to-decreasing support costs for those systems will also disappear, replaced with inexorably increasing invoices from our vendor.

For internal IT, there is an important point embedded here. If you aren’t doing so already, start quantifying how the IT group is “paying for itself” and “decreasing cost per user” by detailing the productivity / cost saving efforts you are completing each year. At the very least, it gives context to the other departments that want to break away from internal IT – can their new systems deliver the same year-over-year reductions? Alternatively, can they quantify the benefits we will gain with the increasing costs?

Or maybe, just get the vendor to strike the Price Increase language from the services agreement …

18 August, 2013

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Articles