Last week I received a message from a friend discussing the annual fees his firm pays for their hosted Web CMS. The CMS and associated website are served up by a well-known, Software as a Service ("SaaS") WCM vendor. My friend had been comparing notes with a colleague at a similar organization -- who was paying substantially less in annual fees to an installed CMS software vendor -- and came away puzzled at the difference.

You may already know this, but it bears repeating: the fee structures between traditional installed software and SaaS solutions are quite different.

In this case, my friend was paying for monthly CMS application hosting, as well as website hosting, in addition to traditional maintenance, support, and upgrades. (And with a SaaS platform, the upgrades happen automatically.) His colleague's organization was paying only maintenance and support, probably something like 20% per year of the upfront software fee they shelled out initially.

As a broad generalization, the license formula for SaaS solutions is "pay-less-now-and-more-later," while for installed software it's "pay-more-now-and-less-later."

But when you dig into the details, it becomes much more complicated than that. What's the total cost of ownership of your installed CMS in years two and three? Surely more than just the vendor's maintenance fee. Servers and applications need care and feeding. Software requires patching and updates. Internal staff resources cost money, even when they don't fall under your department's budget. Finally, with either approach, you will consistently want to tweak and enhance your application, and those development costs frequently dwarf your other outlays.

Still, don't assume that the SaaS alternative is always less expensive. When we help our customers do the math over several years, we often find the SaaS approach costlier.

For example, some SaaS business models don't account well for outlier scenarios. We recently saw a proposal where a SaaS WCM vendor bid an enormous annual pricetag for a comparatively simple website. Why? The total amount of content was quite high, and this played a decisive factor in pricing. At the same time, I've seen surprisingly low-cost SaaS bids for small, yet complicated websites. In either case, the line between "support" and "customization" can get very blurry. (So can the line between true SaaS and "managed services." Scour contracts carefully.)

So in those cases when we advise a research customer to consider a SaaS route, it's usually for structural reasons rather than financial. The right approach may hinge on your internal capabilities and experience -- an area we plumb in more detail in our advisory paper on Platforms versus Products.

In the end, when comparing vendor bids, you need to normalize pricing across multiple years and dimensions. Let us know if we can help you.