Migrating Software - Don't making a meal of it!

Migrating Software - Don't making a meal of it!

Much conversation is had around the subject of software upgrades or migrations, ranging from the evangelist who trusts that every patch release and hotfix must be applied instantly, to the cynic who believes that all upgrades are simply the result of efforts by marketing departments to continually sell more hardware, software and consultancy.

Well, the truth is probably somewhere in between (as you would expect).  Extreme views or opinions on just about any subject should be treated with suspicion, and keeping up with the Software-Joneses is no exception.  There is no doubt that the need to provide more functionality in order to stay ahead of the competition (and retain or increase ongoing revenue) is undoubtedly part of any software houses’ remit, but similarly, the evangelist should ask themselves why those hotfixes are required in the first place…. a fair proportion of the time it’s to address issues raised by the last patch or version release!

I think there are 3 major factors that should be taken into account when deciding on an organisations software version policy (what’s that… you don’t  have a policy?!) :-

  • Risk: This is not simply the opposite of ‘reward’; the risk of critical platforms such as your Business Process Management infrastructure or Desktop Applications not being supported by modern Operating Systems should be taken as a reason in favour of migration.

  • Reward: Remember to extrapolate some of the more important benefits from the new feature-set.  For example, improved workflow is a feature, but the reduction in man-hours for a particular process, made possibleby the new functionality is your reward.

  • ROI: Try to put some figures around tangible benefits, but this is not the deciding factor when evaluating your option, it's more a way to justify common-sense to people who make decisions using little more than numbers.

Now, my last point may be a little provocative, but that’s because in the world of upgrades, the end consequences can be as horrific and costly as your imagination (or that of your FD) is capable of serving-up, so the figures you produce for ROI can always be brought into question.  Honesty is always the best policy in my experience – use ROI to justify the fact that migration work is not simply a money-pit and that there are tangible returns, as well as tangible costs.

And so to tactics.  Spending some time drawing-up a policy with a method of evaluation, and getting the stakeholders to agree this strategy before any major migration work looms, makes the sign-off that much easier when the dreaded day arrives, as there is nobody to persuade; everyone has already agreed what the requirements for a migration project are. This is a little like organising the business Christmas Meal - anyone that has attended one of these affairs will know, 9 time out of ten, the menu is circulated in advance so the venue can ensure adequate supplies and prompt service (well, most of the time!)  All you are doing by having a policy (and the discussions surrounding it's creation and ratification) is preparing the ground and managing everyones expectation, nobody can pretend they didn't know the upgrade was coming or what it involved.

And that brings me to my final point – the fact is, migrating or upgrading is not a question of if, but when.  In a very, very small number of cases, systems become obsolete and are consigned to software heaven (for example, fax gateways and processing systems are heading that way) but for the most part, we are all going to have to bite the migration bullet sooner or later.

I'd recommend laying the table and printing a menu in advance.

MIGRATING TO OPENTEXT MBPM v9