Real Story Group. Make Better Technology Decisions.

Irina Guseva

Follow Irina on Twitter @irina_guseva

No such thing as an easy upgrade with your CMS

17-Feb-2011

Tags: Web Content and Experience Management, Implementation

I always get a mild panic attack when I come across "simple upgrade" claims in the context of web content management systems. And it’s not because I find change and technical/infrastructure topics unnerving, but because I’ve seen those CMS upgrades in practice, and in real life, they are never simple.

If you think you can upgrade a packaged CMS with just an instruction manual in hand (especially, if it’s for a hot-off-the-press version of software), or by relying on some magic Install Wizard, you might be in for a rather unpleasant surprise.

The level of upgrade simplicity will vary from one CMS to another, with some (marginally) better at easing the pain than others. Your own people, implementation, infrastructure, and deployment patterns will play a key role as well.

CMS vendors don’t like to talk about upgrade difficulties. They will tell you that the upgrade path is a breeze --  all just a matter of swapping some .jar files and restarting your system. What goes thickly veiled is related software and database upgrades, the possible need for additional hardware, and the amount of human capital and effort involved.

I often hear how Web CMS customers hit major upgrade roadblocks. To be sure, some difficulties stem from a lack of organizational preparedness and pre-upgrade analysis. Other problems emerge from implementations that were simply flawed to begin with, but more commonly, the real problem is unsupported customizations.

The extent of manual upgrade work you'll need to undertake will be directly related to the amount of those customizations -- templating, extensions, integration -- your organization has applied. Most vendors will promise backwards compatibility for most customizations, but not everything you do may be "release-safe."

Moreover, nearly all vendors (and open source project teams) will sometimes rewrite parts of their products from scratch. Core changes -- in architecture, content repository, APIs, scripting, underlying content delivery services -- are the hardest to address here. No wonder some customers make a choice to stick with legacy bits and pieces built in 199x technologies. Call it "upgrade fear paralysis."

Given that upgrades are rarely a trivial task, be sure consider the following:

1) When doing any customizations/extensions of a platform, make sure to conduct a "release-safe" analysis on each, and count that into  longterm TCO

2) Track the "upgradeability" of all add-on modules, since you may be upgrading a whole family of services, rather than just the core CMS (and expect surprises here)

3) Remember that complex platforms are not MS Word: you're not just updating a piece of software, you're upgrading your entire CMS implementation

So the next time you hear “one-click update” from your CMS vendor rep, go ahead and raise a big, fat red flag. This doesn’t mean you should shy away from the upgrade or immediately file for divorce from that vendor. Just make sure to plan the upgrade carefully, with clear expectations and a grain of salt.