There has been quite a bit of discussion online lately about which version of SQL Server new applications should target. Members of the SQL Server product group were saying they can't see any reason why new applications should use anything less than SQL Server 2016 as a real base line.
I'd love to see any new application using the absolute latest version of SQL Server. Unlike the bad old days where you needed to wait for a service pack before using the product, the best tested version of SQL Server is invariably the one that's just released. (And there aren't service packs any more anyway).
However, I spend a lot of time in software houses and I know only too well why they are still working with older versions. There are two aspects to this:
- Which version that they'll use features from
- Which version they'll support customers using
The first one is easy. They only want to write code once, and so even though they might be using a later version, they'll keep their code to the earliest version that they support ie: even if an ISV (Independent Software Vendor) is supporting SQL Server 2017, they might have a restriction on using any features later than SQL Server 2012 because they want to be able to deploy on any version from 2012 to 2017.
The second one is tough. After they answer the first question, many then get really slack and don't put the effort in to test and support later versions. I understand that testing is costly and the more versions that you support, the worse this gets.
This is the true pain point though, as unless they do that, their customers will be stuck on those old versions. The problem is multiplied when the customer has to support applications from many vendors concurrently.
There is no way to fix this except pushing the application vendors to test later versions. As well as direct customer pressure, I'd love to see Microsoft reaching out about this more.
Greg, note that we actually are working a lot with ISVs to certify later versions of SQL Server. We're also working with ISVs to certify to a specific compatibility level rather than a specific version of SQL Server so that the end customer can just pick the latest major version of SQL and use the compat level at which things have been tested by the ISV. We have been trying (absent for security reasons) to not remove functionality much in SQL anymore to help aid this model and minimize the work on ISVs to certify. If there are specific ISVs where you would like Microsoft to encourage adoption, please reach out to the engineering team or your Microsoft field rep and make sure that you communicate which piece of software could use a nudge to help get it certified to run on the latest SQL versions.
A few comments:
1. Connor the deprecation rule that used to be in place (N+2) caused less confusion. A great example of a feature affected by that today is DBM. It was announced as deprecated in 2012, 2016 has AGs in Standard, and DBM isn't really getting bug fixes. I wish that you would remove some things.
2. The ISV is one part of the problem. The other is the customer. Switching a version (SQL Server, Windows Server, or even Linux) is not always trivial. That can cost them new money potentially, plus do they have builds of those things? Have they been vetted in house? As much as we'd all like to see our customers on later versions of SQL Server and the OS, the reality is that sometimes it's the customer.
3. Sometimes ISVs do have a later version of an applicaion that runs on SQL Server xxxx. But they refuse to pay the money to upgrade the application. Not only is it the cost and time associated with that whole effort, but training of end users, etc.
It's easy to just blame ISVs, and believe me, I see it all the time. The answer is not always that cut and dry in my experience.