Software and hardware vendors today call it their survival strategy—launching fresh versions of products in order to prove that they are right up the street of cutting edge technology. While this breakneck speed of development ensures that products are constantly on the betterment path, it is usually difficult and often unnecessary for enterprises to match this speed of upgradation.

WHO’S THIS STORY FOR? An IT chief with a funds crunch, faced with upgrades requests from users, in a growing midsize company  WHAT DOES IT ANSWER? n When do I upgrades? How can I squeeze it into our funds?   n How can I upgrades whitout disrupting work?  n What do I do with old hardware? n What if I don't upgrade?

How is an upgrade different from a replacement? Users usually pay a fee for an upgrade that entitles them to new versions annually or more frequently. However, when vendors introduce new technology or architecture, they often create distinct products, which are not provided to users as part of the same fee. In such cases, old applications are gradually phased out and no new versions are introduced. If users wish to stay with the same vendor by migrating to the new applications introduced by the company, they need to enter into a fresh commercial arrangement with the vendor. At such times, users can also evaluate other vendors, since this amounts to fresh deployment, though it may be relatively easy to work with the same vendor. This is of course, less common as it requires major expense for the company and should be done only if required.

After implementing a business application, say ERP (enterprise resource planning), users typically spend four to five years with it. However, organizations do retain their applications for decades.

As long as the functionality of the application efficiently meets the organization’s work process, there is no need to upgrade the software or hardware. Desktop users with packages like office etc, on desktop OS’ (operating systems) like windows often get into the frequent upgrade tangle, which sometimes is unavoidable. These upgrades typically happen once in 18 to 24 months. Minor updates and patches happen continuously.

Need for upgrades
As technology evolves at a rapid pace, the time frame between two versions is reducing. At the same time, budgetary constraints do not permit CIOs to upgrade hardware as well as software as often as they would like to. How can CIOs strike the right balance between the two?

CIOs need to carefully consider the features and functionality actually being used by users in their organization. Version upgrades are driven by the collective requirements of users across the globe. Not all are relevant for each organization. Thus if there are no compelling business requirements for the upgrade, CIOs need to be cautious since the total cost of upgrades cutting across software, hardware, training, data migration, bandwidth etc. can be substantial.

Ideally, the economic justification for upgrades is in terms of increased productivity. However, in certain cases, upgrades may be justified for reasons of compliance, compatibility with customers/service providers, high costs associated with maintaining legacy versions, unavailability of skills and lack of continued vendor support. CIOs should consider the overall cost of upgrades viz a viz the benefits. Another strategy could be to quantify the losses (monetary and otherwise) that will occur if the upgrade is not made.

Finally, the CIO should try and upgrade across the board in logical units in order to avoid having multiple generations of hardware/software in the same unit or geographical location.

For example, changes in the tax regime may necessitate the upgrade of financial applications. Similarly, rapid changes in tariff policies may require billing applications to be upgraded frequently in the telecom industry. In the services industry, the focus on CRM may require rapid upgrades. Thus upgrade cycles are somewhat linked to the maturity of the technology or business application. As applications mature, the upgrade cycle stretches. The second important factor is the scale of deployment. An organization with 10,000 desktops needs to be far more cautious about upgrades compared to an organization with 1000 desktops. Upgrade projects in themselves may stretch to three to six months and organizations may be hesitant to commit themselves to upgrades year on year. For mature applications, there is a growing tendency to skip generations and synchronize desktop hardware and office upgrades to a 3-5 year cycle.

It is a tightrope act for most corporations. The decision criteria for CIOs will lie in making a decision based on the end-of-support date for the products being used.

Warning: Pay now or Pay Later!
It is imperative that enterprises do not fall behind current versions since support for the older versions will not be forthcoming after a given period.

Balancing the financial and operational benefits of delaying an upgrade is understandable, but up gradation is a must. If one does not upgrade for long periods, upgrades become increasingly unattractive in comparison to the power and features of new machines. Some technologies may become obsolete. The effects could be disastrous. Operations could stall and starting all over again may be difficult.

The issues of not keeping up with upgrades grow exponentially the longer a company puts them off. Not upgrading technology potentially affects the competitive advantage, creates large massive upgrades that are hard to manage, could impact employee productivity, and dictate spending in other areas.

By not upgrading or replacing applications on time, the organization risks not only loss of competitiveness, but also in extreme cases, financial loss. All these problems can be avoided if upgrades are properly planned and the vendor is committed to agreed performance levels, costs and time.

Implementation
It is very important to plan upgrade/replacement of enterprise applications so that disruption is minimal. Enterprise applications are usually mission critical and disruption can be hugely expensive. Upgrade/replacement should be in synchronization with the overall technology direction and priorities of the company. Sometimes, it may be strategically more important to replace than to upgrade.

If the application has been substantially customized, it is important to ensure that the changes are retained after the upgrade. Managing software migration is a complex process. In some situations migration is not a choice, but a necessity. Fixing the Y2K bug, for example, necessitated countless software and hardware migrations. Other situations will not be mission-critical but may be productive means of increasing your return on investment and reducing total cost of ownership.

Migration planning can require significant time, money, and technical resources. Users in your organization are likely to increase pressure to migrate as newer versions of software with new features become available. The management is likely to resist software migrations due to budget constraints. Balancing the factors that influence your decision is the first step in planning a migration.

You could conduct a detailed study among your users and create software and hardware reports to help you identify version and compatibility issues. Migrating one piece of software can necessitate other, more significant software migrations. Be prepared for this likelihood by investigating your enterprise…

Do you find users running software that is not compatible with the new operating system that you are preparing to roll out? Do you hand down hardware as new equipment comes in, thus creating a situation in which users need their hardware upgraded or adjusted? Do users make enough use of the product to make an upgrade worthwhile? Do all users need to be upgraded? Do the benefits of the new features outweigh potential compatibility issues?

Understanding the implications of a software migration is crucial to your decision to migrate, as well as to your planning process.

It is equally important to have a committed team to ensure the success of ‘Mission Upgrade’. The team needs to have an in depth understanding of why the upgrade is essential for end users. Team members should be equipped with detailed plans that have contingency options. Team leaders should be able to prioritize issues arising during the migration process and then direct the team to sort them out promptly. And team leaders should have skills to interact with users and iron out any doubts they may have.

Buying hardware
The need for desktop software upgrade arises as and when new versions are available in the market (though the user may not necessarily need it at that time).

For this reason, organizations should typically buy desktops with the best configuration that fits their budget. The pace of technology change often makes upgrades beyond RAM (random access memory) and HDD (hard disk drive) difficult/unattractive. Newer applications demand higher processor ratings and therefore old desktops even with sufficient RAM and disk-space are unattractive.

Organizations should plan for desktop lifetime of five years with a mid-life upgrade if required after three years. Software development organizations should plan to phase out machines in three years. The right balance is to go in for a package deal when buying desktops— a complete upgrade when the new OS, office suites are available, up gradation of hardware once in four years for desk tops on buyback or by lease operations. Hardware vendors can lease desktops and replace all of them at the end of three years.

Buying software
The need for software up gradation is dependent on a company’s area of operation as well as its business plans. If business plans are ambitious and aggressive, there is naturally a need for frequent up grades. The need for enterprise software arises when there is a major workflow or functionality change in the organization. One of the issues would be to ensure there is no downtime or business impact due to the upgrades/changes. Testing for stability of the new versions is another key challenge.

Sometimes CIOs prefer to wait for the newer versions to stabilize before jumping in to upgrade their versions, especially for software.

A school of thought asks enterprises to always be a version behind on aspects like desktop software. The idea is not to deny users what is the best in the market, but actually make sure it works well for your organization and then deploy it. A CIO could set up a mini laboratory (with just one or two PCs) in his department. These PCs could deploy the latest versions available, test it for a fixed time period and then implement the software across the organization if found to be good.

When old is not gold...
One of the prime reasons for resistance to upgrade is that the management sees "discarding of old hardware and software" as a waste of resources that were valuable till recently. Planning for the effective use of these assets is also a task the CIO has to undertake.

The first priority should be to re-deploy these resources to areas requiring lower configuration for computing needs. However, it is becoming increasingly difficult to re-deploy old hardware. Typically, the cost of buying new hardware is comparable to the depreciated cost of old hardware. Therefore new users do not see a business benefit in taking on hand-me-down hardware. Negotiating with vendors for exchange schemes is a good option. Also, while buying hardware, organizations must identify the useful life of the same, and develop the phase out plan and try to exchange with new hardware after this period.

Crystalball-gazing
As vendors outpace each other in launching products and versions based on the latest technologies, the rate of obsolescence is likely to be high. Portable devices, mobile computers and multi-function devices will add to the up gradation concerns of CIOs. It is difficult to predict where IT will lead enterprises in the next few years. Given the uncertainty that jet-setting technology brings, CIOs must make sure that the plans they make today, are flexible and adaptable.

Manjiri Kalghatgi