SQL Server 2016 end of support: how to choose your upgrade path

SQL Server 2016 reached the end of extended support in July 2026, which means it no longer receives regular security updates unless you pay for Extended Security Updates (ESUs).

Your realistic options are to upgrade to SQL Server 2025, upgrade to SQL Server 2022, or buy ESUs for up to three more years (to July 2029), whether you run SQL Server on-premises or in Microsoft Azure.

For most production systems, I recommend a side-by-side migration to SQL Server 2025 unless an application vendor or a removed feature rules it out.

The right approach ultimately depends on application compatibility, infrastructure constraints, acceptable downtime, licensing costs, and how long the new environment needs to remain supported.

In this article, I’ll cover the key decisions (in-place vs side-by-side, SQL Server 2022 vs SQL Server 2025, on-premises vs Microsoft Azure, and ESUs), plus a pre-upgrade checklist and rollback advice to keep risk low.

What are you trying to achieve with your SQL Server 2016 upgrade?

Before making an upgrade decision, you need to work out what exactly you’re trying to achieve. This might seem obvious but, in many organizations I’ve worked in, it’s actually not.

Some just see the support lifetime and want to get onto a supported version as fast and as disruption-free as possible, while others take advantage of the interruption by consolidating their servers, replacing old systems (or improving their availability) – or even moving their workloads to Azure.

What to find out before choosing a SQL Server 2016 upgrade strategy

Whenever I’m discussing this type of upgrade with clients, there are several things I want to know:

It’s critical to really check out what’s being used in terms of third-party applications, since vendors often certify their software for specific SQL Server versions. I know that Microsoft has been telling them for years to target database compatibility levels instead of database server versions, but the message still isn’t getting through to them.

Even if an application works perfectly on SQL Server 2025, there may be a roadblock if the vendor will only support it on SQL Server 2022. It’s unlikely that the client organization will be happy to move to a setup that breaks their vendor support.

You must also consider the level of operating system (OS) support. It was common to install SQL Server 2016 on Windows Server 2016, for example, but that’s not possible with SQL Server 2025. We usually find that those servers need an infrastructure refresh anyway.

What you find here should determine the strategy you use for upgrading from SQL Server 2016, and there are two core ways of doing this.

In-place upgrade vs side-by-side migration: which should you choose?

There are two core ways to upgrade from SQL Server 2016: install the new version over the existing instance (in-place), or build a new instance and move your databases to it (side-by-side).

In-place upgrade (pros, cons, and risks)

One way of upgrading from SQL Server 2016 is by an in-place upgrade, which installs the newer SQL Server version over the existing instance.

The main advantage of this approach is simplicity – there’s no need to migrate every database, recreate logins, or redirect applications to another server.

However, there are also some downsides to this approach. The fact that you are modifying the existing instance, for example, can make rollback difficult. I generally won’t ever do this unless I know that a full image backup of the server and all associated drives has been made.

Additionally, the upgrade itself requires downtime, and you need to allow for a rollback time window in case that’s necessary. I can’t tell you how often I see clients who have not allowed sufficient time for potential rollback situations.

Can you upgrade SQL Server 2016 directly to SQL Server 2025?

If you’ve applied Service Pack 3 (SP3) for SQL Server 2016 (as you should have by now), then a direct in-place upgrade to SQL Server 2025 is supported, presuming the edition and OS requirements are met. There’s no need to make a transition step through SQL Server 2019 or 2022 first.

Side-by-side migration (pros, cons, and how it works)

Side-by-side migration involves building a new SQL Server instance and migrating databases and associated objects to it. While this can of course be more work, there are many advantages to doing this.

The new environment can be built, configured, and tested independently – and both the hardware and operating systems can be upgraded at the same time. You also might be able to migrate applications one by one rather than all at once.

And lastly, the original setup might remain available for testing.

One important lesson I can offer from the school of hard knocks: use different service accounts, logins, etc. for the upgraded system.

I’ve seen clients who had both the old and new systems available on a single network, and applications talked to a mixture of the systems. What a mess!

How to run a side-by-side migration: backup and restore, log shipping, or availability groups

There are many options for how to do the actual migration. You can use backup and restore, log shipping, and availability-group-based approaches where supported.

I recommend log shipping for large database migrations. How log shipping works is simple: a final tail log is taken on the old system and applied to the new system when you’re ready to migrate. I’ve seen that take only a few seconds.

It’s for these reasons that I prefer carrying out a side-by-side migration for most production systems.

In-place vs side-by-side at a glance

SQL Server 2022 vs SQL Server 2025: which should you upgrade to?

Clients used to be hesitant about upgrading to a new version of SQL Server, instead choosing to wait until at least one service pack had been released, but the approach has been different since the discontinuation of service packs nearly a decade ago.

As I mentioned earlier, I see customers choosing SQL Server 2022 simply because it’s been available for longer and they think that means it’ll be more stable. That’s not quite how I see it, though.

Ever since the team moved to using a common code base (many years ago), the best patched version of SQL Server 2022 is SQL Server 2025.

If you’re using brand new features in SQL Server 2025, that’s a different story – but if you’re using the same features that you were using on SQL Server 2016, SQL Server 2025 is the best patched version of SQL Server you can use.

Given SQL Server 2022 reaches the end of extended support in January 2033, and SQL Server 2025 extends that to January 2036, moving to SQL Server 2025 gives you another three years of supported lifecycle. That’s an important difference if you’re undertaking a substantial migration.

After all, why invest heavily in an upgrade only to face another one sooner than you need to?

In my experience, SQL Server 2025 just runs SQL Server 2016 applications better. It’s the result of various improvements such as intelligent query processing, security, developer capabilities, and integration with modern data platforms.

At my company, we’ve been particularly impressed with the adaptive query plan changes that have happened over the years.

However, SQL Server 2025 is not better for every workload. There are many things you need to consider, like changes to linked-server connectivity and requirements around encryption.

Also, some components have been removed, such as Master Data Services (MDS) and Data Quality Services (DQS).

That hasn’t affected us and our clients yet, but you need to check your own situation. If you rely on MDS and/or DQS, or a software vendor hasn’t certified SQL Server 2025, SQL Server 2022 is probably better for you in the interim.

Verdict: choose SQL Server 2025 unless there’s a clear reason not to

My preference would be SQL Server 2025 for new migrations, unless there is a demonstrated technical or commercial reason to remain on SQL Server 2022.

SQL Server 2022 vs SQL Server 2025 at a glance

Keep SQL Server on-premises or move to Azure?

Upgrading SQL Server versions may also be a good time to consider exactly where you want SQL Server to be run. On-premises or in the cloud?

Keeping SQL Server on-premises can make sense where workloads depend on local applications, low-latency connectivity, particular hardware configurations, or existing infrastructure investments.

On the second point, never underestimate the impact of latency differences! Last year, I did work for a bank who were moving their systems to AWS-based cloud infrastructure. In theory, they had provisioned resources that were about eight times the size of what they had on-premises.

The result? An overnight process that used to take two hours, now took eight (and that’s why they got us involved!) As it turned out, most of the issue was latency – the applications were simply too chatty.

How to migrate your SQL Server to Azure: the three options compared

If Microsoft Azure is your target for a SQL Server migration, you have three options. Below, I’ll explain each one to help you determine which is best for your use case.

Azure SQL Database: most change, best for new applications

Azure SQL Database is my preferred choice for a SQL Server migration, but it’s more complex than just migrating an existing on-premises SQL Server database. You need to be prepared for redevelopment work.

Migrating to Azure SQL Database makes most sense for greenfield applications (software built entirely from scratch).

SQL Server on an Azure VM: closest to what you run today

SQL Server is highly compatible with Azure Virtual Machines (VMs). Chances are, when running an environment on an Azure VM, it’ll be very close to what you’re already running (or have run in the past).

Azure SQL Managed Instance: the middle ground

Azure SQL Managed Instance is, in many ways, the middle ground. You don’t need to manage the platform beneath it, and you can take advantage of automated patching and built-in high availability.

It’s not the same as SQL Server, though. If you’re using features like FILESTREAM or FileTable, you need to consider alternatives.

Azure migration options at a glance

What else to consider before a potential Azure migration

You also need to consider the cost implications of a potential Azure migration, but don’t just focus on the price of the database service. Make sure you compare the complete cost of compute, storage, licensing, backup, availability, and administration.

A potential move to Azure is often a separate architectural decision and, with most of my clients, SQL Server 2016 reaching end of support would rarely trigger the move.

It might be a good idea, though, and preparing for an upgrade is as good a time as any time to consider it.

SQL Server 2016 Extended Security Updates (ESUs): length, cost, and limits

You might run into a situation where you simply need to keep running SQL Server 2016. If you don’t want to be unsupported during this time, Extended Security Updates (ESUs) provide critical security updates for three additional years, ending in July 2029.

However, ESUs aren’t the equivalent of ‘normal’ product support, so don’t expect new functionality or routine bug fixes. You also need to consider the cost. I’m always nervous about mentioning prices, but I’m told by customers that Microsoft have quoted around 75% of the on-premises license cost each year.

Note: I only mention that as a guide. Actual charges depend on many things.

There was a period when moving an unsupported SQL Server workload to an Azure VM automatically unlocked free ESU support, but I’m told that’s no longer the case and SQL Server 2016 VM ESUs must be paid for.

Again, though, talk to Microsoft for further information specific to your use case.

ESUs might be useful if you know an application vendor needs more time before upgrading, and they’ve already committed to development of a ‘replacement’ version.

Otherwise, it’s probably time to find a new application vendor instead.

Database compatibility levels: why they matter when upgrading

Originally introduced to avoid upgrade blockers, database compatibility levels have been useful tools over the years.

Imagine you had a database object called ‘XYZ’, but ‘XYZ’ has suddenly just become a reserved word in the latest version of SQL Server. That could stop you dead in your tracks, but with database compatibility levels you could run the code with the previous level while upgrading your code to avoid the issue.

Nowadays, however, they’re much more than that. Your database doesn’t have to be at the same level as your server, for example.

A database running at compatibility level 130 on SQL Server 2016 can stay on that level after moving to either SQL Server 2022 or 2025 – allowing the engine upgrade and compatibility-level change to be treated as separate activities.

I’d still recommend that you initially keep the existing compatibility level to make sure the apps work as expected. You can then raise the compatibility level as a separate, planned change. Try to avoid running at the lower compatibility level indefinitely.

SQL Server upgrade checklist: 7 things to do before you start

Before scheduling a SQL Server version upgrade, I’d suggest you do the following (and it’s more than just running SQL Server Setup).

Take inventory

Record databases, SQL Server versions and editions, operating systems, service accounts, linked servers, SQL Agent jobs, SSIS packages, encryption keys, and high-availability configurations.

Check application support

Confirm that applications, drivers, and third-party components support the proposed SQL Server version.

Check version compatibility

Identify any discontinued features, deprecated syntax, or configuration changes that could block the migration

Establish performance baselines

Before starting a SQL Server version upgrade, make sure you capture representative CPU, memory, I/O (input/output), query-duration, and wait-statistics. If it makes sense for you, enable and configure Query Store (which I know is not for everyone!)

Validate backups

Take current full backups, ensure the necessary log-backup chain is available, and perform test restores on other servers. Make sure that encryption certificates and keys really are both available and recoverable.

Rehearse the migration

Where possible, rehearse the complete migration using a representative workload, including application connectivity, security, scheduled jobs, and maintenance operations.

Document the cutover process

Define the sequence of activities, responsibilities, expected downtime, validation checks, and the point at which rollback will be required.

SQL Server upgrade rollback: why you need a plan before you start

I often find that rollback is the weakest part of the upgrade plan for many organizations. They tend to forget that SQL Server database upgrades are usually one-way operations.

This is because, once a database has been upgraded to a newer engine version, its files or newer-version backups can’t simply be restored onto SQL Server 2016 – even if the database compatibility level stays the same.

While an in-place upgrade might seem simple, recovery might require you to rebuild the whole environment and restore backups.

Even though you still have the original system with a side-by-side upgrade, you might have a data issue if any work was attempted on the upgraded system. That would potentially be lost.

Summary: how to upgrade from SQL Server 2016

If you’re using SQL Server 2016, you probably don’t need to move away from it – but the support deadline shouldn’t be the only decision point.

Generally, I’d recommend a side-by-side migration to SQL Server 2025 and that will be the strongest long-term option, but only if your application support is available. If not, SQL Server 2022 might still be a valid choice, but I’d suggest only where application compatibility or vendor certification demands it.

If you are upgrading, you should consider whether Azure SQL Managed Instance or SQL Server on Azure VMs make sense.

Finally, if more time is genuinely needed, Extended Security Updates can provide some limited breathing space.

In the end, you don’t just want to end up with a new version of SQL Server. You need to have an environment that’s supported, tested, recoverable, and better positioned for the years ahead.