What You Should Consider When Upgrading to SQL Server 2014

Support for SQL Server 2005 comes to an end April 12 2016. Organizations should now start planning to upgrade their databases to SQL Server 2014. While it is SQL 2005 that is retiring, the reality is, there are still SQL Server 2000 databases that are still operational even though they have not been supported by Microsoft since 2013. In fact, I am currently working on a SQL Server 2000 instance migration to SQL Server 2014 for a customer. What many organizations don't realize is the operational costs in running dated database software. Worse still is the perception that money is saved by not investing in migrating to SQL 2014 or higher.

Imagine driving a late model vehicle as a daily driver. With all the wear and tear through use, imaging the costs accrued on maintenance and repair. Add the availability (or unavailability) of parts for an old car. Take into consideration the time it takes to take your car to the mechanic, waiting for your vehicle to be fixed, the hassle of getting a rental car if you really need to drive to and from work. What about changes or additions to the laws over the years? Newer cars do not require regular emissions testing compared to their older counterparts. With that said, most of us are dependant on our cars as it contributes to how we make a living. Same could be said for the mission critical databases organizations rely on everyday.

Attempting to Support An Unsupported Database Platform

Five years ago, a support ticket was issued on behalf of a customer still running on SQL Server version 6.5. At that time, SQL 6.5 was on its fourteenth year and Microsoft support was way past expiry. The organization was literally on their own should something had happened. The database originally ran on a Windows 2000 Advanced Server on a very old hardware which one day failed. When the customer couldn’t find the hardware drivers and firmware for the new server to run Windows 2000 Advanced Server, they decided to move off the physical server to a virtual machine.

The physical-to-virtual migration was painful. The server OS was upgraded to Windows Server 2003 but kept SQL Server to version 6.5 intact. Their largest database had grown to about 300 GB at that point. Back then a 300 GB-sized database was relatively large for SQL Server 6.5  to support as it wasn’t designed to handle that much data. At that time the maximum amount of memory a server could have was around 8 GB which was the maximum amount of memory Windows 2000 Advanced Server supports.

After the migration, the databases continuously became corrupted. Support tickets to address the database corruption were issued weekly. The even bigger challenge was our team of highly skilled SQL Server experts no longer worked with SQL Server 6.5 and so time was spent re-learning the product just to support it. I even had to install SQL Server 6.5 on my test lab just to get myself re-oriented with the management tools. Managing and supporting that database even affected the team morale because we were getting frustrated with all the issues that we need to fix instead of focusing on more important things that would benefit the business goals.

Here is a great video from a recent Ignite conference in New Zealand that tells of a similar tale:

Spending a large amount of money and resources to support an outdated technology asset is probably not a good idea when you consider what’s really important to the business. Here are some point to consider to help you make that choice to upgrade to supported database software:

  1. Vendor support - Companies like Microsoft define support into two offerings. Namely, mainstream support and extended support. Mainstream support enables organizations to receive enhancements for a specific product thru service packs and cumulative updates. Under extended support, no additional enhancements will be provided and all support-related cases will fall under the paid options. After exhausting the availability of extended support, you are technically on your own and your vendor may not even assist with any support case that you will open with them. Of course, just because your vendor supports your particular platform doesn’t guarantee that your internal team can.
     
  2. Availability of skilled resources -  Would you still keep a mission-critical database platform if nobody knew how to support it? Sure, you can possibly outsource that to a managed services provider but can you guarantee that they have the technical skills to keep the lights on? A newer version of a product will be much more common in the field that there will be more skilled talents and resources available to maintain it.
     
  3. Compliance requirements -  HIPAA and PCI compliance both require the database and operating system platforms to be updated with the latest security patches. It also means that you need to comply with the laws and regulations that apply in the country or region in which your business operates and/or data is held. Does your existing technology platform meet these compliance requirements or do you need to upgrade to a newer version to be compliant?

This is the reality that customers face when dealing with an older version of the product.