Last week, I asked you what you were going to do about SQL Server 2008’s fast-approaching end-of-support date.
Here were some of my favorite responses from blog comments and Twitter. Terry’s been doing a good diligent job, but struggling to keep up:
Like Andrew we’ve been working on retiring/migrating off 2008 (to mostly 2014 or 2016) for 1.5 years. We started with 25 instances and are down to 3. They’ll be done by the EOL date. Then a couple year breather before we rinse and repeat with 2012 (EOL 7/12/2022).
Trav wrote:
if you’re my company you ignore the dbas who have been warning about this for 2 years and then get mad when we point out that time is up.
But Pittsburgh DBA responded with something that I heard from a lot of commenters:
Who cares? It works fine, and it’s been working fine for a hell of a long time. This panic attack going on around the country about 2008 is hilarious.
I don’t know that I’d say it works fine because I usually reserve the time fine for things like art and dining. If SQL Server 2008 was a restaurant, it’d be more Mickey D’s and less Top Chef – but I get where he’s coming from.
Similarly, Alen points out:
my old employer still has some 2005 servers. They still work. there is no money to upgrade them. When i worked there i called MS maybe 2-3 times in many years for SQL support.
I’ve heard that remark about support from several clients, too, as in, “We don’t call them for support anyway. That’s why we have you, because we got burned by a few bad support experiences.” I try to gently remind them that I don’t have the capability to write patches for bugs.
Mark Freeman’s servers are on life support:
We have four 2008 R2 instances that I’ve been asking to upgrade for almost 2 years. The answer has always been, and continues to be, that they are supporting a legacy application that we intend to retire Very Soon Now and therefore we don’t want to put any resources into an upgrade project. That legacy application is, in fact, being replaced and the replacement (using Azure SQL Database) is rolling out over the next two years. Meanwhile, the legacy version (not in Azure) is responsible for supporting 80% of revenues. That going out of support doesn’t seem like an optimal situation.
John Cas points out that even Microsoft’s apps have those problems:
Lol, MS have a hard enough time keeping their supported products with the newer versions of SQL. We will support sql 2014 with MS <product x> but not 2017. Heaven help you if you ask them to tune something.
— John Cas (@moresunshine_1) March 28, 2019
Greg Low reminded me of something I’d (happily) forgotten about:
Core based licensing shock was the #1 reason most don’t want to move from 2008 R2.
And on a related note, Jeff G reminds you that the upgrade money might come from the same pocket that pays your salary:
In the industries I have worked in (casino vendor, transportation, construction), the idea of upgrading because Microsoft stopped supporting the software is laughable (as in I was laughed at when it was suggested to upgrade). But on the same token, these guys do not see technology as a revenue generator but more as a revenue black hole. No matter how I explain it, the sticker-shock is too great. Since these were smallish companies, I don’t necessarily blame them. “As vote of hands, who would rather have bonuses this year and who would rather run software that is supported by Microsoft?” Software always loses in that case. Now if I am a 1000+ person company with multiple data centers (and cloud instances) then the sell is far easier (at least it was for me). This was due to rolling it into the master licensing agreement (you know for all the Windows licenses, Office 365 licenses, and server licenses) which was a yearly expense that was already budgeted for. To give you my opinion, if the support of 2008/2008 R2 doesn’t cost too much, then I would leave it in.
Tony’s company is thinking big because they’re tired of this hamster wheel:
Expired versions of ERP & integrated engineering systems (running on 2008R2) have to be dealt with first before turning off old OS & SQL is possible. Work is *finally* underway (6 years ago I came to this job to do this), but these systems will probably hang on for another 2 years. And maybe longer, if it’s decided to keep them running as reference. Infrastructure team wants to airlift the data center into cloud, which at least takes hardware failure off the risk list (7 years old and counting).
John C wrote:
we plan to make the leap to 2019 by end of Q3… but considering 2017 in case the RTM launch of 2019 delays to end of Q2.
It’s easy for me to say this from an armchair perspective, but I think Microsoft made a mistake with the 2019 launch timing. They used to make a lot of noise that they were going to ship a new version every year on a “fast train” of releases, but 2019 is taking longer to ship than 2017 did. I know the MS folks will say, “But 2019 has so many big features and we can’t rush it” – that just means someone got the scoping wrong, and should have shipped a smaller incremental set of features earlier.
On a related note, Rowdy Vinson tweeted:
But really though, 2017 is kinda the flyover state of sql versions. 2016->2019
— Rowdy Vinson (@RowdyVinson) March 27, 2019
I had to laugh at that. I love 2017 and I use it every day, but I gotta confess that when I wrote the post Which Version of SQL Server Should You Use, the 2017 advantages weren’t quite as awesome as I’d have hoped. But wasn’t I just saying MS should ship a smaller set of improvements, more often? 2017 is what that would look like, and it’s fine. No, not fine as in…<sigh> Moving on.
Shaun Austin wrote:
I think the apathy from some organisations comes from not really understand what a lack of support means. I work for an ISV and our software runs on SQL Server 2008 or later. I’ve been encouraging our customers to upgrade SQL Server for the last 12 months or so. The typical conversation goes like this:
Customer: “what do you mean when you say our version of SQL Server won’t be supported from July?”
Me: “I mean Microsoft won’t provide critical security updates and bug fixes. Nor will they provide technical support in the event of a serious problem, nor will it be guaranteed to run on later versions of Windows Server.”
Customer: “Huh….but your software will still work…right?”
Me: “Well…as it stands….yes…so long as SQL Server is able to run…our software will continue to work. There are other performance and feature benefits too of course”
Customer: “Hmm…ok…well…I don’t have a problem now, and an upgrade to SQL Server seems really expensive…I’ve also heard about that cloud thingy which is going to save me a chunk of cash and I’m definitely going to look into that…..hmm….I’ll get back to you.”
Or as Dcariboo summed up:
Business dictates to IT what technology we use, hence why we still have an app around that requires sql server 2000. 8\
Andrew Miller summed up the life of an admin:
We’ve been migrating DBs from 2008/2008R2 to 2016(preferred) or 2012 for the past 1.5 years. We are down to 4 applications still running on 2008/2008R2. We plan to be complete by next week. At which time, we’ll start planning the migrations from 2012 to 2019.
But I think Jeff Moden’s comment was my favorite:
I’m tickled!!! It means that 2008 is finally STABLE!!!
10 Comments. Leave new
I’ve just inherited a SQL 2000. There are younger people working here.
There is a SQL 2000 isolated off that I don’t ‘officially’ support…except for when they ask.
SQL 2008/R2 migration. It still runs fine, few care about spending resources to upgrade except perhaps my boss. And his opinion doesn’t count much to the others either.
I have 60-70 instances to upgrade. Many are also on Windows Server 2008 R2 which is also going end of life. But at the end of the year so that effort is also moving slowly. Doesn’t help me, because the end of life dates don’t match up.
One server, the guy left (he’s also dead now), and the team didn’t even know what the servers were. Managed to convince them to retire that one by starting to plan the migration with them and pointing out how much better off they would be to just get new servers built and install the new version when they were ready to do so (which will most likely be never anyway).
Fun stuff. As other’s have pointed out, it still runs reliably and there is no real ‘good’ reason for them to upgrade in their minds.
We’re working on removing the last stuff from a 2008r2. The hardware is being shut down, and we’ve moved to azure.
Our azure vm has had 3 major outages in the last 3 months, because af azure instabilities.
The 2008r2 box has been chugging along for years with no hickups. Microsoft just told us to invest in ha if we want stability from their offerings.
The cloud path is not always the best, and it’s definitely not cheap.
If you are in the healthcare industry then not upgrading will be a HIPAA violation.
How’s that? i’ve managed SQL 2005 servers recently and we were SOC2 compliant.
Not familiar with HIPAA, but I know that in the case of PCI, the general consensus is that using EOL software is probably non-compliant, since PCI requires software systems to be kept up to date with vendor-supplied patches within one month. One could argue that, “if there’s no match, you’re up-to-date,” but the PCI council has stated in their FAQs that this is not the case (and most security auditors agree). That said, you could possibly get a “compensating controls” pass if SQL is running on a dedicated machine with no internet-facing access (which, absent a BI or data explorer system, should be the case for most businesses).
I’ll also note that many security policy documents have a catch-all hidden somewhere in the terms that says something like, “Use security best-practices. Don’t ignore vendor recommendations, OWASP, the CVE database, etc.” While it’s generally not considered inherently bad practice (security-wise) to use older, supported software (assuming it isn’t missing a feature required for security), EOL software is definitely considered bad security practice.
Mind you, most of these sort of things are self-reported, so companies are often found compliant because the IT department interprets the company as being compliant, despite all the stuff I mention above.
All these stories made me feel a lot better about my situation. I’ve been chipping away at this for a few years. The main obstacle for me has been getting IT assistance to help do the migrations, it’s just not a priority for them and they’re squeezed for time, money & resource. In my case it’s never just about moving a db. There’s reports to be redeployed, ETL, OLAP Cubes to be moved, “Integration” queries with 3 or 4 part names, Excel spreadsheets and ODBC connections sprinkled all over the place. Moving 1 db is easy, finding all the crap that connects to is a nightmare.
In 2016 we had about clients on SQL2000. We tried to pry it from their cheapskate hands, we warned them in advance that our application will not work any more on SQL2K, and when that happened – they all decided to upgrade within the same week.
Now we still have about 50 clients on SQL2005 who upgrade when/if they change the hardware.
I consider a small personal victory that I convinced my coworkers to install SQL2017 on new instances (“Hey, it’s been a year since 2017RTM, it’s stable now, safe for production, do you have any reasons to stick to 2012?”).
> In 2016 we had about 10 clients on SQL2000.
Fixed
We’re in the middle of upgrading all of our 2008R2 and 2016 SQL Servers to 2016. A lot of pushback from people running legacy systems (MS Access Data Projects)