If you have SQL Server instances that are out of support, which is any version prior to SQL Server 2014, then I’m sure you have your reasons for not upgrading to a newer version. Let’s take a quick look at those reasons and then examine one reason you might not have considered. My hope is you might change your mind by the end of this post.

Saying no to horsing around with upgrades

I have a client that just this year migrated off and decommissioned a SQL Server 2000 instance. If the instance was a person, it would be old enough to drink. That’s a sobering thought.

It’s remarkable but not completely out of the ordinary. Here in 2022 still have clients using SQL Server 2005, 2008 (both versions), and 2012, and all those versions are out of Extended Support. From what I can tell, the decision to avoid an upgrade is driven by one or more of three reasons: cost, fear, and apathy.

The cost may be related to licensing costs, or costs for new hardware, or cost of employee hours to conduct the upgrade. The fear is that if migrations associated with upgrades go wrong, they can lead to a lot of avoidable downtime. And the apathy comes from the “if it ain’t broke, don’t fix it” line of thinking.

I get that no one wants to spend time and money on a upgrade that could ultimately be rolled back, and then suffer through a Root Cause Analysis meeting with their supervisors. That’s a meeting anyone would skip for a root canal instead. From a business standpoint, the risk of upgrading looks more likely to be a dramatic loss than an impressive win.

The problem is when this upgrade avoidance becomes the default thinking: SQL Server is working fine, we don’t need the headaches, so we don’t need to try an upgrade.

Carrots and sticks

Microsoft puts a lot of effort into selling the shiny new features in each version of SQL Server to try to entice everyone to upgrade to the newest instances. While it’s easy to appreciate the intention to upgrade the product every few years. Often, those new features don’t appeal to everyone. Query store is wonderful, but if you don’t know how to use it, then it’s not much of a motivation to upgrade. And have you found a business need for resumable online index rebuilds or stretch databases? Probably not.

If the new features don’t apply to the business usage of your organization, then you understandably have little motivation to upgrade to a new instance. And even if you did want to consider using the new bells and whistles, you may need to train your staff on how to use them.

Of course, if you don’t appreciate the new features, Microsoft’s fallback position is to strongly remind you these new versions be out of mainstream support (functional, performance, and scalability updates) in five years and extended support (security updates) in ten. After that, you’re at the End of support era, which never ends. If you’re running SQL Server 2012 or prior, this is where you are at.

And yet, many decide they’re quite fine with that.

Horses prefer carrots

Here’s the thing about feature upgrades – they aren’t the same for all editions. Now when I say editions, I don’t mean the year – that’s versions. I mean Enterprise and Standard. For the sake of brevity, or what’s left of it in this post, I’m not mentioning Developer or Web editions. Your time is valuable, so we’ll move briskly.

If your instances absolutely need:

• more than 24 cores (or 4 sockets, whichever is lower)
• more than 128 GB of memory
• more than two nodes for a Failover Cluster or Availability Group
• more than one database in an Availability Group with more than two replicas
• online index rebuilds
• resource governor

…then you need to stay on Enterprise edition. Thank you for reading; you can skip the rest of the post.

There are some other features exclusive to Enterprise edition, but if you can look at that list and say you don’t need those things, you might be able to save about $5000 per licensed core.

I’ll say that again: you might be able to save about $5000 per license core. Do I still have your attention?

There are many features introduced in Enterprise edition that are critical to your SQL Server that folks don’t realize were later integrated into Standard Edition. SQL Server 2016 Service Pack 1 was kind of a big deal, as it enabled the following features in Standard edition for the first time:

• Always Encrypted security
• Change data capture
• Columnstore indexes
• Data compression
• In-memory OLTP
• Partitioning

Although it wasn’t heralded as much, SQL Server 2019 introduced the widely-used feature Transparent Data Encryption (TDE) in Standard edition. In fact, for SQL Server 2019 all RDBMS security features are supported in both Enterprise and Standard.

Recently I had a conversation with a client on SQL Server 2016 Standard edition, and for compliance reasons, they need to enable TDE. They were concerned about the extra expense of upgrading to Enterprise edition for this one feature, so imagine their excitement when I told them they just needed to upgrade to SQL Server 2019. Maybe you got excited reading this as well.

Summary

There are many, many good reasons to stay on Enterprise edition. There aren’t a lot of good reasons to stay on your out of support version of SQL Server. But there are some really good reasons why you might want to upgrade to a newer version, and also downgrade to a less expensive edition.