Managed IT services

SQL Server 2016 is out of support: risks and migration options

By the Montreal IT team

Extended support for SQL Server 2016 ended on July 14, 2026.

A database does not stop working because a lifecycle date passes. The risk is quieter: the platform is no longer receiving the normal level of security updates, fixes and Microsoft support.

For an SMB, SQL Server is rarely visible to users. It sits behind accounting software, business management systems, production tools, client records, property systems or custom integrations. That invisibility is one reason migrations are delayed.

The first question is not “Which version should we install?” It is “Which applications and data actually depend on this instance?”

SQL Server 2016 may be installed in more places than expected

A business can be using SQL Server 2016 without having a clear inventory.

It may be installed:

  • on a dedicated Windows server;
  • on the same server as the application;
  • in a virtual machine;
  • on an old workstation acting as a server;
  • as SQL Server Express bundled with software;
  • in multiple branches;
  • in a forgotten test environment;
  • as a dependency of backup, monitoring or management software.

The inventory needs to cover database engines, named instances, attached databases, services and applications that connect to them.

What to inventory

For each SQL Server 2016 instance, record:

  • edition: Express, Standard, Enterprise or other;
  • exact build and patch level;
  • host operating system;
  • physical or virtual server;
  • databases;
  • size and growth;
  • authentication methods;
  • service accounts;
  • SQL Agent jobs;
  • linked servers;
  • reports, imports and exports;
  • client applications;
  • responsible vendors;
  • licensing method;
  • backups and most recent restore test;
  • availability and downtime requirements.

Look for inactive databases as well. An “unused” database may be the only remaining copy of history the business still needs.

Application dependencies are the real risk

A SQL migration is not only a database operation.

The application may depend on:

  • a specific engine release;
  • an older driver;
  • a particular compatibility mode;
  • a SQL account stored in a configuration file;
  • a custom stored procedure;
  • a scheduled job;
  • a local file path;
  • an Excel, Access or Windows service integration;
  • a vendor-controlled upgrade procedure.

Before changing the platform, obtain written application requirements from the vendor. A technically successful database migration can still leave the application unsupported.

Option 1: migrate to a supported release

The durable solution is usually to move databases to a supported SQL Server release or another data platform supported by the application.

The project should include:

1. vendor compatibility confirmation; 2. inventory of SQL features in use; 3. backup and restore testing; 4. installation of the new platform; 5. copy or restore into a test environment; 6. application validation; 7. performance testing; 8. cutover plan; 9. documented rollback; 10. controlled retirement of the old instance.

The newest version is not automatically the correct target. It must be supported by the application, operating system and chosen licensing model.

Option 2: use ESU as a temporary bridge

Microsoft offers Extended Security Updates for SQL Server 2016 for a limited period.

Under the published lifecycle, ESU Year 1 follows the end of extended support and runs through July 13, 2027. Additional years are scheduled through 2029 for eligible organizations.

ESU is a transition measure. It covers security updates defined by Microsoft, but does not provide:

  • new features;
  • customer-requested non-security fixes;
  • design changes;
  • a full replacement for normal support.

An organization choosing ESU should also have a migration date, project owner and budget. Without those, the extra cost simply moves the deadline.

Option 3: retire or replace the application

Some databases remain only because an old application has never been reassessed.

It may be more practical to:

  • replace the software with a current release;
  • migrate to SaaS;
  • export historical data;
  • retain a read-only copy in a controlled environment;
  • retire the application completely.

That decision belongs with business owners as well as IT. A technically active database is not necessarily a workload that still provides value.

A database backup is not enough

A SQL backup must be restored and validated.

Testing should confirm:

  • the backup file is readable;
  • it contains the expected recovery point;
  • it can be restored on the target platform;
  • accounts, users and permissions are understood;
  • jobs and configuration outside the database are documented;
  • the application can connect;
  • critical data is coherent;
  • restore time is acceptable.

A restored database without its identities, keys, jobs, links or associated files may still be unusable.

See our guide to restore testing for a broader recovery checklist.

Avoid emergency migration

A rushed migration increases the chance of:

  • an underestimated maintenance window;
  • incomplete backup;
  • missed secondary instance;
  • lost scheduled jobs;
  • driver problems;
  • licensing mistakes;
  • unexpected performance issues;
  • unusable rollback;
  • excessive reliance on one person.

The best time to test is while the old system is still working.

A focused review can clarify the decision

A managed IT environment review can identify SQL Server 2016 instances, dependent applications, backup gaps and realistic options.

To prepare, gather:

  • server name;
  • application name;
  • vendor details;
  • backup reports;
  • possible maintenance windows;
  • licensing constraints;
  • people who use the data;
  • retention requirements.

Contact Montreal IT to define the scope and migration plan.

Keep exploring