Information Technology Management with a Purpose

Sep 27 2010   6:29AM GMT

Software upgrade guidelines

S R Balasubramanian Profile: S R Balasubramanian

We have witnessed rapid technology changes around us, along with an evolution of the software landscape. Today we run a host of application software packages ranging from office application packages on desktops/laptops to enterprise packages like ERP. Some of these are user oriented, while other enterprise packages are often mission critical, and should be dealt with carefully. CIOs frequently face the challenge of upgrading these packages from time to time. Now let us examine situations in which the CIO has to take a decision.

User packages like office applications on PCs are not much of an issue. For proprietary packages, we may either pay up AMC or take an upgrade charge (depending on the vendor policy), and then decide when to upgrade. In case of open source software, the call has to be taken by the customer in consultation with the service provider. Many a times, we face problems when some users are on the upgraded platform, while others are not. Files generated on upgraded software are sometimes are not readable on the older platforms.

For other specific application packages, the decision for an upgrade has to be taken based on the necessity. It also depends upon the position of the version in the product upgrade cycle.

The decision is often a bit involved when it comes to packages like ERP. Being a mission critical application and closely linked to the day to day work, any decision on upgrade has to be well thought of, as it has organization wide ramifications. I have found that CIOs often get stuck, and therefore defer decisions for too long. One of the main reasons is that ERP upgrade is a project in itself. It requires justifications and involvement of the organization.

There are two factors that influence our decision while deciding to go for an application upgrade. One is that the vendor announces the date from which a particular version will go out of support. That is a reasonable call, as the vendor cannot be expected to keep staff to support an older version. In such cases, organizations scamper to complete the upgrade since they don’t want to lose vendor support. Some organizations prefer to continue with the old version, and appoint a support person externally at a much lower cost. I consider both these moves— that is, either waiting till the last minute to upgrade or continuing on with de-supported version—rather dangerous and perhaps to be avoided. CIOs can choose an appropriate time to upgrade once he is told about the support schedule by the vendor.

The second situation requiring an upgrade is when the organization gets interested in doing so to enable use of features offered by the new version. I will cite two examples. In one of my earlier organizations, the decision for our upgrade to SAP version 4.7 and the middleware (Netweaver), was influenced by the company’s desire to implement CRM and SRM packages. These could have worked best in the newer version. Similarly, in the current organization, we are upgrading our Oracle EBS version R11 to R12, as we intend to implement a Production Planning system (with discrete and process manufacturing features as well as product costing), which is well served in the new version.

In either case, it requires a balanced view and the courage to upgrade at an appropriate time. Such upgrades require involvement of all the stakeholders to make it happen.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: