Last week, you used SQL ConstantCare® to analyze 2,396 SQL Servers across a variety of versions:
- 15% (362 instances) of SQL Server 2008 and 2008 R2
- 18% (438) SQL Server 2012
- 27% (650) SQL Server 2014
- 32% (777) SQL Server 2016
- 7% (169) SQL Server 2017
That means 15% of your servers are going to be out of support in about 106 days: SQL Server 2008 & R2 both end support on July 9th.
So I’m curious:
- What does your company plan to do about that?
- If the answer is “nothing,” what have you tried to convince them otherwise? Or have you?
- What’s the single biggest thing stopping you from moving to a supported version?
I’m asking because it influences how we support these older versions in the First Responder Kit, SQL ConstantCare, and Consultant Toolkit. For years, I’ve said, “If Microsoft can’t support it, neither can we,” but given the relatively high market penetration of these old versions, I’m not sure I can still say that. (After all, if I look at the market numbers, it’s more profitable to support 2008 and R2 right now than it is to support 2017!)
98 Comments. Leave new
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.
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.
This is what my VP said about our 2003 server… until it went down over xmas break. Suddenly we’re migrating off 2003! I won’t stop other people from playing Russian Roulette if they want to though. 😉
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.
We plan on upgrading all of our SQL servers to SQL Server 2017 whenever the owners approve the budget. That could take a while.
we all have SQL Server 2017, so we are waiting the rest to join us … 🙂
Business dictates to IT what technology we use, hence why we still have an app around that requires sql server 2000. 8\
Hence why we still have a Visual FoxPro database “hanging on for dear life” on a really old server. Thankfully, the data is being migrated to a SQL Server database next month so we can finally kill it off. How many years has VFP been dead? Yikes.
Last I checked, Office 2000 works fine for creating a Word document. Same situation here, really. Sure, they’ve added some sugar, and torqued the optimizer, and blah-blah-XML-JSON-something. But, apps that work on 2008 will CONTINUE to work on 2008. Nothing has changed on that front.
Still a lot of VFP out there. As of 2019 the issue with it is the flat file DBF format, really. Not scalable, not secure, prone to ransomware encryption. But VFP the DBF file format. So a lot of people just continue with the language and connect it to SQL Server or Postgres or whatever else for the backend.
Same here. We will loose support for some old application if we update the server. And it’s not only the SQL server. The OS is on Windows Server 2008, too.
The sooner we can get rid of that old app the better. But as dcariboo said: Business dictates to IT what to use.
Ditto. We’ve pushed the application vendor to get their app supported on WinSvr 2016 and SQL 2016 for a year. They’ve been dragging their feet until now. Sent us a SOW for $20k for each server – we have 15. Yikes.
Our 2008 & R2 instances are just about out the door, waiting on an old MQ system to be live on 2017, they’re running in parallel at present.
As for 2012, been trying for the last year and a half to get them upgraded to 2017, but as usual the server engineers and dba’s get put on the back burner until all the developers are ready..
If you think about all the SQL expresses that come packaged with a application (ie backup excec, AV enterprise consoles, sage accounts etc etc ) id bet i have a few SQL2005 ‘s around still. certainly loads of sql 2008’s
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.”
ah the mythical “cloud will save us money” we had people like that at my company, until we got our first azure bill.
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.
Andrew, are your application vendors charging you professional services fees for migrating their app to WinSvr 2016/SQL 2016? For example, one of our imaging vendors is charging $1000/server, another is $20k/server.
Well… google cloud or AWS solves all this…. you just pay a percentage of the license monthly and always run the latest version
Richard – oh awesome! They just update SQL Server for you and make sure your apps all work and are supported? That’s amazing!
Wow, I haven’t stayed current enough in cloud stuff, because in my AWS VMs, I still have to do all the patching and upgrades myself even though I pay them for the licensing. I’m going to go call my AWS rep right now and have them take over this work! Thanks man, you’ve really made my day.
Snarky snarky 🙂
It obviously depends on the platform you use. If you’re just IaaS, then of course you have to do it yourself. If you’re doing RDS, then AWS does indeed take care of this (at least in Aurora land)
Bad news: they don’t. (I use RDS too.) They don’t check your code to see if it works on new versions, make sure your app is supported, etc.
Yes, of course they don’t test your app. I was referring to patching and upgrades. And yes, there is always a trade-off, no matter what service/technology you use.
Ah, so they do the easiest part of the process. Gotcha. I see. Well…hmm.
If you read all the comments here, patching SQL and keeping it up2date does not seem to be the easiest part… just saying 😀
May want to read the rest of the comments. The patching really is way easier than getting all the developers & business stakeholders to agree to invest their time in updating their code and testing it. Thanks for the visit though!
it is frustrating to still have SQL2008, in the environments I support. Despite every effort to persuade my managers, there still seems to be too much fear in committing to any upgrades, and then they will only upgrade to SQL2012 (which is 5 years old!!) at a push. There are far too many choices – “what if we just go to the Cloud”, then we don’t have to upgrade…. ” While they are sitting on their Laurels, waiting for that to happen (or not), years have now passed, and it becomes too difficult to decide. So, yes, it seems there is more money in supporting <SQL2008
Any, what is the risk?
I can tell you stories of companies still pushing hundreds of millions of dollars in transactions on SQL 2008, and it works FINE. Never mind the billions in inter-company transactions. Some small to medium sized companies couldn’t care less about a support contract. They paid their license fee, and they rock right on with no problems. This isn’t going to take down the world. It works fine. Why blow more money when a.) app works fine and b.) company not concerned about “upgrades” to SQL 2008? Take a deep breath, everybody.
For most people, security is a big deal.
Security? If someone is hacking into your SQL Server, you have bigger issues than the surface of the SQL box. That’s a guarantee.
While this is true, the fact that you are neglecting SQL Server already tells me that you’re probably also neglecting to update the following to supported versions:
– Server OS
– Firewall
– Routers
– Client OS
– Client Applications
– etc.
And now you’re in big trouble…
Oddly enough, Pittsburgh DBA and Michel Zehnder are talking about the same thing. Even if you DO keep SQL Server totally up to snuff with the latest version and CU, if the rest of the stuff that Michel is talking about isn’t properly done, it won’t matter much… you’ll get hacked eventually and it won’t be pretty nor will the latest and greatest in SQL Server help you.
This is for Michel Zehnder, but this forum doesn’t allow a certain depth of replies, apparently. Anyway…I hope that when you say “you are neglecting…” that Michel is not referring to me. Because there is no “fact that [I] am neglecting” anything. I’m merely making some observations. I don’t manage any infrastructure, and I don’t really care what version someone is running. 90% of the time, they have a REASON for doing so, such as a legacy app that requires it (mentioned about 10x in this thread), or a lack of concern (such as a small business with ample ability to recover, or where an unsupported outage is just not THAT BIG OF A DEAL). If it’s critical, then by all means, update. However, there is still a lot of SQL 2000, 2005, and 2008 in the wild, and it’s not going away. I’m just a realist. What am I doing about 2008? Nothing – because I am not responsible for any infrastructure. People call me when they have a problem, and I solve the problem. That’s the gig, and I’m not going to castigate someone over their SQL 2008 licensing. Hell, the majority of SQL Server users I encounter don’t even HAVE a support contract, and they wouldn’t call Microsoft and pay $ if the company was melting down. It’s just a certain mindset, where not every company is obsessing over their tech stack, the way, say, a fanboi would.
Pittsburgh DBA you seem have an very significant amount of advice for other people regarding something that aren’t responsible for… Your observations effectively boil down to “if it ain’t broke don’t fix it”. Which is great and all if we’re talking about a doorbell or something. But not really if we’re talking computers. Do you keep your antivirus definitions out of date for 20 years too? I mean, you never got a virus before, right? I honestly think that you’ve just been lucky never to have needed to call MS for support before. But again, it’s your funeral so you do what you please. But I think everyone should take your recommendations to effectively ignore EOL support dates with a massive grain of salt.
so what does a financial institution do when they are told they can no longer trade across unsupported infrastructure, 2008 is out of support June this year – whats your fix for this?
my company is getting off of SQL 2008 R2
I suspect a reason a lot of people have migrated is the licencing model. 2008 was on a per socket license, SQL server 2012+ uses cores. Of course, is not being compliant with certain regulations (like GDPR), and having to struggle against a lack of support and functionality of the newer versions really outweigh the cost of upgrading? Depending on the business that may not be up to the DBA, who’s budget is dictated by a director who knows nothing of IT other than “if it ain’t broke, don’t fix it.”
I noticed that John C stated they were planning to upgrade to 2019 this year, considering the topic I assume that are using 2008. Unless I recall incorrectly, I didn’t think that 2019 supported 2008, so a direct upgrade path isn’t available. Of course, my memory could be failing me, and considering the statistics Brent has shared here, I think it would be a mistake for Microsoft to not support Compatibility 100 on SQL Server 2019.
Hey, we just migrated our SQL2000 boxes. . . SQL2008 & R2 will have to wait a bit more then!
Legacy apps are still running on 2008. We are waiting for the app upgrade.
B.I.N.G.O. – this is something I’ve seen many times. Some environments are running every version from 2008 R2 to 2017, mostly due to either vendor app requirements, or lack of interest in wasting money for no reason other than to be “on the latest and greatest”, which is often driven by fanbois on the programming team.
Do I dare bring up that I still have 2000 servers being deployed? We run the gambit from 2000-2016 but I’ve had to install 2000, 2005, 2008, and 2016 within the last 12 months.
You and the 95% of us that work in the real world. Inevitably, I land at a new gig, and a youngster on the team will lament something like “I cannot BELIEVE they’re still on 2016!”.
We’re almost getting to the point of a new hire saying “oh man i was born after 2000” FeelsOldMan
We’re in the process of migrating to new servers running 2016. Still working on determining what is still in use on our 9 2008 servers and what the specs need to be on the new ones. All looks on track to be rid of them in 108 days.
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.
We are migrating our SQL 2008 databases to 2012/2014/2016, but they won’t all get migrated by July 9. Why? Some older apps don’t support the newer versions, and we can’t (or won’t) upgrade the apps. Also, it doesn’t seem to be a priority for most of our users.
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).
Just read your article and immediately pinged my boss… again… who was a former development manager @ Microsoft. His response? “Well, we’ve never needed support from Microsoft before…” smh. I believe this is one of the warning signs that it’s time to change jobs, right?
NO. It’s a sign that your boss is smart about money, and there’s nothing wrong with that application. Is there a “drop dead date” where it stops processing queries? I thought not.
We have one 2008 server left and its application is close to being migrated to a 2014 server. I think a lot of the value that you and your group/tools bring to the table is that they fill in the gaps left my Microsoft in trying to support and manage a complex product like SQL Server. Continuing to support the older versions (as long as technically possible) beyond what Microsoft is able to do is a big, big, plus for people that are stuck with those old servers. Please keep up the good work.
Not 2019!!!!???
¡Qué horror!
😉
Third party vendor that requires 2008R2 SP3
We have another package that was written to run on SQL 2005 and failed when we tried to upgrade to a newer version.
We have spent the last nine months moving most of our 2008 instances to either 2016 or 2017. (One application specific instance had to be upgraded to 2012 as the users do not want to upgrade the old application until early next year.) We now have three application specific instances of 2008 left. One will be upgraded to 2017 in April and another to 2016 in May. The business owner of the application which uses the last 2008 instance has been dragging his feet for over a year despite numerous warnings that our security policy means the servers will be switched off on July 9th if nothing is done. We will see what happens! Fortunately we only have four 2012 instances so upgrading those should not be such a major undertaking.
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.
Most companies like that just buy the software once, and use it forever. For them, it’s a tool. If a user can process a transaction, and a company can get money deposited into their bank account, they usually don’t care about such things. I’m enjoying this tempest in a teacup, though. It’s pretty fun to watch.
Please don’t stop supporting these with your scripts. We are running old versions because we currently have to for local government. We’re transitioning as best we can but with multi-year application deals that have specific requirements, it puts us in a tough spot.
Agreed. Considering 2008 is not going to change, and the current kit works, it should continue to work. However, that’s your prerogative, of course. If it makes it too much trouble to maintain the kit, then we’ll survive if you ’86 good old SQL 2008. I can’t get half the kit to run on SQL Azure, so I’m more interested in that. 🙂
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).
We only just got off the last SQL 2k instance and are currently working on our remaining 2005 installation. Making the jump from 2012 to 2016 on one of our instances required months of testing and vetting before it was approved. Getting onto newer versions is a hope, but who knows when that will be approved – so I’m just hoping to get everything upgraded to at least 2016 before we’re too deep into the next decade.
I do what I can to remind those who make decisions that we need to keep the migration going. And, in the meantime, I make sure our backup strategy is as robust and dependable as possible.
I worked at a major US bank for a while, and between the paperwork and the politics, it took 6 months to perform the regression testing on the whole stack, for even the smallest of changes. That’s a lot of millions of dollars and thousands of person-hours. It’s difficult for some organizations to justify “upgrades” in these situations. Let is suffice to say that such organizations have a paranoia level that is hard to comprehend when it comes to tinkering with server products, unless you have worked inside one such company. Some would rather be running on old mainframes (and this place actually was), rather than bite that horrible bullet.
Yeppp… financial industry. It’s a mixed blessing. It’s not the harried pace of younger and rapidly accelerating companies I’ve been at, which is good for my nerves and my home-life. But the snail-paced of technological approval and adoption can be frightening. I know the devs are open, they just don’t have the cycles available to dedicate to an upgrade project.
We’re planning on upgrading before the EOL. We have PCI compliance issues, so there is really no choice. (Although they said it doesn’t fall within PCI scope which I disagree.) I more or less pointed out to them that if something goes wrong there is pretty much no help, and we’re on our own. It’s really an interesting conversation when you bring up database corruption problems as a possible scenario and getting no help.
If you want my personal opinion on supporting it. You already have the code, and it’s pretty easy to fork it at this point and say, “O.K. we’ll support the current feature set that we have right now.” That way you don’t have to spend any more time adding features and only doing the occasional bug fix. (I mean we know you all don’t write defects, but I thought I would say that to make the rest of us feel better :-p.)
This depends on exactly what the code does though. If the code you wrote to handle 2008 does things that are allowed, but not recommended, this is an entirely different scenario. IIRC, in the SQL 6.5 days you could write to the master tables, but you really shouldn’t have. Then people broke things, and were very sad, because they were told not to and did it anyway. In a scenario like this, not having Microsoft support could be disastrous, because somethings just aren’t fixable if something unexpected happens. I’d rather have support dropped in this instance, because the chance of something going wrong that could have been avoided by not using something with no way of recovering is much much worse. At least this way, Microsoft warned people well in advance they were on their own.
This reminds me that 6.0 would return query results sorted by the clustered index columns, even if you didn’t use an ORDER BY clause. When 7.0 hit, this was no longer the case, and the meltdowns were really funny. Trying to explain “this behavior was never supported” was met with the most puzzled, deer-in-the-headlights looks I’ve ever seen from business users and sponsors. Despite my many attempts to explain this simple fact, they just kept saying “but it always worked before!”. All we had to do was add ORDER BY where it was needed, but this initiated a devastating regression test cycle, so there was much wailing and gnashing of teeth.
My company is still getting hot-calls and warm-standby calls from vendor partner (MSPs) on SQL 2005, sadly. Many out of the box managed applications had some infrastructure guy install 2005/2008 Express or Standard somewhere as a data-wallet. A lot of our projects currently are 2008/2008R2 to 2016 pushes. In 2015 I ran a 2000 to 2012 push.
We are in the process of moving our databases (about 8TB) to SQL Server 2017 on Azure IAAS. It will probably take us another three months to complete the process.. many weekends.
We are planning to move the MS SQL Server 2016. We have a unique problem because some of the DB are validated due to FDA rules
Core based licensing shock was the #1 reason most don’t want to move from 2008 R2.
The reality is that a multitude of reasons exist at the business end which can dictate 2008x continuing to be used. While as a dbas we may propose best practices, there are many other factors which come into play which may trump those recommendations. We handle support for many customers each of which we see with various reasons for certain systems staying on 2008x. I hope you’ll continue to support it.
When you’re locked into an app that embeds SQL 2008 in itself, what can you do? Wait until they get the lead out and release a new version, which I hear is going to step all the way to 2012! 🙂
SQL 2008. Hahaha. Company I work for has a SQL 2000 server in full on production. It runs a critical app that’s being obsoleted and replaced this year but it does more work than all other days combined. In fairness it had 1000s of queries run against it that we know don’t work the same in later versions but… I’m just glad to finally get to say goodbye.
You don’t need to support “First Responder Kit, SQL ConstantCare, and Consultant Toolkik” if you ave a development sunset date on it. Put a disclaimer on it. No more upgrades/fixes etc…. Contact us on how to get off legacy SQL versions!
The tools can be still avialable. In general they will still work. There is not some magical date where it just stops working is there.
I agree since Microsoft offers extended support on SQL2008\r2 if you move your server to Azure. And we have one customer who is moving now all it’s 2008 instances to Azure.
What does your company plan to do about that? Upgrade to the most recent supported compatible version.
What’s the single biggest thing stopping you from moving to a supported version? Legacy Apps and a DevOps manager with his head in the sand.
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.
My company is working to upgrade all but some will probably stay behind. After all, we still have one SQL 2000 server and the last 3 2005 will be shut down next month.
http://2.bp.blogspot.com/-vfRIhEJ8sfc/TzcoWxMRxwI/AAAAAAAAmb0/QNUNDOONIx8/s320/funny-dog-pictures-i-cants-hear-you-la-la-la-la-la-la-la-la.jpg
Classic!
I’ve been with my company for 6 months, and fortunately we only have a couple of SQL 2008 R2 servers in the environment (that I have discovered). Unfortunately, one of those servers holds a couple of very mission critical applications, that have only recently announced supported upgrades to SQL 2014. We are just beginning to plan upgrades for the latter half of this year, but we also have to untangle 9 years of interconnections with databases and applications on other servers and versions of SQL as well, as well as introduce High Availability into the mix, and work around version compatibility issues with pub-sub between those different versions (up to SQL 2017). It comes down to what is important to the company in a given quarter/year and what they are willing to budget for it. Lack of MS support is a relatively minor consideration when it comes to budget line items…but when the vendor of one of our critical apps says we have to upgrade their app to meet regulatory compliance then they will move heaven and earth to get it done.
2008 R2 Web is a fantastic licensing option that simply isn’t available in the newer versions. The equivalent would require us to move to enterprise edition which would cost upwards of $250k/year. It has also proven to be rock solid over many years.
nothing 🙁
The Databases are stuck in 2000 (80) compatibility because the application has thousands of internal scripts and procedures that use “*=” join syntax.
The application is slated to be replaced in the next 3 years.
Geez! We still have 2005 for one db! It works and we dont apply patches. 🙂
I’m tickled!!! It means that 2008 is finally STABLE!!! 😀 😀 😀
As an ISV we’re asking our customers the same questions right now with the addition of questions around upcoming OS versions end of support.
Honestly, I think half the issue is the socket to core switch but the other half is the my business doesn’t have the right type of IT management penetration and all our calls are falling on deaf ears. We’re talking about 2008 and R2, my organisation still has two 2005 servers about, handling and churning data and I’ve told them repeatedly of the issues around security etc but also on deliverables but nothing’s happening. It’s doesn’t help our IT is outsourced to IBM/Ecenca and they’re crippling the organisation with their incompetence.
We’re pretty close to those numbers. out of 3500+ instances, 14% of them are 2008. We’ve had a plan to upgrade those since last year and the team is slowly churning away at them. Going to 2014, iirc. Not my decision, I’m just a lowly developer. At least we’ll be able to program against new features in 2012 once we have those others upgraded. (This product spans multiple version, but we have to go with the lowest version in the wild… and I do mean wild, very wild.
Migrating 90% to 2016 (Server and SQL), the rest will be risk accepted by the business. Raised it 2 years ago as a risk and they raised a project in Feb this year. Not ideal but…
We’ve almost finished migrating our (many, many) SQL Servers from 2008 R2 to 2014, after several years of a migration project. When that’s done, later in the year, we’re probably starting the next round of migrations – waiting to see if 2019 RTMs before that happens, or if we’ll be going for 2017.
We’ve spent two years migrating systems from SQL 2005/2008. WE have one system that uses RDM disks on a failing legacy SAN on an OS/SQL/App version no longer or about to be unsupported and we still have issues getting developers involved for not billable work.
I guest upgrading had never been a problem. I thing keeping the infrastructure under support is the real issue and with 2008 and 2008 R2 is no longer possible. Also does not provide all the HA + DR capabilities the way all DBA desire to have.
As an MSP for small-mid size businesses, we see a lot of our clients still on 2008 – the biggest deterrent for getting them to approve upgrades is cost. What will we do? Recommend, have long conversations on why, maybe even beg a little but at the end of the day, we’re still going to end up supporting a good chunk of them for awhile probably.
Michelle, regarding “approval for upgrade costs”; are your app vendors charging you professional services for migrating their app to Windows Server 2016 ? (or SQL 2016)?
Luke – please stop leaving the same comment. Thanks!
Totally agree. It’s what it’s….from that perspective. I think letting then know their risk is the correct approach. From that point on, it’s on their hands.
What are the risks of updating from SQL 2008 to SQL 2017? In other words, what can break? Thanks for any insights!
Aaron – that’s kinda beyond what I can answer fast in a blog post comment.
Ok, I was hoping there was a simple list of things to look out for, especially anything that is not backwards compatible. I recall years ago upgrading SQL and we had issues with triggers because of the upgrade.
Probably everything
I’m just here to to report that it’s October, 2020, and I’m working with a huge company that you’ve heard of to upgrade from SQL 2008. The update itself is trivial, but updating code to lose deprecated syntax in its interactions is many hundreds of hours. We’ll be good to have it done in Q1 2021.