Upgrading Software: A Checklist

Earlier this year, we decided to fix a few things around the house, including some loose bathroom tiles. Upon further investigation, we discovered that the floor underneath was a bit wet, thus explaining why the tiles were loose. Before we knew it, about a third of the tiles were ripped up as we assessed how much of the floor was wet from an apparent leak.

One thing led to another and we had a plumber come by to examine the situation, and then a designer to talk about options for salvaging what we had versus upgrading everything. It took two weeks for us to gather all of the details in order to make the decision that we would renovate the entire bathroom, as opposed to trying to patch a few things here and there.

As I pondered all of these events, it made me realize something: Upgrading software follows the same pattern.

We start with a piece of software that is functional—it gets the job done—even if it has flaws that we all look past. Eventually one of the flaws becomes something worth investigating. Companies will look to upgrade software for many reasons, including a desire to stay current, security concerns or perhaps they want performance improvements.

For whatever the reason, a flaw becomes an issue, and the issue gets raised up until senior management can weigh in on what to do next. Information is gathered and a decision is made by the business to either repair what exists or to go forward with something new.

Planning is essential

Either way, when upgrading software -- or your bathroom -- it pays to have a plan. The reason it took three months for our bathroom to be completed is because we did everything ad-hoc. We had no plan in place, and that meant we would sometimes have to wait for someone to become available to do the work. Had we planned everything out in advance, then the right resources would have been allocated, items shipped and the work done in a much shorter timeframe.

When upgrading software, it’s important to have a plan as well. I’ve seen examples of companies where they head down the same route as we did with our bathroom. They look to fix one or two flaws and end up discovering more flaws, which leads to the need for additional work and resources, and before they knew what had happened, they had an unplanned, but major, upgrade in progress.

Perhaps you’ve been in this same situation. If you haven’t, there’s a good chance you may be at some point in the future. Remember, though, all is not lost, providing you have a process in place to follow. Here are the seven steps I recommend for anyone looking to upgrade any software.

1. Have a rollback plan

I’m a DBA by trade, and that means I know you must always have a rollback plan. No matter where you are in the process, you have to be able to revert back to an earlier state. I’ve lost many hours on upgrade projects where, in the absence of a rollback plan, we kept pushing forward until we got things to work in production.

2. Gather metrics

You need to gather metrics regarding application and database performance prior to the upgrade. Another aspect often overlooked are application and database configuration settings, so make an effort to collect those prior to the upgrade as well. You don’t want to get 95% done and find your stuff failing because of some obscure missing DNA alias.

3. Look for new features

If you are making the effort to upgrade your systems, then take time to understand what new features might be available for you to use. It may be the case that after the upgrade, you want to use a feature that might require additional resources or hardware, so you will want to get those requests made sooner rather than later.

4. Go to the latest version possible

Too many times I have watched companies upgrade software and systems in too small of an increment. I always advocate for systems to be no more than one major version behind the platform they are using. For example, with the June 1 Microsoft SQL Server 2016 release, I would advocate upgrading to SQL Server 2014 at a minimum.

5. Decide the upgrade method

There are typically three options when it comes to software upgrades: You can upgrade in place, upgrade side-by-side or migrate to new servers. Each has its own benefits and drawbacks. I prefer to migrate to a new server as opposed to trying to reuse existing hardware.

6. Review configurations

Once the upgrade is complete, and before you hand the systems over to end users, take the time to review your application and server configurations to make sure they match the previous settings. This is where it pays to have a lot of these checks automated either with scripts or third-party tools.

7. Test workloads

Once end users start testing their applications, it's important for you to capture new performance metrics and compare them to the performance baselines captured prior to the upgrade. You don’t want to hear your end users complaining about the new system being slow without any data to know what is happening.

As it turns out, this list works pretty well for bathroom projects, too. For example, our rollback plan was the use of the second bathroom upstairs. Without that bathroom, I don’t know what we would have done for three months except spend a lot of extra time at Starbucks.