When To Upgrade (and when not to)

I have often found people divided on this matter.  Some people always want to be on the latest version, it doesn’t matter what it is, but if there’s a newer version out there, they want it.  The other extreme is people clinging on to their old version and wanting it to run forever.  So much so that if they are forced to upgrade because of the operating system, they would rather run the older operating system as well.  There are arguments for both cases but camp A will get stung eventually when a new software release is detrimental and they can’t go back to the old version.  Camp B will get stung when they can no longer get support for their version and they are forced to upgrade.

So which is the better option?

Version Numbering

It comes down to understanding version number.

Version numbering comes in 3 Parts, Major Minor and Revision. A forth can also exist that refers to the incremental build number.

So we have version 1.4.8 of an application and they release version 1.4.9.  What can you expect to have changed in that release?  Not a lot in all honesty.  The most likely thing is bug fixes which were deemed urgent enough to make a release for.  It is these updates that you should avoid unless you have experienced the bugs in question.

The next upgrade might be version 1.5.2 this is a minor release; there may be improvements in security or a new feature requested by a number of users.  Again, I would be reviewing what the differences are between the two versions before upgrading.  If I’m never going to make use of those new features, it probably isn’t worth taking the risk of updating the software.

The Major release is the biggest upgrade you’ll encounter.  This could be a major overhaul of how the code works and the number of features that are available.  Not all major releases will have features added.  Some may be taken away because the development team have found they are troublesome to maintain and test.  Or based on user feedback have decided not to keep that feature.  Other reasons behind this could be incompatible operating systems or other software on the market or there could be legal reasons behind it.  The UI may have been overhauled giving it a different look and feel.  Users of Word 2003 to 2007 will have noticed a huge difference in how the application looks and operates (does anyone actually like the ribbon functionally compared to the humble toolbar?)

Switching Vendors

So there are reasons why you would never want to upgrade your software provided it is working as it should.  But what’s the other type of software upgrade?  This is where vendor switching comes into play.

Say you have Crystal Reports 8.5; you’ve kept with this version because it allows you to compile the reports and distribute them as Executables, thus eliminating the need to install an expensive licensed piece of software to all of the machines that need to run then.  Version 9 or later doesn’t allow you to do this so you’ve avoided upgrading it. After all, it works and you’re happy with it.

Sooner or later Crystal Reports is going to look very outdated compared to other companies software.  The terminology used within it doesn’t match any other products of a similar nature and guess what, anyone else joining your company isn’t going to have been trained in that version of Crystal Reports or maybe hasn’t even heard of Crystal Reports because it is that old.

So at some point you’re going to have to upgrade to something or face an extortionate bill finding the last person on the planet willing to get out of bed to support the legacy application.  I for one hope to make a mint out of writing conversion packages to take a report from one system and convert it to whatever other product is on the market e.g. SSRS.