The Slow Upgrade of SQL Server Versions

  • Comments posted to this topic are about the item The Slow Upgrade of SQL Server Versions

  • I worked on an application using an old 2008 instance the other day and got hit by an unfortunate surprise. Apparently ef.core 2.x is the last version that can do the standard pattern for query paging on that version of sql server.

    This likely has an impact on a lot of places that are modernizing their application infrastructure(but might otherwise be satisfied with the feature-set on the database) and moving it towards .net5 and beyond.

  • Thanks for the mention! Yeah, I totally agree about virtualization being a huge enabler here. Once we stopped being reliant on a specific physical box being up, these zombie 2005/2008 boxes can soldier on forever.

  • This was removed by the editor as SPAM

  • Some people are running package software that is just as old and cannot run on the newer versions of SQL Server.

    I work with Microsoft's Dynamic NAV (new versions are called Business Central), and it has a long tail of customers who do not want to spend the money to upgrade.

    Other ERP products have the same problem.

  • Mostly 2 years after a major release. Luckily we are in control of most programs and the ERP was greenfield. Azure is causing an increase of upgrade tempo

    The older version stem from discontinued products or products in transition that needs to be kept running for x years.

  • All my experience is in this scenario (including downgrading code from 2014 to 2008.)

    So I am interested in the effect of going 'cloud'-based. The upgrades are a well-advertised feature of this but does going 'cloud'-based remove all obstacles that are the reasons behind so many legacy SQL installs still being use?

  • nicksamuel wrote:

    All my experience is in this scenario (including downgrading code from 2014 to 2008.)

    So I am interested in the effect of going 'cloud'-based. The upgrades are a well-advertised feature of this but does going 'cloud'-based remove all obstacles that are the reasons behind so many legacy SQL installs still being use?

    This is rather general. Of what "obstacles" are you thinking?

    The cloud for SQL Server could be different things (IaaS v PaaS), but there isn't a single comprehensive list of problems or advantages I know of. Much advice or experience is based on specific things that are problematic. You might solve a few of your issues with an upgrade or move to the cloud and be fine. Or you might cause other, unexpected issues.

     

  • I guess I would be interested in knowing HOW the numbers of which versions running SQL Server were determined.  Is it a survey, some type of inventory data upload to Microsoft? How complete is the list to reality of what exists in the real world?  I know in my years of being a DBA it was amazing to see how many older versions were running.  A LONG time ago the issue would be that a software install would install MSDE or SQL Express behind the scenes to store some metadata and no one actually knew it was installed and there until a network sniffer found them.

  • Summer90 wrote:

    I guess I would be interested in knowing HOW the numbers of which versions running SQL Server were determined.

    Not enough to actually click on the links in Steve's post and read though, eh? I see.

  • Brent publishes this report from his clients. These are real world clients that subscribe to his service, so the counts are based on that.

    A self-selective group of people outsourcing some admin stuff, but I wouldn't expect this to be way different than clients in general as a group. In any particular place I've worked, it could be much different, but I've been in places that were always under support and in some that were mostly out of support with old versions.

  • Brent Ozar wrote:

    Summer90 wrote:

    I guess I would be interested in knowing HOW the numbers of which versions running SQL Server were determined.

    Not enough to actually click on the links in Steve's post and read though, eh? I see.

    Heh... it reminds me of the instructions in the upper left corner of the screen.

    rofl

    --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)

  • Jeff Moden wrote:

    Heh... it reminds me of the instructions in the upper left corner of the screen.

    HAHAHA, you got it. Nicely done, sir.

  • On-prem SQL Server instances in large organizations are typically treated by accounting as a capital expenditure (CapEx), so there is a financial motivation to hang onto it for 10 years (or more). I mean, the longer they go without upgrading the license, then the better it looks on their financial statements from a ROI perspective. However, those of us in IT know there are both financial and opportunity costs involved in not upgrading (extended support, missing out on new features, less scalability, the best DBA talent moving on to other things, etc.).

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Viewing 14 posts - 1 through 13 (of 13 total)

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