SQL Server 2016 End of Support: Upgrade Safely in 2026

DBA PARK may earn a commission from purchases through links in this article, at no extra cost to you.

SQL Server 2016 reached the end of extended support on July 14, 2026. A server can continue to run, but normal security servicing and technical support no longer continue under the standard lifecycle. The practical choices are to upgrade, migrate to Azure, or use Extended Security Updates (ESU) as a temporary bridge.

This guide turns those choices into an actionable migration plan. It emphasizes side-by-side migration because it provides a clear fallback, but the correct design depends on downtime, application certification, high availability, licensing, and operating-system constraints.

What End of Support Changes

End of support is not an automatic shutdown. It changes the risk and support position:

Standard servicing and support for SQL Server 2016 have ended.
Newly discovered security issues might not be covered without ESU.
New client drivers, operating systems, backup products, and security requirements may stop being tested against SQL Server 2016.
Waiting increases the chance that the database, operating system, application, and driver all need to change in one project.

Microsoft lists three broad paths: upgrade to a supported SQL Server release, migrate to Azure SQL Managed Instance or SQL Server on Azure VM, or purchase ESU for an eligible deployment. SQL Server 2016 ESU can provide critical security updates for up to three additional years, but it does not add features or normal non-security fixes.

Choose the Migration Path

Option	Best fit	Main advantage	Main caution
Side-by-side SQL Server 2025	Teams that want on-premises control and a clean rollback boundary	Old server remains available during validation	Requires additional infrastructure and a planned cutover
In-place upgrade	Simple, well-tested instances with limited infrastructure options	Fewer server and connection changes	Rollback is harder; OS and feature prerequisites can complicate recovery
Azure SQL Managed Instance	Applications compatible with a managed SQL Server-like platform	Managed patching, backups, and high availability	Feature, networking, latency, and cost validation are mandatory
SQL Server on Azure VM	Lift-and-shift workloads needing instance-level compatibility	Familiar SQL Server administration model	You still own much of the instance and OS operation
ESU bridge	Systems that cannot migrate before the deadline	Buys limited time for critical security coverage	Not a modernization plan; normal fixes and new features are not included

Inventory the Existing Instance

Start with evidence. Do not begin with Setup.exe.

SELECT
    SERVERPROPERTY('MachineName') AS machine_name,
    SERVERPROPERTY('ServerName') AS server_name,
    SERVERPROPERTY('InstanceName') AS instance_name,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('ProductVersion') AS product_version,
    SERVERPROPERTY('ProductLevel') AS product_level,
    SERVERPROPERTY('ProductUpdateLevel') AS update_level;

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

Record at least the following:

Edition, build, collation, service accounts, and trace flags.
Database sizes, recovery models, compatibility levels, and encryption state.
SQL Agent jobs, operators, alerts, credentials, proxies, linked servers, and Database Mail.
Logins, server roles, certificates, keys, endpoints, and SPNs.
Availability Groups, replication, CDC, SSIS, SSRS, Full-Text Search, CLR, and Service Broker.
Backup products, monitoring agents, antivirus exclusions, and application drivers.
Peak workload, maintenance windows, RPO, RTO, and acceptable rollback time.

The inventory becomes both the migration checklist and the post-migration comparison.

Validate Backups Before the Migration

A backup job reporting success is not the same as a proven recovery path. Before cutover:

Confirm the full, differential, and log backup chain.
Restore representative databases to the target environment.
Run integrity checks appropriate for the environment.
Measure restore duration against the recovery objective.
Verify encryption certificates and keys are backed up separately.
Document the final tail-log or last-log-backup procedure.

Keep an independent rollback plan. A database upgraded to a newer engine cannot simply be backed up and restored to SQL Server 2016.

Use Compatibility Level as a Controlled Boundary

SQL Server 2025 uses database compatibility level 170 for its newest query-processor behavior. Restoring or attaching a supported database does not mean that you must immediately enable level 170. Separating the engine migration from the compatibility-level change reduces the number of variables in the outage window.

A safe performance workflow is:

Enable and size Query Store before the migration.
Capture a representative baseline on SQL Server 2016.
Migrate the database while initially retaining the existing compatibility level.
Validate application behavior on the new engine.
Change compatibility level in a separate, reversible test.
Use Query Store to find regressed queries and compare plans.
Mitigate urgent regressions with a validated plan or compatibility option while investigating the root cause.

See how to read SQL Server execution plans and the essential DMV monitoring guide before performance testing.

Side-by-Side Migration Runbook

1. Build the target

Choose a supported Windows and SQL Server combination.
Patch SQL Server to the approved servicing level.
Match required collation, network, storage, and service-account design.
Pre-create firewall, DNS, certificate, SPN, and monitoring requirements.

2. Migrate server-level objects

Move logins with SIDs preserved, then jobs, credentials, linked servers, operators, alerts, certificates, endpoints, and other instance objects. Do not copy objects blindly: remove obsolete items and validate secrets through an approved process.

3. Seed and synchronize data

Choose backup/restore, log shipping, an Availability Group, replication, or another supported method based on downtime and features. Record every LSN boundary and restore option when a log chain is involved.

4. Test the application

Connection and TLS validation with every driver family.
Authentication, permissions, and default databases.
Critical read/write transactions and scheduled jobs.
Backup, restore, CHECKDB, monitoring, and alerting.
Peak-like performance with Query Store and waits captured.
HA/DR failover and recovery, if applicable.

5. Cut over

Freeze application writes.
Complete the final synchronization or log restore.
Validate database state and row/transaction checkpoints.
Change the controlled connection endpoint.
Run a pre-agreed smoke test.
Monitor errors, waits, blocking, CPU, I/O, and business transactions.

6. Keep rollback explicit

Define rollback triggers before the outage: failed critical transaction, data divergence, unacceptable latency, security/authentication failure, or inability to meet RPO/RTO. Once writes occur only on the new server, rollback requires a data-reconciliation plan; it is not just a DNS reversal.

Common Migration Mistakes

Changing engine version, compatibility level, drivers, and application code in the same test.
Forgetting SQL Agent jobs, linked-server security, credentials, certificates, or SPNs.
Testing only successful connections instead of failover and recovery.
Assuming more CPU or memory will fix a changed query plan.
Keeping SQL Server 2016 indefinitely because ESU exists.
Retiring the old environment before the rollback and retention period ends.

Summary

SQL Server 2016 end of support is a risk-management event, not only a version upgrade. Use ESU only as a time-limited bridge. For most complex systems, a side-by-side migration provides the clearest validation and rollback boundary. Preserve the current compatibility level during the engine move, capture Query Store data, and enable level 170 as a separate controlled change.

Continue learning: To rehearse the core DBA tasks before a migration, browse Udemy and search for SQL Server administration courses with exercises on backup and restore, security, and database maintenance. For hands-on practice with SQL Server queries and database fundamentals, explore DataCamp.