How to upgrade SQL Server 2016 to SQL Server 2022 or 2025

This guide is for whoever is responsible for a business system that still runs on SQL Server 2016: an IT manager, an operations director or the one developer left who knows the application. Extended support ended on 14 July 2026, so the database no longer receives free security fixes. Our SQL Server 2016 end of support page has the background. This guide covers the upgrade itself, step by step.

The steps are the same for SQL Server 2022 (supported until 11 January 2033) and SQL Server 2025 (supported until 6 January 2036).

Before you start

Find out:

the version and edition of the current server, and the Windows Server version underneath it;
everything that connects to the database: applications, reports, spreadsheets and interfaces;
for any third-party application, which SQL Server versions its supplier supports.

Have in hand a backup that has been restored as a test, administrator access to SQL Server and Windows, a test server, and a list of the work the business depends on, including month-end tasks and the slowest reports.

In our judgement, finding out (steps 1 to 6) and rehearsing (step 7) take most of the effort. The cutover is short by comparison, and raising the compatibility level is a small job spread over a long wait.

1. Confirm the version and edition

On the existing server:

SELECT SERVERPROPERTY('productversion') AS version,
       SERVERPROPERTY('productlevel') AS level,
       SERVERPROPERTY('edition') AS edition;

SQL Server 2016 reports a version beginning 13.0, and Service Pack 3 is 13.0.6300 or higher. Note the edition, because the supported upgrade paths depend on it. SQL Server 2025 has no Web edition: Microsoft has discontinued it, and a Web edition server moving to 2025 goes to Standard or Enterprise.

2. Check the Windows Server underneath

Microsoft’s requirements say SQL Server 2022 needs Windows Server 2016 or later and SQL Server 2025 needs Windows Server 2019 or later. So SQL Server 2025 cannot go on a Windows Server 2016 machine.

Nor can you upgrade Windows first and leave the old database engine in place: Microsoft’s compatibility table lists SQL Server 2016 as not supported on Windows Server 2022 or 2025. Windows Server 2016 has its own end date of 12 January 2027, and our Windows Server dates page lists the rest.

3. Choose the route

In-place upgrade. SQL Server Setup replaces the existing installation on the same server and upgrades every database. Microsoft supports this from SQL Server 2016 Service Pack 3 or later, to both 2022 and 2025. Microsoft describes this route as the easiest, but it needs downtime and takes longer to fall back from, because the old installation is overwritten.

A new server alongside. You build a new server with the new version, leave the old one running and move the databases across. For most databases this means backup and restore, and the downtime is the time taken by the final backup, copy and restore. For a large database, log shipping shortens that. A full backup is restored on the new server in advance, then backups of the transaction log (the record of every change) are applied on a schedule, so only the last one remains at cutover. Microsoft supports log shipping from an older server to a 2022 or 2025 one.

Microsoft’s guidance says the new-server route reduces risk and downtime compared with an in-place upgrade, and we agree. The old server stays untouched as a fallback, and an old Windows Server is dealt with in the same move.

4. Leave the compatibility level alone

Every database has a setting called its compatibility level, which tells the engine which version’s query behaviour to use. SQL Server 2016’s level is 130. The default is 160 on SQL Server 2022 and 170 on 2025, and both still accept 130.

A database that is restored or upgraded keeps the level it had. Microsoft ties changes in the query optimiser, the part of the engine that decides how each query is run, to the level, so queries are planned as they were on 2016 until somebody raises it.

SELECT name, compatibility_level FROM sys.databases;

Leave it at 130 through the upgrade. Keeping the old level does not bring back features Microsoft has removed, which is why step 6 exists.

5. List what lives outside the database

A backup contains the database and nothing else. Microsoft documents what is held elsewhere on the server and has to be recreated on the new one.

Logins. Stored in the master system database. Users in a restored database lose their link to a login unless the logins are copied across with the same identifiers. Microsoft’s sp_help_revlogin script copies them with their passwords.
SQL Agent jobs. Stored in msdb: overnight imports, maintenance and emailed reports, with the credentials and proxy accounts they run under.
Linked servers. Connections to other databases, which may need drivers installing. SQL Server 2025 changes the encryption defaults, and Microsoft warns that existing linked servers can fail unless a valid certificate is in place.
SSIS packages. Integration Services packages import and export data. Those stored in msdb are exported or redeployed, then upgraded to the new package format.
Reporting Services reports. Since SQL Server 2017, Reporting Services has been a separate product with its own installer. A 2016 report server is migrated, not upgraded in place, and its encryption key must be backed up first. With SQL Server 2025, Microsoft provides Power BI Report Server in its place.
Server-level settings. Configuration options, server-level triggers and the certificates used for encryption. An encrypted database cannot be restored without its certificate.

6. Check for removed and deprecated features

Microsoft lists the features removed in each version. For SQL Server 2022 the list includes Stretch Database and Hadoop data sources for PolyBase. SQL Server 2025 removes Data Quality Services and Master Data Services. In our experience few line-of-business databases use any of these.

The SQL Server 2025 breaking changes are more likely to matter: queries against existing full-text indexes fail after the upgrade until the indexes are rebuilt.

The migration component in SQL Server Management Studio 21 or later produces an upgrade assessment for the target you choose. On the existing server, this query shows which deprecated features have been counted in use:

SELECT * FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%SQL%Deprecated Features%';

7. Rehearse on a copy

Build a test server with the target versions of Windows Server and SQL Server.
Restore the latest production backup. Time the backup, copy and restore: together they are your downtime.
Recreate everything on the list from step 5.
Point a test copy of the application at it and run the work the business depends on, including every scheduled job and interface.
Write each fix into the runbook, and repeat until a run goes through without a surprise.

8. Cut over, with a way back

Stop the application and disable the Agent jobs on the old server, so that nothing changes the data.
Take the final backup, or the last log backup, and restore it on the new server.
Check logins, jobs and row counts on the important tables.
Point the applications at the new server by changing connection strings or a DNS name.
Have users run the agreed checks, then take a full backup on the new server.

An upgraded database cannot go back: SQL Server will not restore a backup onto an earlier version. The rollback plan is therefore the old server, left exactly as it was at step 1. Rolling back means pointing the applications at it again and re-entering anything keyed into the new server since. Agree beforehand the point after which problems are fixed on the new server instead, and who decides.

9. Raise the compatibility level later

Do this as a separate change, following Microsoft’s recommended workflow.

Turn on Query Store, which records each query, the plan used and how it performed. It is off by default in SQL Server 2016, so check.
Let it record a full business cycle, including a month-end, at level 130.
Raise the level to 160, or 170 on SQL Server 2025.
Compare, using the Regressed Queries report in Management Studio. Where a query has slowed you can force the earlier plan, and if that fails the level can be set back.

ALTER DATABASE [YourDatabase] SET QUERY_STORE = ON;
ALTER DATABASE [YourDatabase] SET COMPATIBILITY_LEVEL = 160;

What usually goes wrong

A login or an Agent job is missed, and surfaces only at month-end.
The compatibility level is raised on cutover day, so nobody can tell which change slowed a report.
The rollback plan assumes the new backup can be restored on the old server.
Reporting Services is assumed to come across with the database engine.

When to get help

If the upgrade cannot be tested in time, Microsoft sells Extended Security Updates for SQL Server 2016 until 17 July 2029. Its documentation says they cover only fixes rated Critical, are released as needed and require the server to be connected to Azure Arc or hosted in Azure. Treat them as a stopgap while the upgrade is prepared.

Get help if nobody can say what connects to the database, or if the database is large and the business cannot accept much downtime. If the database is already slow, deal with that in the same piece of work: see database performance. Where the inventory is the missing piece, our fixed-price code audit produces it.