SQL server upgrades are often percieved as problematic, or at least highly challenging. In fact, non-existent studies have demonstrated that the number of days left to the upgrade deadline and the number of tums being consumed by IT managers follow an inverse geometric distribution. Which is to say, upgrades cause a lot of stress. In my experience, however, the whole process can be demystified if viewed as just another change management challenge. Here are my five golden tips for assuring a smooth SQL server upgrade:
- Gotcha Checklist – a list of possible problems such as hardware/OS/drive compatibility, known issues, etc. All of this can be researched in advance, and as they say forewarned is forearmed.
- To Do Checklist – a list of steps that need to be taken from the starting point to past upgrade. Take your time to think about all the pieces of information that you will need to arrange in order to properly assess the upgrade risks and ensure a smoooth transition. Few extra hours spent at this stage will save a lot of grief later on.
- Testing Plan – a list of applications, business functionality etc. to test and certify on the new system. It may seem very obvious, but you’ll be surprised how many businesses can not quantify what it means to have a working system. If you rely on your customers to tell you that something is broken, this may be a good opportunity to figure out what are the different aspects of your system’s functionality. Create test cases around each scenario, etc.
- Rollback Plan – even with the best planning, things can still go wrong. All upgrades need a back out plan. This is probably the most neglected area of the upgrade process. It seems that when it comes to having a rollback plan, we all suffer from at least a mild form of an adolescent invincibility syndrome. After all, we went over all possibilities, right? What could go wrong? Well, if you’ve done more than ten upgrades you know that the best laid plans can go awry. Therefore it is absolutely crucial to have a plan B. If you’re getting pressure to cut some corners and skip this step, just make sure that you make it extremely clear that the database can be left in an inoperable state or data can be lost. Enough said.
- Roll Forward Plan – a list of steps to be taken at the upgrade time. Nothing can be more embarrassing than fumbling at the goal line. When it’s time to actually run the upgrade be sure to have a detailed list of steps so that you have to do as little thinking as possible. Time to think is over, when the downtime window opens you have to be like a robot, precisely completing step after step. Champagne comes later.
So, there you have it. Most if not all SQL upgrade issues can be managed with careful planning. As I like to tell my clients – “it’s not rocket science, but it has to be done with good planning and very carefully”.
