IT upgrades without excess
Deb Shinder
Published: 21 Nov 2005 16:20 GMT
...from your e-commerce site because of the site's slow performance, speeding up the site is an upgrade priority. But you still must analyse the cause of the slow performance to determine whether you need to upgrade your Web server hardware, Web server software, or your network infrastructure (perhaps moving from a T-1 to a T-3 Internet connection, or spreading the load across a Web server farm instead of overloading a single server).
Of course, in real life your upgrade priorities may not always be based strictly on need. If the big boss wants the top of the line multi-processor workstation with 4Gb of memory and a high-performance video card just to read email and compose the occasional Word document, there's a good chance he/she will get it. In general, though, don't over-upgrade. Plan to give your users the hardware and software that's required to most effectively perform their job tasks — and no more.
Consider dependencies
Upgrading some categories may be dependent on first upgrading other
categories. For example, you may not be able to upgrade your
productivity applications until you first upgrade the operating systems
— and you might not be able to upgrade the operating systems until
you've upgraded the hardware.
It can work the other way, too; if you upgrade the operating system, you might be forced to upgrade the productivity application because the old version doesn't run well (or at all) on the new operating system.
These dependencies affect your upgrade priorities and timelines.
Phased rollout
Once you've decided to upgrade a particular category or subcategory,
you shouldn't jump in feet first and roll out the upgrade to every
system or device in that category. What if the upgrade causes major
problems that make systems or the network unusable? The most prudent
strategy is to roll out each upgrade in phases. Test it first in a
non-production environment. This gives you a chance to work the bugs
out without any impact on employee productivity.
Next, select a pilot group to test the upgrades in the production environment. If the new hardware or software entails a learning curve, roll it out first to power users, those who are more technically savvy and thus better able to handle the new way of doing things without overwhelming your support staff. Once they've mastered it, they'll serve as a resource for helping other users make the transition when you roll it out to the rest of the department or the rest of the company.
Keeping it scalable
Your upgrade plan should be set out in writing and you should get input
from different departments and different levels to help you create a
plan that will create the least disruption and proceed smoothly. You'll
need to know about any plans for expansion (geographic and in terms of
personnel), so you can include the additional locations and/or users in
the upgrade plan. Likewise, you'll need to know if there are
restructuring, consolidation or personnel cuts in the company's
immediate future. It would be a waste of time and money to upgrade
systems that will sit idle a few months down the road.
Upgrading can be costly and traumatic, but sooner or later it's inevitable. Proper planning, with scalability in mind, can make the difference between a smooth deployment of nifty new technologies and an upgrade disaster.
Previous
Did you find this article useful?
89 out of 194 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
