When should we upgrade?

During our first blog we covered the software upgrade.  This installment of the three-part series will focus on hardware upgrades and tie those back to software and the software-hardware symbiosis.

Part II — The Hardware Upgrade

Hardware upgrades are often the most physically demanding of all the upgrades.  Consider chassis switch replacements, or blade center replacements.  While these are not always the most common, they are highly labor intensive.  Add to this the internal memory upgrades that require unracking the gear, and dissection!  So let’s talk about the reasons we would upgrade hardware.  Depending on your job role, you could come up with dozens of them, but we are going to focus on just a few in today’s blog.

First, in every day in the life of a system admin there comes a time of, “Oh, I wish I could do that with what I have.”  And that is the first reason for upgrading:  increased capabilities.  Often, this means a faster router, a special feature only supported on new hardware, or just the ability to handle more interfaces.  In a future article we will cover a new feature called TRILL for switches.  Most system admins view new hardware replacements as opportunities to improve upon the status quo, however caution should be the word of the day.  We often see new hardware installs met with too many changes too quickly and this creates lots of opportunities for challenging situations.

Beyond the new-feature needs comes the end-of-support forced upgrade.  Many organizations have policies that require items to be covered by a warranty or a level of manufacturer support.  In these organizations, a forced hardware upgrade is just a scheduled event based on vendor end-of-support timelines. (Remember that we will cover Cisco’s End of Sale Notice in the third and final part of the series.) Forced upgrades often bring with them many daunting challenges.  New hardware means new software and new software means interdependencies on software versions. An example of this is Cisco’s Unified Communications software.  The Cisco Emergency Responder supports certain versions of hardware and software for switches, and The Unified Contact Center Express has an intense document for the call control element versions (Communications Manager and Communications Manager Express).  Upgrading a Cisco Voice installation where the servers have to be replaced can be a daunting task with the intricacies of the hardware supporting X version and the software dependencies added to that. Consider the PRE-VMWare installs of voice where a Cisco 7825-I2 only supports Communications Manager up to version 7.1 and the new server only supports version 8.0 and higher. An upgrade that involves Contact Center may require upgrading that server and software along with replacing the server.

So far we have covered a new feature or capability upgrade and a forced upgrade to maintain support. The third most common upgrade is the failed hardware upgrade.  This upgrade can be tricky.  In the event the failed hardware is still supported and under warranty, you get an easy way out.  However, for those organizations that do not follow the replace before end-of-support model, this upgrade can really be painful.  Often when a failed device upgrade is forced upon us, we have to quickly learn new software, hardware and even interdependencies while being thrust into a nearly impossible repair window.  Going back to the Cisco Voice Solution – if your Contact Center server were to fail and the new server does not support the version you were running this could be daunting.  Another challenge is the Cisco Authentication Control Server Appliance.  The latest iterations do not support Lightweight Extensible Authentication Protocol (LEAP).  In this realm, if LEAP is still used by your organization you may have to rebuild your entire wireless architecture should a forced upgrade occur.

As you look around your network, a constant eye should be kept on aging hardware, software, and specific configurations.  These elements can create a failed-device replacement nightmare with more labor effort than can be imagined on the surface.  Keeping management informed on a scheduled basis can help prevent an impending disaster!

There are a few silver bullets out there:

For hardware appliances that run software applications – begin looking at a migration away from physical servers, check out VMWare.

For hardware elements, make sure you are on the distribution lists from the manufacturers so that you are kept informed about hardware End of Sale Information.

Engage your consulting partners; ask for a review of your network to determine what is and is not supported by the vendor.

And lastly, once you get those end-of-support notices, build a plan for upgrades.  It may take more than a month to get everything checked and ready, but a month of research is far less stressful than 2 hours of a system down due to failed and unsupportable systems!

In summary, hardware is often a challenging and costly upgrade for most organizations with software, hardware and configuration interdependencies. These interdependencies should be the catalyst to plan ahead.  Often the last-minute replacement is a lot longer than a minute!