I have a real problem when software companies artifically name new product releases with whole-number increments. My first example of this behavior was Citrix's insistence in increasing every Presentation Server version by a whole-integer increment (Presentation Server 3 to Presentation Server 4 being the most obvious one) when the actual changes to the product were minimal at best.

Today, in this article at ZDnet, I read that Microsoft is planning to change the name of the next version of their server operating system from Windows Server 2008 R2 to Windows 7 Server.

Note to Microsoft: Bad idea.

This distaste on my part has little to do with the obvious wag to their marketing department. My problem is that it gives the illusion there is more there than there really is. Worse yet, for IT decision-makers, who may not necessarily be completely "up" on the product, it gives them an incorrect impression of the level of risk associated with the upgrade.

Allow me to explain, using Citrix's misguided naming changes as the example. Let's assume that at one point you were an IT shop running Presentation Server v3. After a year or so of merrily humming along with your existing version, Citrix announces in big letters HEY EVERYONE, WE'VE GOT v4 OUT NOW! As the technical professional in your IT organization, you very quickly came to the conclusion that the upgrade included a few new user-exposed features along with a couple much-needed stability improvements. Effectively the upgrade is little more than the encapsulation of all the previous patches and service packs into a better and more-tested version.

Your subscription advantage agreement means the software is "free". The only costs going to the time to upgrade and any risks associated with a service outage due to the upgrade itself. Sounds like a no-brainer.

For your first step, you approach your non- or quasi-technical manager to get the upgrade approved. The manager, who knows more about budgets and the timing of their next CIO meeting, looks at that whole number version increase and incorrectly assumes it is a more complex and more risky upgrade than they're willing to sponsor. Maybe the last whole-number version upgrade of some other product didn't go so well. Maybe your internal processes say that whole-number increases require substantially added testing and project planning.

So, the upgrade is denied until you "complete further study." Or, instead of using your IT organization's "quick" project approval path, they force you into your "long" project approval path (as it is common for mature IT orgs to have both).

If Citrix in this example, or Microsoft in the theme of this post, had instead named the version v3.1 or R2 instead of a completely new product, your life would have been significantly easier. The upgrade would have been rolled out significantly faster. Yet, due to a marketing decision, your upgrade will be delayed as you go through the extended testing steps required by your organization's "long path" to project approval.

Note number two to Microsoft: This is why its a bad idea.

The summary of this story is thus, and its aimed towards all product vendors: Making whole number name changes to products when there isn't a good reason to actually hurts you in the end. It makes the product upgrade a more difficult sell to the risk managers of an organization. Conversely, if you propose and release small version increases - even if the "small" is in name only but includes "big" changes to functionality - you stand to see a much faster adoption rate.

Have you had a similar experience with overly boastful product name changes artifically slowing down your upgrade project? Let us know in the comments below.