Lifecycle Management of SQL Server RRS feed

  • Question

  • I recently took a position as an Operations Manager of a database team focused on SQL Server.  We've got a large SQL presence (couple thousand servers) and I'm looking at setting standards for version usage and providing guidance to the business on planning for upgrades.  We've just kicked off a project begin migration away from SQL 2012.  That's better than starting next year but what are others doing in regards to lifecycle management?  Do you cutoff new installs for a version before mainstream support ends, on the day it ends or sometime during extended support?  When do you drop internal support for SQL versions and/or start your migration/upgrades to newer versions?

    Looking forward to comments!

    • Moved by Tom Phillips Monday, August 3, 2020 12:38 PM Upgrade questions
    Friday, July 31, 2020 2:20 PM

All replies

  • Hi,

    The new version of SQL Server will bring more enhancements and new features..

    SQL Server end of support options

    Best Regards,

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, August 3, 2020 9:37 AM
  • There are a lot of variables when upgrading SQL Server.

    I suggest you look at this:



    I highly suggest you stop creating new SQL Servers in a version out of "mainstream" support. 

    You "should" always upgrade to the most current version. However, this is not always possible due to vendor support.

    Monday, August 3, 2020 12:38 PM
  • @Tom, Thanks for moving it to the right category.  

    I agree 100% that we shouldn't be installing anything new that is in out of mainstream support.  Just curious how other large enterprises are doing it today.  Honestly, vendor support is rarely the issue. We're a long way away from upgrading groups as newer versions come out.  It's mostly ineffective line of business development/certification processes but as an internal service provider we haven't helped ourselves much.  My predecessor was generally seen as more of, "I'm going make a point, rather than a difference" type of guy and as a result, we've had to rebuild a lot of trust to be able to speak into these products groups.  We're making headway and as 2012 End of Life conversations continue, we'll be able to engage in more conversations about on-going life-cycle management. 

    Monday, August 3, 2020 2:11 PM
  • I generally recommend upgrading ASAP to the new version.  New versions of SQL Server are highly tested.  Most major problems are found before RTM.

    The upgrade path since SQL 2008R2 has been pretty painless.  There are very few, if any, breaking changes between versions.  It is simply a matter of testing and taking an outage to actually do the upgrade, short or long depending on how you do it.

    As far as "other large enterprises", I know of one who is running versions SQL 2000 through SQL 2016.  One application is very old and does not exist anymore and it only runs on SQL 2000, but they will not decommission it and migrate to a new software tool.

    Mostly, upgrading in large organizations tends to be a political issue, rather than a technical issue.  No one wants to be blamed when there is a problem after upgrading, even a minor problem.  So they just stick there head in the sand and say "it is working now, why risk upgrading".

    Monday, August 3, 2020 4:20 PM