SQL Server 2025 Upgrade Guide: Upgrade Paths, Breaking Changes and a Step-by-Step Plan

Upgrading SQL Server is rarely difficult because of the setup wizard. It becomes difficult because of everything around the database engine: the applications and drivers that connect to it, the server-level objects that live outside the user databases, the query plans that change under a new optimizer, the high availability topology and, above all, the fact that an upgraded database can’t be taken back to an older version. Most failed upgrades fail on one of these, not on the installation itself.

This guide covers which versions can move to SQL Server 2025 and how, the changes in SQL Server 2025 that most often break existing environments, how to choose between an in-place upgrade and a side-by-side migration, and a step-by-step plan from assessment to post-upgrade tuning.

Quick Decision Table: Which Upgrade Route Fits?

Tested-Version Notes

Last verified: 19 October 2026. Every claim below was read on Microsoft Learn on this date. T-SQL tested on SQL Server 2025 (build 17.0.4055.5).

Where Does Your Version Stand?

The urgency of an upgrade depends largely on where the current version sits in Microsoft’s support lifecycle. Once extended support ends, a version receives no security fixes unless you buy Extended Security Updates (ESU), which cover only critical security updates for up to three years.

Microsoft supports an in-place upgrade to SQL Server 2025 from SQL Server 2014 SP3 or later, 2016 SP3 or later, 2017, 2019 and 2022. Older versions can’t be upgraded in place, but their databases can be migrated: any database with compatibility level 90 or higher can be restored or attached to SQL Server 2025, and level 90 databases are raised to 100 automatically.

To find out exactly what you’re running, check the version, edition and build on every instance:

SELECT
    SERVERPROPERTY('ServerName')     AS server_name,
    SERVERPROPERTY('ProductVersion') AS build,
    SERVERPROPERTY('ProductLevel')   AS service_pack,
    SERVERPROPERTY('ProductUpdateLevel') AS cumulative_update,
    SERVERPROPERTY('Edition')        AS edition;

SELECT name, compatibility_level, recovery_model_desc, state_desc
FROM sys.databases
ORDER BY name;

What Changes in SQL Server 2025 That Can Break an Upgrade

Every release has its own list of removed features and changed defaults. These are the ones in SQL Server 2025 that most often surprise teams during an upgrade:

Beyond these, check how much your applications still use deprecated features. SQL Server counts every use since the instance started:

SELECT instance_name AS deprecated_feature, cntr_value AS usage_count
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Deprecated Features%'
  AND cntr_value > 0
ORDER BY cntr_value DESC;

For a complete assessment of breaking changes, behavior changes and deprecated features, Microsoft now offers the SQL Server migration component in SQL Server Management Studio.

In-Place Upgrade or Side-by-Side Migration?

For production systems, we generally recommend side-by-side migration. It costs a second server for the duration of the project, but it turns rollback into a decision rather than a reconstruction, and it lets you renew the operating system and right-size the hardware at the same time.

Moving the Data with Minimal Downtime

• Backup and restore: the simplest method; downtime equals the time to take and restore a final backup. Suitable for small databases or generous maintenance windows.
• Log shipping: restore a full backup in advance, keep applying log backups, and at cutover apply only the last one. Supported from SQL Server 2008 SP3 and 2008 R2 SP2 as the source. It reduces downtime to minutes and works on Standard edition.
• Availability groups: for environments already on availability groups, add a SQL Server 2025 replica, let it synchronize, then fail over. Once the new version becomes primary, older replicas can’t take over again, so this step is the point of no return.

Objects That Live Outside the User Databases

In a side-by-side migration, moving the user databases is the easy part. A surprising amount of what makes an instance work lives in master, msdb and the server itself, and none of it travels with a database backup. Inventory and script everything below before the migration, and check it off on the new server:

Most of these objects can be scripted with SSMS or T-SQL, and open-source PowerShell tooling such as the dbatools module can copy many of them in one pass. Whatever you use, compare the object counts on both servers after cutover rather than assuming the copy was complete.

If You Build a New Server: Infrastructure Checks

A side-by-side migration means a new machine, and a new machine fails in ways that have nothing to do with SQL Server. Check these before the cutover weekend, not during it.

Active Directory, OU and Group Policy

• Create the new computer object in the same OU as the old database servers, or in the OU your database servers are meant to be in, so the same Group Policies apply.
• Confirm the policies have actually been applied to the new machine (gpresult /r or gpresult /h report.html): security baseline, firewall rules, local administrators, audit policy, update policy.
• Check the user rights the SQL Server service account needs, often granted by GPO: Perform volume maintenance tasks for instant file initialization and Lock pages in memory where it’s used. A GPO that applies to the old OU but not the new one silently removes them.
• Register SPNs for the new server name and service account so Kerberos keeps working, and recreate any delegation settings that linked servers or reporting depend on.

Network permissions

• Firewall rules from every application server, reporting tool and ETL server to the new server: SQL port, listener port and, for availability groups, the endpoint port (5022 by default).
• Access from the new server to everything it calls: backup shares (with write permission for the service account), linked server targets, SMTP relay, file shares used by jobs and SSIS, monitoring and backup software.
• DNS: aliases or CNAMEs that applications use, and their TTL, so the cutover is a DNS change rather than a configuration change in every application.
• Network segmentation and VLAN membership matching the old server, including any rules that keep the database server off the internet.

Comparable compute power

• Make sure the new server has at least comparable compute power to the old one: core count, per-core clock speed, memory and storage latency. A server with more cores but a lower clock speed can make single-threaded work, such as many OLTP queries and serial batch jobs, slower.
• Check the edition’s core limit and the VM’s socket layout, so SQL Server can use every core you give it; see how many CPU cores SQL Server can use.
• Set the Windows power plan to High performance and check the BIOS or hypervisor power profile.
• Compare the baseline from the old server (CPU, wait statistics, per-file I/O latency, durations of key jobs and reports) with the same workload on the new server before cutover.

Compatibility Level and Query Performance

Upgrading the engine and raising a database’s compatibility level are two separate decisions. A restored or upgraded database keeps its compatibility level, so it keeps most of the old query optimizer behavior even on the new engine. That’s deliberate: it lets you separate the risk of the upgrade from the risk of plan changes.

A controlled sequence looks like this:

1. Before the upgrade, capture a performance baseline: CPU, waits, duration and reads of the most important queries.
2. Upgrade with the existing compatibility level and confirm the applications work.
3. Make sure Query Store is enabled and collect a representative period of workload.
4. Raise the compatibility level, preferably one database at a time.
5. Use Query Store to compare plans and force the previous plan for any query that regresses, then fix the underlying cause.

ALTER DATABASE [SalesDB] SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);

-- After collecting a baseline on the old compatibility level:
ALTER DATABASE [SalesDB] SET COMPATIBILITY_LEVEL = 170;  -- SQL Server 2025

We explain how compatibility levels influence the optimizer in our compatibility level article.

Upgrading Always On and Failover Cluster Environments

For availability groups and failover cluster instances, the order of operations matters more than the setup itself. In an availability group, upgrade the secondary replicas first, fail over to an upgraded synchronous secondary, then upgrade the former primary. Remove automatic failover while replicas run different versions, and confirm synchronization before every failover. The step-by-step procedure is the same rolling approach we describe in our Always On patching guide.

Official Behavior, Aryasoft Field Notes and Our Recommendation

A Step-by-Step Upgrade Plan

1. Inventory: instances, versions and builds, databases and compatibility levels, server-level objects, applications and their drivers.
2. Assessment: supported upgrade path, operating system, removed and deprecated features, third-party application support statements.
3. Method and target: in-place or side-by-side, target edition and sizing, data movement method.
4. Test environment: restore production databases on the target version and run application, integration and performance tests.
5. Cutover and rollback plan: a timed runbook, a go/no-go decision point and the conditions that trigger rollback.
6. Upgrade or migration according to the runbook.
7. Validation: applications, Agent jobs, integrations, security, backups and HA/DR.
8. Stabilization: monitor against the baseline, raise compatibility levels in a controlled way and tune regressions.

Common Mistakes

• Assuming a rollback is possible by restoring a backup on the old version.
• Migrating user databases but forgetting logins, jobs, linked servers or certificates.
• Upgrading without checking the operating system and driver changes.
• Raising the compatibility level on the same night as the upgrade, without a baseline.
• Treating availability groups and failover clusters like standalone instances.
• Starting the project weeks before support ends instead of months.
• Choosing a build with known critical issues on the target instead of a well-established cumulative update.

SQL Server Upgrade Checklist

• Have the current version, edition and build of every instance been identified?
• Is the source on a supported upgrade path, or does it require migration?
• Does the operating system meet SQL Server 2025’s requirements?
• Are DQS, MDS, Synapse Link, Purview policies or Web edition in use?
• Have the effects of the new driver encryption defaults on linked servers been tested?
• Do third-party vendors support the application on SQL Server 2025?
• Has every server-level object been inventoried and scripted?
• Is the new computer object in the right OU, and have the Group Policies and user rights been applied to it?
• Are firewall rules, share permissions, SMTP relay, SPNs and DNS aliases in place for the new server?
• Does the new server have comparable compute power, including per-core clock speed and storage latency?
• Are TDE and backup encryption certificates backed up and tested on the target?
• Has a performance baseline been captured and is Query Store enabled?
• Is there a timed cutover runbook with a clear go/no-go point?
• Does the rollback plan keep the old environment intact?
• Has the HA/DR topology been tested after the upgrade?

Sources (Microsoft Learn)

Technical claims in this guide were checked against these primary sources on 19 October 2026. Microsoft can change documentation at any time, so re-check version-specific details before a production change.

• Supported version and edition upgrades (SQL Server 2025)
• Choose a Database Engine upgrade method
• Plan and test the Database Engine upgrade plan
• Hardware and software requirements for SQL Server 2025
• What’s new in SQL Server 2025
• Breaking changes to Database Engine features in SQL Server 2025
• Upgrade availability group replica instances
• ALTER DATABASE compatibility level
• RESTORE statements (Transact-SQL)
• SQL Server end of support options
• Extended Security Updates for SQL Server
• Microsoft Lifecycle: SQL Server 2016 (see also 2014, 2017, 2019, 2022, 2025)