Why should we upgrade off of SQL Server 2000?

Typewriter: But, it still works FINE...

But, it still works FINE…

A good many companies still have servers chugging along on SQL Server 2000 (or even, as some of us noted on Twitter, SQL Server 7.0 and 6.5) . If you’re one of those companies, and you’ve never had a problem with it, why should you upgrade?1, stability: It’s completely out of support. Microsoft won’t release any new patches, and won’t help you if (when) something blows up. New viruses or bugs out there can find and exploit your server.

2, applications: Vendors increasingly don’t release to or support software on SQL Server 2000. Your apps are out of support, too, and your monitoring and alerting options are increasingly limited.

3, maintainability: It’s getting harder and harder to find DBAs with SQL Server 2000 experience. Make no mistake, 2000 is an entirely different animal. When I work with it, I have to take the (billable) time to backward-port all of my day-to-day scripts – scripts that make heavy use of the system views and other improvements they’ve made in the eight years of post-SQL 2000 releases. You’re actually costing yourself quite a lot of money over time if you have contractors and consultants supporting your 2000 instances.

4, migration: It’s getting harder and harder to migrate from SQL 2000 to the newer versions. It’s already a two-step process, and you’re piling up the deprecated features. Eventually it’ll be so difficult, you may have to recreate your entire system and code a data port from the old system, just as if you were getting off of another RDBMS entirely.

These aren’t the only four reasons to upgrade from SQL Server 2000. We’ve barely mentioned the wild array of new features in each successive release. But think about it: you’re going to have to move your data into a robust, supported system eventually. Why wait until something goes really wrong?

Happy days,
Jen McCown
http://www.MidnightDBA.com/Jen

5 thoughts on “Why should we upgrade off of SQL Server 2000?”

  1. Yes.

    And No.

    Many companies have legacy applications that haven’t updated in years. Those applications haven’t been updated to support later versions of SQL Server. It’s a total catch-22. Microsoft won’t support the older version of SQL Server and the application vendor won’t support you on newer versions of SQL Server.

    In other cases, companies will wait until the cost of maintaining the old version is more expensive than the cost of upgrading to a more modern version.

    From a technical perspective, upgrading makes perfect sense. But from a business perspective, maybe not.

  2. Been there, done that!

    But the arguments for updating your applications are the same arguments for upgrading SQL. The app may be vulnerable, isn’t supported, isn’t maintainable in the strictest sense, and is getting harder to migrate off of with every passing moment. I get that it’s difficult to create or procure new solutions to existing legacy apps, but when would you rather do it? Now, next month, or in another 15 years, when NO ONE who understands the thing is within a 200 mile radius?

    For many companies, the answer is “in 15 years, or maybe never ever”. It’s definitely a choice, but I stand by what I say: it’s the wrong choice.

    Good comment man…

  3. Jen,
    It is definitely the wrong choice to put off an upgrade. Especially without support for security patching. In a 2004 study by the Aberdeen Group… they state that the average cost of a data breach to be somewhere in the ballpark of $2 million/incident. 2 MILLION. If business wants a case for coming up with funds for an upgrade that should be it.

    There was an incident at DoD that shut down an entire state off the grid for 4 full days….want to guess what the focal point of the attack was? …. SQL Server 2000 …..whoopsie

    Spend a little now, give yourself a feeling of peace, and get to sleep at night people.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>