SQL Server 2016 reaches end of extended support in July 2026. SQL Server 2017 follows in October 2027. After that, there are no more security updates or Microsoft Support.
That sounds like plenty of time. In practice, it isn’t. Database upgrades and migrations have a habit of turning into ‘we should have started months ago’ projects, because you only discover the awkward bits once you inventory, test, and involve the people who own the apps.
What "end of support" means
Microsoft supports each SQL Server release for at least ten years: five years of mainstream support (features + fixes + security) and five years of extended support (security fixes only).
Your SQL Server instances won’t suddenly stop working, but once you hit the end date, the updates will stop. There will be no security patches for new vulnerabilities and no hotfixes. Are your critical databases offline and you need Microsoft support? Sorry, you’re out of luck!
Why it matters (beyond security)
Security is the headline risk, but it’s rarely the only pain point.
Compliance teams don’t love unsupported software. If you handle personal data (UK GDPR) or operate in regulated sectors, an out-of-support database can become an audit finding, or make an incident review a lot harder.
Then there’s the slow squeeze from third-party vendors. Over time, app suppliers stop certifying older SQL Server versions. That’s when ‘we’ll do it later’ turns into broken upgrades, unsupported integrations, and last-minute firefighting.
Your options
There isn’t one ‘best’ route. The right answer depends on where your databases run today, what depends on them, and how much change you can realistically absorb.
1) Extended Security Updates
Microsoft’s Extended Security Updates (ESU) can provide critical security patches for a limited period after end of support (typically up to three years). It can be useful if you need breathing room, but it’s paid, time-limited, and it doesn’t remove the underlying risk of staying on an out-of-date platform.
2) In-place upgrade
An in‑place upgrade updates an existing SQL Server instance to a newer version on the same server, replacing the binaries while keeping the same server, configuration, and databases. It’s quicker and simpler than migrating to new hardware, but it requires downtime and offers limited rollback options. For those reasons, it’s rarely the preferred approach.
3) Move to new hardware (side-by-side)
A side-by-side upgrade involves deploying a new SQL Server instance on new hardware (or a new virtual machine) and moving the existing databases and server configuration across with minimal change.
This approach reduces risk by leaving the original server untouched, allows testing on the new platform before cutover, and provides a straightforward rollback if needed. While it typically requires more planning and temporary duplication of infrastructure, it is often preferred for production systems where stability and recovery options are critical.
4) Cloud migration (PaaS or IaaS)
Migrating SQL Server to IaaS or PaaS is the most fundamental change of all, shifting workloads away from traditional on‑premises servers and into a cloud platform such as Azure virtual machines or a fully managed database service.
This can bring long‑term benefits around scalability, resilience, and reduced day‑to‑day operational effort, but it also introduces new considerations around architecture, cost control, security boundaries, and application compatibility.
As a result, it is usually the most disruptive option and not one taken lightly. However, a major SQL Server version upgrade is often the point at which organisations step back and assess whether simply upgrading the existing platform is enough, or whether it is the right time to explore a broader move to the cloud as part of a longer‑term strategy.
When should you start
Now. Even if you’re thinking “we’re on SQL Server 2017, we’ve got ages”. The earlier you start, the more options you have and the less likely you are to end up paying for urgency.
A sensible plan usually looks like this:
- Inventory every instance and database (including the ones no one ‘owns’).
- Map dependencies (apps, reports, integrations, SQL Agent jobs, linked servers).
- Check compatibility and deprecated features.
- Choose an approach (in-place, side-by-side, or cloud) and build a test environment.
- Rehearse the cutover and rollback, then schedule the real thing.
Where we come in
If you’re running SQL Server 2016 or 2017, we can help you understand what’s in your environment, what it depends on, and the lowest‑risk path to a supported platform. That might be a focused audit and upgrade plan, or full end‑to‑end delivery, depending on what you need.
If you want a clear picture of where things stand and what needs to happen before support deadlines arrive, please get in touch.
