Rick Heiges

News about SQL Server and the SQL Server Community

Risky Business

Whenever I do a webcast or presentation, I always ask the audience to indicate where their organization is in relation to running SQL Server 2000 or running SQL 2005. Recently, in an audience of about 40 people, more than half of the audience still had more than 50% of their production servers running SQL Server 2000. One of the main bottlenecks are the vendors of third-party apps. This has forced businesses to choose their risk.

SQL Server Support Risk - The application will not run/be supported on SQL 2005 by the vendor. The decision has been made to keep the aaplication running and "hope" that there is no need for support from MSFT

Application Support Risk - The DB is upgraded by the customer (perhaps keeping the DB in '80' compatibility mode). The decision has been made to keep the data platform updated and under support from MSFT point of view while taking a chance of not getting support from the third-party vendor.

There are many factors that go into this type of decision. In fact, some organizations may choose to assume different types of risk for different applications/DBs. This is not a comfortable choice for any organization. Why don't vendors upgrade their DBs/Apps? SQL Server 2000 is a solid DB platform; 2005 is better. As time goes on, their will be more pressure for customers to avoid the SQL Server Support Risk (and associated costs). Customers will pressure the vendors to upgrade their DBs/Apps or lose a customer.

This now puts the risk on the vendors for not "keeping up". There is some advice for vendors who have not kept up.... Plan to Upgrade your DB/App to SQL 2005 now. While you are "under the hood", run the Upgrade Advisor for SQL Server 2008 and take care of that at the same time. This way, the application/DB will be ready when SQL Server 2008 is released and even more importantly when it becomes a standard/approved data platform for many organizations. Sticking with SQl Server 2000 may not have cost you business over the past couple of years, but it will cost you as the April 8, 2008 date gets smaller in the rearview mirror.

Published Tuesday, June 24, 2008 10:47 AM by RickHeiges

Filed under: SQL 2008, SQL 2005, SQL 2000, Upgrade

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

	James Luetkehoelter said: I gotta admit - I disagree Rick. Even with SQL 2000 out of mainstream support, many will stay on it for quite awhile, and with good reason. Have they ever called support? I haven't run in to many people that have - they muddle through whatever issue they get into. 3rd party vendors choosing a database platform often have a difficult release cycle and often don't even want to explore the benefits of a new version of SQL, much less keep up with the most current version. SQL 2000 is a strong product. Is 2005 a stronger one - you bet. Will 2008 be even stronger - probably. But if a company has made an investment, they want it to last as long as possible. If you know what you're doing with SQL 2000, it won't break. Most purchasing individuals go by the thought "If it ain't broke don't fix it". That's why we have so many legacy apps out there, and such a strong install base of SQL 2000. It's a reality. Personally I'd love to see everyone be more aggressive with upgrading, but I just don't see it happening, nor do I see a strong argument to do so. June 24, 2008 1:10 PM
	AaronBertrand said: I kind of agree with James here. The majority of customers I have dealt with do not encounter the kinds of problems that involve/require support resolution. In fact I have had more 2005 issues escalated to support in 3 years, than 2000 issues in 8 years. Add to that, most of the clients I have are quite stingy and follow the same "ain't broke" mentality. If what they have is working well enough, then the cost of buying new licenses for the latest version is very unlikely to pay for itself, if most of the benefits cannot be absolutely quantified. As an example, take backup compression in SQL Server 2008. If you aren't using some kind of backup compression already (LiteSpeed, RedGate, etc.) then you must already have adequate disk resources to handle your backup needs without compression. (And if you're right on the cusp and your data is growing, I think that is a fringe case and you shouldn't be cutting it so close.) So, let's say you would potentially reduce your backup storage requirements from 1TB to 800GB. Unless you really, really, really need to re-use that 200GB immediately, and expanding your storage is a drawn-out affair, adding disk is a much cheaper short-term solution than upgrading your SQL Server instance(s). What Microsoft tries to do is pack a LOT of compelling features into each new version, so that the bean-counters cannot isolate a feature like backup compression and judge its utility in a vacuum. But it is still an uphill battle in most shops. Even after an absolute cost-benefit analysis might show that the upgrade is worth it, there are still a lot of unknowns when thinks like app and backward compatibility come into the picture... June 24, 2008 1:24 PM
	RickHeiges said: But there is still the draw of new customers... If a vendor has a product based on SQL Server 2000, there has to be some compelling reasons to purchase the application that is based on a DB Platform that is now officially out of support. Would you purchase an application that requires SQL Server 6.5? Vendors must also decide how far back to support their application and DB platform. If they jump at every new version/service pack/etc, the complexity of support increases. I understand this. Skipping SQL 2005 may be a wise decision for some vendors. Many organizations are opting to take the SQL Server Support Risk currently rather than force other changes. When I talk with customers about their third-party apps, they appear frustrated and often ask how they can make their vendor upgrade to 2005. Yes, some customers are stingy, but others know that upgrading will make life easier and reduce TCO in many cases. Many organizations have policies against using software that is no longer under support. SQL Server 2000 is primarily a 32-bit application. With the advancement of 64-bit systems, you really need to move up to 2005/2008 to take advantage fo the memory capacity afforded for the vast majority of the SQL environment. Don't get me wrong, SQL 2000 is a strong DB platform. If it wasn't we'd see a bigger exodus to 2005/2008. I believe that we are at a tipping point where 64-bit will be the norm for DB servers. This means that while SQL 2000 can still function on x64 OS, it still has 32-bit limitations. I believe that we will dramatically see less SQL 2000 in 12-18 months after 2008 RTM - say around only 30% of the installed base instead of the estimated 60% currently. June 24, 2008 4:13 PM
	James Luetkehoelter said: If it is a NEW vendor product, I totally agree with you Rick - and that is a compelling thing to consider when purchasing it. You're right, I'd never recommend someone puchasing a 3rd party product with SQL 6.5 with the engine (or 4.2 - I still know someone running it!). But if they are upgrading the database version with incremental improvements to their product ("." releases), they can't afford to do the backwards compatability testing necessary. I've worked with many of these companies, I understand their dilemma. I've got one client that works with an application running an Oracle back-end (yes, I do Oracle work too - you can all throw fruit at me later) that is doing the constant updating of the database platform with relatively incremental updates of their product. The result is actually extremely painful for the end-client - upgrading Oracle is non-trivial task and this is for a mission-critical application. I would rather see the 3rd party vendor upgrade database versions only with major releases of their product (actually its a complicated situation based on the industry, but I digress...). So yes, if you were driving at the slowness or reluctance of third-party vendors to upgrade their platforms from the standpoint of supportability and standardization for the customers they serve, I think that is a much more compelling argument. But being "out of support" for SQL 2000 I find to be a very weak argument for upgrading. That smacks a bit of "keeping up with the Jones'" mentality. That was the late 1990s. We know how that ended... June 24, 2008 9:33 PM