This week, I’m writing blog posts that can be summed up in one image. Here’s the first one:
You could probably stop reading right there, but if you’re not convinced, allow me to elaborate.
SQL Server 2012 support ends July 12.
No, there’s not a year in that sentence, because it’s this year.
No, there’s no qualification about “mainstream support” because that’s the extended support end date.
Sure, there are extended security updates for a few more years, but those are only security bugs. Within 141 days, your SQL Server 2012 boxes are going to be unsupported, period, full stop, end of sentence. If you call Microsoft for support, they’re going to give you best effort, but at the end of the day, you shouldn’t be surprised if they tell you that the “fix” is to upgrade your SQL Server.
And you know what? I think that’s completely fair. SQL Server 2012 is a decade old at this point.
It wasn’t a bad version!
I don’t want you to think I was disappointed in 2012. To the contrary, I think it was a groundbreaking release, especially looking back at 2008 and 2008R2. My 2008 R2 review noted that it was really just more of the same from 2008, whereas 2012 was really different.
In 2012, I was incredibly excited when Always On AvailabilityGroups (did I capitalize and space that right?) revolutionized high availability and disaster recovery. However, the SQL Server 2012 execution was outright terrible.
2012’s columnstore indexes? No way, Jose: they made the table read-only.
But this stuff represented great down payments on technology that Microsoft has continued to invest in. Today, in 2022, columnstore indexes and AGs are solid features that…
(listens to earpiece)
One moment please…
(continues listening to earpiece)
I’m being informed that Always On Availability Groups are still painful, but at least they’re widespread. (Did I phrase that right?)
Look, stop distracting me. The point is SQL Server 2012 is bad in 2022. If you’re still running 2012 in production today, it’s time to start having the discussion with the business. Here’s how I’d start: “Is it okay if application ___ is running on an unsupported version of SQL Server?”
18 Comments. Leave new
With this on the horizon would it make sense to move these databases off of 2012 and over to newer servers like 2017 or 2019 and run them in compatibility mode until the vendors? Is there any reason not to do that?
Unfortunately, that may not work, as described in the documentation:
https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-compatibility-level?view=sql-server-2017#backwardCompat
Read the “Important” notes in that section.
2014 end of life is just around the corner as well. Luckily we only had a handful of those instances so we’ve been mixing them in with our 2012 upgrades.
We anticipate being done in plenty of time to start upgrading the hundred or so 2016 instances we have.
I look at it this way. Suppose you bought a brand new car in 2012, and paid about the same as many people paid in licensing for SQL 2012. How unimpressed would you be if the manufacturer announced today they would no longer be servicing or making parts for that car? I’d feel pretty let down.
that is exactly what they do. Auto manufacturers are only required to make replacement parts available for 10 years. some really ubiquitous vehicles may get support longer than that, but they aren’t required. The analogy really doesn’t work however.
A better analogy would be a hypothetical car that never breaks down, but over time new features are required to continue driving on new roads that are built. Some of the roads you may be able to continue driving on, but features in the new roads my damage your car and the people in it, eventually there will be no roads you can drive on. This car also consumes more and more fuel every year that it is kept and require more and more maintenance to keep it running compared to everyone else on the road with newer cars. It also does a worse and worse job at transporting you compared to all the other new cars, and your coworkers start getting your hours because it takes you too long to get to and from work.
If you are keeping SQL 2012 around, it is costing you money and that is all there is to it. It was a good database solution in 2012, but it isn’t anymore. Even if they did continue to do critical and security updates, it is still drastically worse at doing its job than even SQL 2016 and that is costing you money. Labor is your single most expensive item and saving a dollar once every 7-8 years is a really bad exchange for saving 10 every two weeks. All of this is over something that has already paid for itself and you owe nothing to it.
A version of SQL Server that never breaks down?
That sounds great, Keith! Sign me up. Which version is that?
Believe that would be SQL Server vNext no matter what the year currently is!
— a hypothetical car that never breaks down…
Wouldn’t require so many security updates. I don’t think that’s a better analogy at all.
you can’t pick and choose which parts of reality to apply in an analogy that uses a fantasy world to make the comparison.
I just think it was a poor analogy. Why compare SQL to a car which never breaks down?
I have a car that’s almost 10 years old. I don’t have any problem getting parts for it. And if the manufacturer does stop producing them, there’s nothing stopping someone else from doing so. And I didn’t pay anywhere near the price of a SQL Server estate for it either. If I did, I’d expect the manufacturer to support it for much more than a decade. Especially considering the fact that the only reason it needs support is because it wasn’t built correctly in the first place.
Plus, if you take a 20-year-old Ford to your local Ford dealer, they will quite happily support it.
… and, off-topic, Ford is talking about bringing that back to 6 years.
Afraid of getting my head torn of here but we chose to stay on it for a bit longer.
Security bugs will still be fixed and we know her to be a well-mannered lady.
We don’t use availability groups and our software requires that we run maxdop 1 – So it a relatively simple setup.
We have 50.000+ different queries during the day. Here and there we have implemented a few “force select orders” and about 20 plan guides are in place.
She now works better than ever. We use the brilliant First Responder Kit – although not the very latest version. I believe ours is the one you released in late 2019 😉
We don’t need the support from Microsoft. We’ve never really used it other than when they released bug fixes which haven’t been much lately? Perhaps because she is a mature lady now.
Once miss 2019 is mature we may look that way. But for now she looks to be a bit “unbaked” for our liking.
So staying with Mrs 2012R3 for another year or three – We’re not too scared about it :/
Sorry – SQL Server 2012 SP4 ofcourse (not R3).
I studied so hard for my MCSA: SQL Server 2012/2014. 🙁
> “Is it okay if application ___ is running on an unsupported version of SQL Server?”
Note that the answer to this question is typically “no” if operating under any sort of compliance or regulatory scenario.
our “select * from table” works just fine. What are you complaining about.
#DucksAway
Good one! Last client is still on 2000 with few stuff to migrate. Still looking into 2008 and R2 servers to migrate with same versions on cloud. Maximum stretch is 2016. Whome to blame not getting application compatible to latest 2019( hands on) nor the organisation to understand