I have been talking to a few clients in the last couple of months about their upgrade cycles. The topic of upgrading can be pretty ugly in some companies.
Pros for Upgrading:
- New versions usually (and I know it isn’t always) fix major problems with the previous version.
- New versions usually include new features that have been requested by customers.
- New versions usually are built to integrate with other products in the environment.
- New versions usually are engineered to be more intuitive and to be easier to use that earlier versions.
- Keeping current provides motivation for IT staff to keep their skills and knowledge current. You can’t attract top talent when you have old technology in place.
- Excessive costs of maintenance contracts once warranties expire.
Cons for Upgrading:
- It is expensive to buy new licensing.
- It is expensive to buy new hardware.
- It is expensive to train the IT staff as well as the end users.
Risk Issues should be a major concern for most organizations. I have often talked to my clients about deploying older technology and the risks associated with deploying older technologies as well as the risk associated with keeping older technology around past its end of life. Those risks include the loss of official support as well as the loss of quality support. I use the example of Product X that has been upgraded to Product Y. The vendor that has produced Product X and Product Y has support staff for their products. The good support staff generally move on to the new product as they are motivated to continue their personal growth and to make themselves more valuable for the company as well as the industry. Yes, many people are left behind to support the legacy product, but we need to face the fact that they are not the cream of the crop, and I really don’t want these “lesser” support people being the lifeline for my company.
I remember a former client (former because they are out of business) and use them as an example of what can happen. They built several e-commerce sites using a Windows NT 4.0 server that ran IIS 3.0. The sites all connected to a SQL 7 database that was running on a Windows NT 4.0 server. I kept telling them over and over again that they needed to upgrade by replacing the hardware and also upgrading to current versions of software. They kept resisting based on the “it has been working forever, and we are happy with it” philosophy. Yes, they had a major failure caused by a virus and since none of the newer antivirus software supported the operating system, they had no way to keep the servers up and running. There is more to the story, but the important part of the story is that they rolled the dice, and they lost.
I have had several discussions in the past couple of years about their new deployments. I have one client that just insisted on deploying Windows Server 2003. Why? Well, they knew the product and hadn’t trained anyone on Windows Server 2008. Finally, I got a sit-down with the CIO last year and asked him if he remembered all of the issues of NT 4.0 support going away and how much trouble they had with some key systems. He grimaced in pain at the memory. I then pointed out that he was setting up his company for a similar situation. I explained to him that doing the simple math would help it make sense. If you deploy Windows Server 2003 in the year 2010, then you are deploying a 7 year old OS. It is a good OS, but let’s do some more math. If you plan on the lifetime of the installation being 5 years (usually the longest you can get a warranty for new hardware), then you will be running 2003 in the year 2015. His eyes got really wide, and then he said he would call a meeting with the IT group to talk about the future that next week. Yes, they skipped Windows Server 2008 and went to Windows Server 2008 R2.
Refresh Planning is vital for most organizations. After all, we know that we can’t keep using the same software and hardware forever. Oh, yeah, some people don’t know that until they end up going out of business because of the failure to plan for the replacement technology.
I highly recommend trying to keep products on a 5 year or less lifecycle and performing refreshes of hardware and software at the same time. I really don’t have an issue with skipping a version, sometimes, but I really have a huge issue with riding technology out so long that there is no longer official support and everyone else has forgotten how it works.
Conclusion: If you are an IT professional, help educate the business groups on all of the issues around product life cycles. They need to understand the issues and concerns, and they need to make sure they budget for the upgrades and migrations.