Should You Upgrade?
Short answer to this question is as soon as possible. Long answer takes a little explanation.
I realize that whenever the dreaded ‘As soon as possible’ answer is given; everyone looks for an excuse to not perform the upgrade. The reasons are plentiful but they usually revolve around one common reason: “We don’t need to upgrade now because what we have is working.”
Behind that reasoning, of course, is a little fear. What if an upgrade doesn’t work out? What if there is a hidden incompatibility that doesn’t pop up until it’s too late? Upgrades can fail for a number of reasons, but that’s not a good reason to not upgrade.
Here’s something to keep in mind. When I say that you should upgrade ‘as soon as possible’, I don’t mean to shut down what you have and upgrade today. What I mean is that you should start planning on your upgrade as soon as you hear a newer version of your server software is released. Start having those conversations (how to upgrade a multiple machine farm, which ones to upgrade first, who does the upgrade, do you have servers that don’t need an upgrade because of a redundancy, etc.) now to determine how you are going to upgrade. A server upgrade in a perfect world would be all sunshine and rainbows and all files transferred will work perfectly and you would have no issues at all.
I know the first question will be, “Don’t newer server versions have built in backwards-compatibility for support of older software?” Yes, they do, but you cannot count on that.
I was recently brought into a project where the client upgraded their production servers to Windows Server 2012 R2 from Windows Server 2003*. On this server was a critical application and they wanted to know if the application would still run on the new server. I relayed to them that the application should run fine.
*This means that when they decided to upgrade their main production server, the OS on the machine was 12 years old! Here’s some fun reference. Google was 5 years old; Arnold Schwarzenegger was elected Governor of California about 6 months after its release, and Facebook had not been created yet.
After upgrading, an issue arose. The application failed when trying to perform a core function. After digging into the source code of the application, I noticed that the application was using a deprecated module that was being used to import data from an excel file. Since this can be a security risk, the functionality was completely removed from Windows Server 2012. In Windows Server 2008, the functionality was removed but there were still workarounds in order to allow the module to run successfully. This would have served as a warning for the system administrator that there is something that needs to be updated in order to run as designed.
In an ideal upgrade scenario, their server would have been upgraded to 2008 and this deprecated module would have been noticed so that the application could have been re-written to not use that module anymore. It could have been budgeted and planned out at that time to be done so as to alleviate pain.
As it were, their server was upgraded because it had to be. They needed to upgrade it ASAP and then hope everything works out well. It did not. They upgraded and then spent more money making their legacy software work with a new server. If they had upgraded to 2008 when it was fairly new and then to 2012 they would have received notice that they needed to upgrade some software on their server
and planned for this. As it stands, they spent much longer than needed on having the software re-written and then more time still testing to make sure that everything worked correctly. A simple server upgrade turned into a nightmare, a nightmare of their own creation.
There will always be some bumps that come up when upgrading a server. You need to minimize those bumps and the best way to do that is to start planning an upgrade as soon as possible. As soon as you hear about an upgrade, contact someone who knows about it and start having that conversation so that you can spend a little money now to prevent spending a lot of money later.