Is It Time to Upgrade?

  • Comments posted to this topic are about the item Is It Time to Upgrade?

  • To be honest, with what happened with 2005 when it first came out and to 2012 over it's life until Sp2-Cu5 and what recently happened with 2014 Sp1, I couldn't blame anyone for sitting on their hands for another year. Migrations to new servers are always a huge pain and inplace migrations are a form of suicide.

    Remember that the really neat thing about a product finally going out of support is that they've stopped changing it. Ironically, that's when it finally becomes a "stable" product with no more surprises or retro-accidents. 😉

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I am so glad that I don't get involved in such decisions. I like to know the "right answer" and this one is such a grey area - just look at the number of times this gets debated (with no-one decision being a "winner").

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • As someone who attended launch events for SQL 2005 I can only say that ten years is too short a life for a product from a business perspective. It takes years to get everything migrated to the new version and get it stable and attempt to standardise by which time the next latest and greatest thing is being promoted and there is no time for a period of stability and to focus on other things and more IT expenditure has to be justified.

    If it ain't broke don't fix it tends to be the business view as database upgrades have no obvious benefits to the end users and we are still stuck with systems that the suppliers won't upgrade from 2005.

  • Jeff Moden (4/29/2015)


    To be honest, with what happened with 2005 when it first came out and to 2012 over it's life until Sp2-Cu5 and what recently happened with 2014 Sp1, I couldn't blame anyone for sitting on their hands for another year. Migrations to new servers are always a huge pain and inplace migrations are a form of suicide.

    Remember that the really neat thing about a product finally going out of support is that they've stopped changing it. Ironically, that's when it finally becomes a "stable" product with no more surprises or retro-accidents. 😉

    Quite.

    I think all the 2000 instances are now finally gone, and we are building new stuff for 2014, but sitting behind the curve seems a decent position. I have a rough plan to move remaining 2005 systems, probably to 2012, but will not be dashing.

  • Chances are that if you've been secure this long, you'll still be secure for a few more years.

    Hmm. As John C. Dvorak might once have said, can you spell "complacency"?

  • In the comments of the SQL Server Blog article someone mentioned the cost issue, to which the team quickly responded by pointing to a study by Forrester Consulting (commissioned by Microsoft) claiming that the costs would be recouped in less than a year.

    The study itself tosses around terms like "risk-adjusted ROI", "net present value" "productivity increases" and so forth.

    At which point my BS detector started screaming like a banshee. If someone can't explain how I'll recoup my investment in two sentences or less without using a single accounting term, then what you're really saying is "Yeah, we know it's expensive and we really don't care."

    ____________
    Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.

  • An interesting point on this; PCI PADSS (credit card industry rules) require that the system be under support. So if your 2005 database holds credit card information, even if it is temporary and highly encrypted, you will still have to upgrade to 2008 or higher by 2016/04/12 or be out of compliance and incur the associated penalties.

  • Great timing for this article. I'm planning the installation of a new server and it'll be 2012, not 2014. As much as I'd like to move to 2014, I can't say with confidence that it's mature enough for production yet. I heard that SP1 was taking down servers, which is pretty sad.

    The botched SP release is nothing new. My 2005 server is at SP3. When I tested the installation of 2005 SP4 on a test server, it broke SQL Server - part was at SP3 and part at SP4. After digging through logs and researching the problem, the solution from MS was to uninstall SQL Server and then reinstall it and patch it up to SP3. In my book, that's not a solution and it's certainly nothing I'd install in production. Going back further, we can look at the debacle with SQL 2000 SP3 and 3a.

    These events (2000 SP3, 2005 SP4, 2014 SP1) all tell me that I'm comfortable being behind the curve a bit. I'd much rather opt for safety and stability instead of the newest features and coolest functions. Of course, I know the new functions can be used to do things more efficiently, but I place a very high value on stability.

  • When I ask our DBA about upgrading he just asks why. He says it is too expensive unless there is a compelling reason. We are on 2008 R2 and he says it is secure and functioning well. So here we sit.

  • Jeff Moden (4/29/2015)


    Migrations to new servers are always a huge pain and inplace migrations are a form of suicide.

    + 1 million on the in-place migrations being suicide. To me, it just isn't worth the risk. If that means I'm paranoid about stability, so be it.

    Jeff Moden (4/29/2015)


    Remember that the really neat thing about a product finally going out of support is that they've stopped changing it. Ironically, that's when it finally becomes a "stable" product with no more surprises or retro-accidents. 😉

    I learned a new term today - retro-accidents. 😀

  • It has always struck me that Microsoft really needs a brain adjustment. SQL Server is a business tool, yet it seems that they treat it like a consumer product. The old IBM treated business like business with long-term support. Granted, IBM made bucket o' dough with the cost of their hardware and support, but you would get solutions when things went bad. It was kinda like getting your film processed by Kodak: you paid extra for lots of people to run around in white labcoats with clipboards to make sure everything is running correctly. But with MS releasing a new SQL Server every 2-4 years, it increases revenue churn for their product and ancillary lines like certification materials. Is 2014 a better product than 2012? I don't see a lot of difference for fairly standard transactional systems, maybe the benefits are in more esoteric configurations.

    They certainly lost a lot of face with having to recall the 2014 SP1, that's for sure.

    I'm curious: how often does Oracle come out with a new major version, or IBM with DB2?

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • Last Thursday we just retired our last two SQL Server 2000 databases. They were small dbs, one was used by 3 people and the other the app was being retired so we just had to wait it out. It wasn't worth the huge amount of testing hours to upgrade it as it is being sunsetted. I am heavy on prodding application owners, and have been for over a year, on migrating off of SQL 2005. We have upgraded 6 SQL2005 dbs already this year. Its not just because of SQL 2005 ending support but Windows 2003 support ends this Summer. It is easy to say just migrate the databases by some outsider. HOwever, if the application you bought is on a version that doesn't certify SQL2008, 2012, or 2014 you cannot upgrade without putting your company at risk. We have a handful of apps that are in the process of beginning projects to upgrade the app to a SQL2012 RDBMS version. It is a constant battle. We have a TON of stuff in SQL2008 and SQL2008R2... when 2019 and end support comes around for that we are going to be in a world of hurt.

  • P Jones (4/30/2015)


    As someone who attended launch events for SQL 2005 I can only say that ten years is too short a life for a product from a business perspective. It takes years to get everything migrated to the new version and get it stable and attempt to standardise by which time the next latest and greatest thing is being promoted and there is no time for a period of stability and to focus on other things and more IT expenditure has to be justified.

    If it ain't broke don't fix it tends to be the business view as database upgrades have no obvious benefits to the end users and we are still stuck with systems that the suppliers won't upgrade from 2005.

    I once heard a large (Fortune 100) company make a policy that if you install it, it has to run for 10 years. At the time I thought that was long, but I think it's about right. My instinct now would be to say that any server I set up probably needs to run for 8 years at a minimum, especially in a virtual environment, unless some catastrophic failure or flaw forces change. I'd expect that 10-12 years makes more sense for app servers and db servers, definitely for file/print/dns/infrastructure servers.

    However, I don't install all servers at once, so I expect that if MS releases every 2 years, that I'll have 5 versions to run and support. That's OK for me, and it allows me staff to keep growing, but maintain useful knowledge from the past.

    I expect MS to do the same. Support the 2005 server for 10 years and 5 versions receiving patches.

  • Gary Harding (4/30/2015)


    Chances are that if you've been secure this long, you'll still be secure for a few more years.

    Hmm. As John C. Dvorak might once have said, can you spell "complacency"?

    Is it? I guess it could be. Or it could be practicality.

    IMHO, support can be overrated. There are times it is important and needed. I think MS does a fantastic job managing support, and I've been on the receiving end (and grateful), quite a few times. However I have also had hundreds of instances I've managed where I never needed to call support. There's no PII information and they support an application that's useful or even important, but not critical. Why pay a large cost to upgrade them because of a date.

    I wouldn't keep these servers without some plan of how to replace them in an emergency, but I wouldn't spend too long on it, nor would I worry about it too much.

Viewing 15 posts - 1 through 15 (of 21 total)

You must be logged in to reply to this topic. Login to reply