This is a reprint from my editorial in Database Weekly. Also, check out the May Question of the Month, as it is also directly related to this topic.

Often when I speak at user groups and conferences, I ask attendees what versions of SQL Server they are running. As you may expect, I hear from attendees who are running the entire gamut of SQL Server versions, from SQL Server 6.5 up to SQL Server 2012. While it is an unscientific poll, it seems that most people are still running SQL Server 2005 and SQL Server 2008.

SQL Server 2012 RTM was announced on March 6 and went into general availability on April 2, but I have talked only to a very small handful of DBAs who are even thinking about upgrading to 2012, let alone having already done so. So why doesn’t everybody immediately upgrade to the latest edition of SQL Server when it is released? Why are there so many older versions of SQL Server in the wild?

Some of the most common reasons I hear include:

• We don’t like being on the cutting edge, preferring only to move to a newer version only once it has been around awhile and proven to be stable. Read: Waiting for Service Pack 1.
• Our vendor applications, or in-house applications, haven’t been certified to run on SQL Server 2012, and this takes a lot of time. Based on my personal experience, vendor applications are extremely slow to keep up to date with the latest SQL Server technology. When I ask vendors why, they generally tell me that they don’t have the in-house resources to do the testing. In other words, they are cheap and don’t want to spend the money.
• If our application is working well on the current version, why go to all the hassle of upgrading when we are happy with what we have. Why stir the pot and cause potential problems?
• The new version doesn’t have any new features that we need, so why bother upgrading?
• Upgrading to a new version almost always means higher licensing costs, and with the economy as it is, we can’t afford to upgrade.
• While we want to upgrade, we don’t have the in-house resources to do so. It takes a huge amount of time to test existing applications (which are often tightly intertwined), and, if there are problems, to fix them; build new servers (as necessary); train staff on how to use new features; perform the actual upgrade; perform post upgrade tasks; monitor performance after upgrading to see if it is better or worse, and make any required adjustments. In other words, the process of upgrading is very time-consuming and costly.

So I have several questions for you. Have you upgraded any of your instances to SQL Server 2012 yet, and if so, how did the upgrade go? If you haven’t upgraded to SQL Server 2012 yet, when do you expect to? And besides what I have listed above, what other reasons or impediments have you run across that prevent you from upgrading to 2012?