The Great SQL Server Migration Question
The current SQL Server release schedule seems to be more than customers can keep up with—more time is needed between versions, but not too much.
January 12, 2011
![bird migrating bird migrating](https://eu-images.contentstack.com/v3/assets/blt07f68461ccd75245/blt771abed4b1785128/66194b93bb62cec0fcb9c948/migration595x335_0_5.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
At PASS Summit 2010 in Seattle, Microsoft announced the next release of SQL Server (code-named “Denali”). Coming quickly on the heels of the SQL Server 2008 R2 release, it seems to me that businesses aren’t ready for yet another release of SQL Server. To its credit, Microsoft is pushing out the releases in a predictable fashion on a four-year/two-year cycle in which every four years the company produces a major release and at the two-year mid-point it comes out with a minor or R2 release. However, from what I’ve seen, businesses just aren’t able to adopt these releases as quickly as Microsoft is pumping them out. Most businesses that I work with are still running SQL Server 2005, and they’re just now thinking about moving to SQL Server 2008. They’re far from ready to move to Denali.
More Time Between Releases—But Not Too Much
Quite frankly, although I like to see new releases of SQL Server, and in the media business new releases are always a good thing, I would rather see Microsoft hold off on the next release of SQL Server—giving businesses more time to absorb and roll out the current SQL Server release. This would also give Microsoft more time to produce a substantial release that packs more value into the upgrade process. Including more features in the next upgrade gives customers a greater reason to adopt and roll out the next release. Increasing the time between releases gives customers more time to roll the releases out into their infrastructure.
I think the major/minor release cycle makes more sense for certain types of products than it does for others. Microsoft implemented the major/minor release cycle in an attempt to eliminate the long wait time between releases. For instance, the wait between SQL Server 2000 and SQL Server 2005 was nearly five years, which didn’t sit well with some Software Assurance customers whose contracts expired before they could upgrade to the new release. Extra-long release cycles also tend to give the competition a temporary advantage by providing them with more time to sell the features in their own products. However, coming out with a release every two years appears to be too much for customers to consume, and it’s not motivated by real customer demand. Most companies aren’t clamoring for a new release of SQL Server—they’re still trying to figure out how and if they should implement self-service business intelligence, which was part of SQL Server 2008 R2. It seems to me that core infrastructure products such as SQL Server should be on a more infrequent upgrade cycle. Businesses don’t like to tinker around with their infrastructure products, and they won’t really do so unless there’s a truly compelling reason. No matter how good a new release is, rolling out a new release requires a lot of planning and effort, and there’s always some degree of risk that the new release will change or break something that’s currently working.
Perhaps an intermediate schedule, such as a major release every three to four years with no R2 release, might be a better fit for most customers. However, considering that all Microsoft server products are following this hectic major-minor release schedule, I wouldn’t expect to see any changes until the customer base eventually becomes hopelessly splintered.
Deciding When to Upgrade
So when Denali is released to manufacturing, businesses will once again face the great migration question: Do I really need to upgrade my SQL Server installation, and if so, which release of SQL Server should I upgrade to? Denali offers significant improvement in the area of availability with its AlwaysOn initiative. It also seems to offer some good development and performance enhancements in the form of the Juneau development environment and the columnar-based index feature. Even so, you have to wonder if these features are really enough to make customers take on the pain of upgrading to a new release. Assuming this major/minor release cycle remains in place, one thing that Microsoft needs to be sure of is that there’s a straightforward upgrade path from older versions of SQL Server to newer versions—and this support needs to stretch back for several releases.
What Are Your Plans?
So which version of SQL Server has your company standardized on? Are you looking forward to the Denali release or are you secretly dreading it? Let us know where you’re at with the great migration debate—drop us a line at [email protected] or [email protected].
About the Author
You May Also Like