Today there are five versions of SQL Servers serving at the hearts of business enterprises, and the sixth is coming soon. Current SQL Server versions are 2000, 2005, 2008, 2008R2, 2012 and the upcoming version SQL Server 2014. The question CIOs, VPs of IT and/or IT managers are asking themselves is, “Shall I upgrade SQL Server boxes to the next release, or not?”
The answer is seemingly easy — yes. You need to upgrade to the next version to take advantage of more features, reduced total cost of ownership, more stability, more scalability, less bugs, etc. However, there are major challenges that are obligating IT Managers to count to 10 before thinking of upgrade.
A study conducted by RockSolidSQL suggests that the majority of 60% of installations-base are using SQL Server 2008/2008R2. Around 27% are using SQL Server 2005, 11% are using SQL Server 2000, and a humble percentage of 2% only started to use SQL Server 2012 recently.
While there is an evidence of rapid adoption and migration to the newest SQL Server 2012 within the previous period, especially among new installations and development projects, we still witness kind of adverseness to migrate to newer versions among SQL Server 2000/2005 installations, which amounts to a total of 38% installations when combined according to the earlier source.
The reluctance of upgrading to SQL Server 2008/2008 R2 or later editions, though nine years have passed since the release of SQL Server 2005, and 14 years since the release of SQL Server 2000, might be attributed – in our opinion – to two main reasons:
- A financial aspect: we all remember the financial crisis that has emerged at the end of 2008 and has severely hit most business enterprises on the planet and till today, the US and world economies are not fully recovered yet.
Enterprises had to cut their costs, and Information Technology departments, being looked at in most of the times as cost-centers, had to absorb a major cut into their budgets. Therefore, CIOs and IT Managers did not give much priority to upgrade their existing applications and database management systems, and their top priority went to acquiring new technologies and applications, while at the same time capping or even cutting their operational expenses.
Upgrading applications and services is a lengthy task that requires significant investments. Migration project costs include acquiring new hardware, planning for re-coding deprecated features of prior SQL Server versions, doing unit testing, quality control testing and users testing, etc… This will amount to significant cost and time that CIOs had to give it less priority and eventually skip it for several years in the previous decade.
- A technical aspect: there were significant changes at the core level of SQL Server versions 2005, 2008, and 2008R2 that made many enterprises and application vendors hesitant to upgrade from earlier versions. These changes go beyond deprecated features and direct into core database engine of SQL Server. Thus, enterprises and application vendors had not only to ensure syntax validity, functions and tools expiration, but in many cases they had to rewrite wide portions of their code and even to implement different programming strategies and techniques to make the application compliant with later versions. This is true for migrating SQL Server 2000 to 2005 path, and for migrating of SQL Server 2005 to 2008/2008R2 paths. The core differences between SQL Server 2008 and SQL Server 2008 R2 were not as significant.
While it is pretty easy for a programmer to re-write code to eliminate deprecated features and tools which are well-documented, it is extremely difficult to re-code or tune the application for the unknown changes within SQL Server engine that is black-box for both developers and enterprises and, in many scenarios re-writing the code completely to be compliant with the newer versions might be a favorable alternative rather than tuning performance of the code that is written for a previous versions.
As such, while it is always recommended to upgrade to newer versions of SQL Server, or at least to stay a version or two lagging to the current SQL Server version, other factors should be considered including to have sufficient budget for the upgrading to cover hardware, testing, licensing, application support, and to consider re-coding and testing the applications for not only deprecated features within the newer versions, but also unannounced changes to the SQL Server core, which can be only chased by running the code through extensive cycles of testing for all features, stress testing and other types of tests.
Interested in working with Mouaz? Schedule a tech call.