SQL Server 2016 End of Support: Your Options and How to Upgrade Safely

SQL Server 2016 reached the end of extended support on July 14, 2026. The servers did not stop working that day, and that is exactly the problem: nothing breaks, so the decision keeps getting postponed. Meanwhile there are no more security fixes for new vulnerabilities, Microsoft support will not open a case for you, and every month the eventual upgrade becomes a larger jump.

This article covers the real options you have, how to choose between them, and the mistakes we see most often in the field when teams finally move off SQL Server 2016.

What End of Support Actually Means

After July 14, 2026, Microsoft no longer releases security updates for SQL Server 2016 unless you pay for Extended Security Updates (ESU). In practice:

• No security fixes. Newly discovered vulnerabilities stay open on every unprotected instance.
• No support cases. Even with a support plan, Microsoft will not open a case for SQL Server 2016 unless the instance is covered by ESU.
• Compliance findings. Auditors, KVKK and GDPR assessments and sector regulators treat unsupported software as a finding. “It still works” is not an acceptable answer in an audit report.
• Ecosystem drift. New drivers, tools and application versions are tested against current versions. Older client libraries and operating systems age out alongside the database engine.

Your Options

ESU is a bridge, not a destination. It buys time to do the upgrade properly, but it does not fix anything else that ages with the platform. If you take ESU, set the target date for the real upgrade on the same day you sign up.

For the choice between SQL Server 2022 and 2025, and between editions, see our version comparison. If licensing is part of the decision, our licensing guide covers core and CAL models and current prices.

In-Place or Side-by-Side?

SQL Server 2025 supports an in-place upgrade from SQL Server 2016 SP3 or later. That does not mean it is the right choice. Two facts usually decide it:

• The operating system. Many SQL Server 2016 instances still run on Windows Server 2012 R2 or 2016. SQL Server 2025 requires a newer Windows Server, so the server has to change anyway.
• The way back. An in-place upgrade replaces the binaries and upgrades every database on the instance. If the application fails afterwards, there is no “downgrade” button.

A side-by-side migration builds the new version on a new server, moves the databases with backup and restore (or log shipping for a short cutover) and leaves the old server untouched until the new one is proven. It costs a second server for a few weeks and buys you the one thing an in-place upgrade cannot: a working system to go back to. The detailed steps, upgrade paths and breaking changes are in our SQL Server 2025 upgrade guide.

The Mistakes We See Most Often

Most upgrade problems we are called in for have nothing to do with SQL Server itself. They come from steps that were skipped because “it is just a version upgrade”.

1. Nobody checked whether the application supports the new engine

The database upgrade is tested, the application is not. Then on Monday morning a report times out, an ERP module throws an error, or an old driver refuses to connect. Before you choose a target version:

• Get the application vendor’s supported version list in writing. Many ERP and packaged applications certify specific SQL Server versions.
• Find the deprecated and discontinued features the application actually uses. Our guide to finding deprecated features in use shows how to capture them from a running instance.
• Check the client drivers. Newer drivers encrypt connections by default, and an application server with old certificates or old drivers can stop connecting after the upgrade. Linked servers are affected too; see the linked server guide for the SQL Server 2025 change.
• Keep databases at their current compatibility level during the upgrade and raise it later, deliberately. Our compatibility level guide explains what changes and how to raise it safely.

2. No dry run before the real cutover

A dry run is a full rehearsal on a copy of production: restore last night’s backups on a test server running the target version, point a test copy of the application at it and run real workloads. It answers questions that no checklist can:

• Do the critical screens, reports and batch jobs work and finish in a reasonable time?
• Which queries got slower? Enable Query Store on the test copy and compare plans and durations against the old server.
• How long does the cutover really take? Backup, copy, restore and verification on real data sizes give you the downtime window to promise the business.
• Do Agent jobs, SSIS packages, linked servers, logins and scheduled tasks outside SQL Server still work?

Write the dry run down step by step. The real cutover should repeat a procedure that has already worked once, not improvise one.

3. No ticket back

This is the mistake that turns a bad night into a lost week. A database backup taken on SQL Server 2025 cannot be restored on SQL Server 2016, and a database that has been upgraded cannot be downgraded. Once users write data on the new version, the old version cannot simply take over again.

A realistic rollback plan has three parts:

• The old system stays intact. In a side-by-side migration, keep the old server untouched (and its databases restorable) until the new one has run through at least one full business cycle, such as a month-end close.
• A go/no-go point. Agree on a moment, for example the end of the validation window, before users write production data. Up to that point, going back means pointing the application at the old server again. After it, going back means losing or re-entering data, or a separate data synchronisation plan.
• A tested procedure. Rolling back is part of the dry run. If you have never switched the connection strings back, you do not have a rollback plan.

4. In-place upgrade with no snapshot and no system database backups

Teams that choose an in-place upgrade often try it directly on the production machine with no safety net. When setup fails halfway, or the upgraded instance behaves differently, there is nothing to return to. Before an in-place upgrade:

• Take full backups of all user databases and verify them. Our backup plan guide covers verification and restore tests.
• Back up the system databases: master, msdb and model. Logins, Agent jobs, linked servers and server configuration live there. Note that system database backups can only be restored on the same version and build, so they are your way back to the old instance, not a way to move to the new one.
• Take a VM snapshot with the SQL Server services stopped, so the snapshot is consistent. A snapshot of a running database server is crash-consistent at best.
• Record the configuration: sp_configure values, trace flags, startup parameters, service accounts, file locations and the exact build number.
• Check the installer prerequisites, including pending restarts. Microsoft lists a known issue where an upgrade from SQL Server 2016 can fail on the Visual C++ Redistributable; repairing it and rerunning setup resolves it.

-- Before an in-place upgrade: back up the system databases and record the build
BACKUP DATABASE master TO DISK = N'D:\PreUpgrade\master.bak' WITH CHECKSUM, INIT;
BACKUP DATABASE msdb   TO DISK = N'D:\PreUpgrade\msdb.bak'   WITH CHECKSUM, INIT;
BACKUP DATABASE model  TO DISK = N'D:\PreUpgrade\model.bak'  WITH CHECKSUM, INIT;

SELECT SERVERPROPERTY('ProductVersion') AS build,
       SERVERPROPERTY('ProductLevel')   AS service_pack,
       SERVERPROPERTY('Edition')        AS edition;

A Practical Order of Work

1. Inventory: every 2016 instance, its edition, OS version, databases, sizes, applications and owners.
2. Decide per instance: ESU as a bridge, side-by-side migration or in-place upgrade, and the target version.
3. Application compatibility: vendor support, deprecated features, drivers, linked servers.
4. Build the target following an installation checklist, not the setup defaults.
5. Dry run with real data, a performance comparison and a timed cutover.
6. Write the rollback plan and agree on the go/no-go point.
7. Cutover following the rehearsed procedure.
8. Stabilise: watch performance and errors through a full business cycle, then raise compatibility levels one database at a time.
9. Decommission the old server only after that.

How Aryasoft Does It

Aryasoft’s senior DBA team starts every SQL Server 2016 project with an inventory and an application compatibility review, then rehearses the move on a copy of production before anything is touched. Every cutover has a written rollback plan and an agreed go/no-go point, and the old system stays available until the new one has proven itself in daily use.