The Minimum Upgrade Point

These days the pace of change with SQL Server can be intimidating. Many of us work in disparate environments with multiple versions of the platform in our environment. In the distant past I’ve had people note that they often have 2 or 3 versions to support. In the last five or six years, when I’ve asked it seems that many people have 5 or 6 versions to support. That can be challenging in trying to manage your estate as a single entity and understand which scripts will run on which machines.

Recently someone noted on twitter that they tried to convince their company to upgrade to SQL Server 2017, but apparently someone at the company wanted to stick with SQL Server 2014. I asked a question and the person responded that since Dev and QA was at the 2014 compat level, they wanted prod there.

Pedro Lopes, from Microsoft, asked a good question: “How can I help you avert this?” I tend to agree, in that moving to 2014 now, which will fall out of mainstream support in July 2019, is silly. You’re installing a system that will be unsupported almost from the beginning. While you will get security patches for a few years, it seems short sighted to start using a version that you may want to use for 10 years.

That got me thinking. What is the minimum upgrade point for your organization? Not the pace or the need, but if you had to pick some random instance to upgrade, where would you go? SQL Server 2017? Something sooner? Perhaps you have some requirements in your organization that limit you from moving to a very new version. I would argue that it’s important dev/test are similar to prod, but I’d also say that dev and test ought to upgrade to a recent version as well.

I think I’d specify SQL Server 2016 SP1 as the minimum point. This changed the feature list in Standard Edition, which is what I’ve often run for systems. We run that now for SQLServerCentral, though our decision last year was a move to 2017. We probably won’t upgrade again for many years, but if we did, I think I’d be looking to get close to the most recent version.

What would you do?

Steve Jones
Listen to the podcast at Libsyn.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

3 Responses to The Minimum Upgrade Point

  1. The problem is Microsoft had a history in the past of breaking changes, and thus, for many FUD became rule of law.

    I think that Microsoft should consider getting rid of the software assurance model altogether and provide some specific monetary penalties it will be responsible for paying customers in the event it releases a version SQL Server with an undocumented, unintended breaking change. Also, it should provide an automatic version migration process as part of the installer so that an on-premise SQL Server subscriber can get seamless, minimal downtime migration to the latest version as part of their standard deployments.

    Until these things happen, SQL Server will continue to have clients using versions well beyond any support life.


  2. way0utwest says:

    I agree with you, but you haven’t really considered the question. Assuming you’ve decided to upgrade, to which version do you upgrade?


  3. Dan White says:

    We’ve locked into 2016 (sp2 track) as our “core”. Management made the decision to move there from 2018 against my objection to move to whatever the latest release is. My company tends to stay on a version for a while.


Comments are closed.