Even though SQL Server 2005 was released almost three years ago, many companies, surprisingly, haven't made the upgrade from SQL Server 2000 just yet. Now those companies face another decision -- whether to just skip the upgrade to SQL Server 2005 and go straight to SQL Server 2008. The choice is not a simple one and this article will discuss the things you need to consider.
It doesn't make much sense to upgrade to SQL Server 2005 -- a version of SQL Server that's already one generation behind. Among other things, you decrease the window of support for your server. If you go with SQL Server 2005, you would be starting with a version that's been around for awhile and had most of the potential issues addressed, either in service packs or with hot patches.
On the other hand, with SQL Server 2008 you would get the many great new features. It seems almost foolish not to skip 2005 and perhaps take the slight risk of running into some problems in the uncharted territories.
SQL Server 2008 initially appeared to be an incremental release to SQL Server 2005. However, as time went by, Microsoft added more and more features. Now, if you look at the list of new features, it's almost as long as the list of new features that debuted in 2005. The choice was somewhat easier a few years back when plans to upgrade to SQL Server 2005 were a definite – you only needed to debate when.
Weighing SQL Server costs
Let's face it, no matter how long the list of new and improved features is, upgrading to a new version might still take years to accomplish for many reasons. The first reason is the cost -- when it comes to price, there is no upgrade path for SQL Server. You have to license your server as if you were buying it for the first time or you have to buy a software assurance program. The problem with the assurance program is that you never know when the new version comes out, so you may be waiting year after year before receiving the be...
To continue reading for free, register below or login
To read more you must become a member of SearchSQLServer.com
nefit. Of course, this option is more lucrative when the new version release is right around the corner.
One thing to consider is buying "downgrade rights," meaning you purchase the latest version of SQL Server, but for a limited time you can run the previous version. Downgrade rights are no longer available for SQL Server 2000, but with SQL Server 2008, you should be able to use downgrade rights to install the 2005 version in the interim, and then upgrade to 2008 sometime in the near future.
Traditionally, a lot of managers do not consider going live with a new software version from Microsoft until at least Service Pack 1 is released. But, this philosophy can backfire. We have seen cases in which a service pack release introduced more issues and bugs than the RTM version.
No one-size-fits-all answer
So, should you upgrade to SQL Server 2005 or SQL Server 2008? As is often the case -- it depends. Consider upgrading to SQL Server 2005 if your requirements meet a few of these criteria:
- Your timeframe for migration is fairly short.
- You use third-party applications that depend on vendor support and the vendor will not likely support 2008 anytime soon.
- You want to rely on a stable and mature product.
- You are willing to forego the new 2008 features for awhile.
Consider directly upgrading to SQL Server 2008 if several of these apply:
- You expect your testing and QA process to last several months.
- The new features in SQL Server 2008 will greatly benefit your organization and offset any potential issues resulting from having a less mature version
- You have DBAs and developers who enjoy cutting-edge stuff and are capable of working with features that have not had much coverage in books, blogs and other available resources.
- You want to avoid double licensing costs.
- Your database and applications are relatively small.
- Your number of users is not very high.
- You have a mission-critical, 24x7 operation relying on SQL Server.
Whatever version you decide to go with in the end, make sure you allow plenty of time for sufficient testing because you never know what surprises lay in store. For example, a few years ago when we were upgrading to SQL Server 2000, I had a query in one of the applications that ran for one second in SQL Server 7.0, but it ran for thirty seconds after we updated the database to SQL Server 2000 -- and the new machine had superior hardware.
The reason for the slowness? While the query optimizer in SQL Server 2000 was greatly improved and enhanced compared to the previous version, there was a bug introduced that caused the optimizer to think the query was too expensive -- so it spent about 99% of the execution time trying to come up with the best plan possible. There is always some risk with each new version, and there is no substitute for thorough testing.
ABOUT THE AUTHOR:
[IMAGE]Roman Rehak is a senior database architect at MyWebLink.com in Colchester, Vt. He specializes in SQL Server development, database performance tuning, ADO.NET and writing database tools. He regularly contributes SQL Server articles to Visual Studio Magazine, SQL Server Magazine and other technical publications and presents at user groups and conferences in the U.S. and Canada. He is an active member and volunteer for the Professional Association for SQL Server. Roman also serves as Tech Chair for the SQL Server track at the annual DevTeach conferences in Canada and is president of the Vermont SQL Server User Group.
MEMBER FEEDBACK TO THIS TIP
Do you have a comment on this tip? Let us know.
