SQL Server 2016 End of Support Options Assessment
A fixed-price, one-week, read-only assessment of every SQL Server 2016-and-older instance you run — up to ten instances for $2,450 — that ends with a decision per instance, not a slide deck: Extended Security Updates as a dated bridge, an in-place upgrade to SQL Server 2022 or 2025, SQL Server on an Azure VM, Azure SQL Managed Instance, Azure SQL Database, or retirement. Each path comes with the date it has to be done by, what it costs in licensing and Microsoft charges, and what blocks it. SQL Server 2016 reached the end of extended support on 14 July 2026 per Microsoft's product lifecycle; its Extended Security Updates run to 17 July 2029 and are a paid, per-core Microsoft charge even on Azure. The report is yours to act on with us, with your own team, or with someone else.
What this engagement is
SQL Server 2016 reached the end of extended support on 14 July 2026, per Microsoft's product lifecycle. From that date Microsoft ships no security updates for it unless you pay for Extended Security Updates — and the 2016 ESUs are not the ones you may remember from 2012 and 2014. They are not free for running on an Azure VM. They are licensed per core with a four-core minimum per virtual machine. They cover Standard and Enterprise editions only. And the last one ships in July 2029. If you also run SQL Server 2014, its ESUs end on 8 July 2027; SQL Server 2012's have ended already. Every one of those instances is now a decision somebody has to make, and in an estate of a dozen or a hundred instances the decision is not the same for each. That is the problem this assessment solves. It is not a migration assessment with a preferred destination. It is an estate-level options assessment that inventories every SQL Server 2016-and-older instance you have, works out what each one actually does and who depends on it, checks what your licensing position allows, and assigns each instance one of six paths with the date it has to be complete by and what it will cost: 1. **ESU bridge** — for instances a vendor has not yet certified on a newer version, or that are being retired inside the ESU window anyway. Enrolled through Azure Arc and billed by Microsoft per core to your Azure subscription, or bought through volume licensing with Software Assurance. 2. **In-place upgrade to SQL Server 2022 or 2025** — for healthy instances on a supportable host. Microsoft supports a direct upgrade from SQL Server 2016 SP3 or later to SQL Server 2025, but SQL Server 2025 requires Windows Server 2019 or later — so a 2016 instance sitting on Windows Server 2016, itself out of extended support on 12 January 2027, either goes to SQL Server 2022 on that host or gets a new host first. The assessment states which. 3. **SQL Server on an Azure VM** — for instances that need the full engine surface (SQL Agent, SSIS, SSRS, CLR, FILESTREAM, cross-database queries) but should leave the datacenter. 4. **Azure SQL Managed Instance** — for instances that can leave the version treadmill entirely and whose feature usage fits the platform. 5. **Azure SQL Database** — for single databases without instance-level dependencies; usually the cheapest to run and the most likely to need application changes. 6. **Retire** — the path nobody prices and everybody has candidates for: databases nothing has connected to in a year, reporting copies, abandoned test systems. Over five business days we collect read-only from every instance — version, edition, service pack and cumulative update, databases with sizes and compatibility levels, SQL Agent jobs, linked servers, replication, log shipping and availability groups, SSRS, SSIS and SSAS use, CLR, FILESTREAM and Service Broker, logins and connected applications — and we ask your application vendors one question per product: which SQL Server versions and Azure targets do you support today. We put that beside your licensing: core counts by edition, whether your licenses carry Software Assurance or are subscription licenses (which decides both ESU eligibility through volume licensing and Azure Hybrid Benefit), and what a true-up would look like on each path. What you get is a written roadmap: an instance-by-instance register with the path, the deadline and the cost for each; a cost model that puts the ESU years against the upgrade licensing and the indicative Azure running cost for the instances that would go there; a blocker list per instance; and a sequenced plan that says what to do this quarter, what can wait for the vendor, and what to switch off. For every path that is one of our fixed-price services, we quote it in writing from these findings. For instances headed to Azure where the sizing needs a deeper look, the report says so and hands off to the SQL Server to Azure Migration Assessment rather than guessing. The report is yours. Run it with your own DBAs, take it to another vendor, or use it to justify an ESU budget to your finance team — each is a legitimate outcome and the report is still worth having.
Success criteria
What you receive
How the work unfolds
Confirm the instance list — or agree that our read-only discovery script builds it — the application owners, the licensing records you can share, the vendor list, any target already decided, and the date driving the decision. Agree the read-only access and the collection window. We send the vendor support question the same day so the answers arrive inside the week.
Run read-only collection against every in-scope instance and its host: catalog views and DMVs for version, edition, databases, compatibility levels, features in use, jobs, linked servers, replication and availability-group state, logins and connections; host operating system version, cores and cluster membership. Where Azure Arc or Azure Migrate is already deployed we use its inventory rather than duplicating it. Nothing is installed on production and nothing is changed.
Reconcile your license entitlements and Software Assurance or subscription status against the cores actually in use, establish ESU eligibility by route and Azure Hybrid Benefit availability, and chase the vendor answers. This is the day the true-up exposure on each path becomes a number.
Evaluate each instance against the six paths using its dependency findings, host operating system, vendor answer and licensing position; build the cost model at Microsoft's published rates on the day; sequence the estate into waves against the lifecycle dates. Where an instance is genuinely a coin toss between two paths, the report says so and states what would settle it.
Deliver the written report and walk it through live for 60 minutes with the people who own the budget and the applications. Answer the 'what if we did X instead' questions on the call rather than in a follow-up. Issue fixed-price quotes for the paths that are our services.
Prerequisites
Who does what
IT Partner
- Provide and explain the read-only collection scripts, and run or supervise collection.
- Build the instance register, dependency findings and licensing position from the collected data and your entitlement records.
- Send the vendor support question, chase it during the week, and record the answers and the non-answers.
- Model the six paths per instance, build the cost model at Microsoft's published rates, and sequence the roadmap.
- Produce the written report, deliver the walkthrough, and issue fixed-price quotes for the paths that are our services.
- Request the least access the job needs and treat everything collected as confidential.
Your team
- Provide a named technical contact and an application-owner contact for the duration.
- Grant the read access described above, or run collection on our behalf.
- Share license entitlement and Software Assurance records, or introduce the people who hold them.
- Confirm the instance list and scope before collection starts.
- Introduce us to application vendors, or ask the support question yourself using our wording.
- Attend the Day 5 walkthrough with the people who own the budget decision.
What's not included
Limitations & technical notes
Frequently asked questions
SQL Server 2016 is already out of support. What actually changed on 14 July 2026?
Microsoft stopped shipping security updates for it, per Microsoft's product lifecycle. The instances keep running, but any vulnerability found from that date is patched only for organizations paying for Extended Security Updates. That matters in three places at once: your attack surface, your cyber-insurance questionnaire, and any audit that asks whether production systems are vendor-supported. The assessment tells you, per instance, which of those exposures you are carrying and the cheapest defensible way to close it.
How long do the ESUs last and what do they cost?
Microsoft offers SQL Server 2016 Extended Security Updates until 17 July 2029 — three years — covering security updates rated Critical by the Microsoft Security Response Center. They are licensed per core with a four-core minimum per virtual machine, for Standard and Enterprise editions only, and — unlike SQL Server 2012 and 2014 — they are not free for running on an Azure VM. You buy them either through Azure Arc on a pay-as-you-go basis, billed by Microsoft to your Azure subscription with no Software Assurance required, or through volume licensing with active Software Assurance. Microsoft publishes the rates; our cost model puts the year-by-year ESU figure for each instance beside the upgrade and Azure alternatives and states the date the rates were checked.
Can we just upgrade in place to SQL Server 2025?
Often, but not from every host. Microsoft supports a direct in-place upgrade from SQL Server 2016 SP3 or later (and from SQL Server 2014 SP3 or later) to SQL Server 2025, so the SQL side is usually fine once the service pack is on. The catch is the operating system: SQL Server 2025 requires Windows Server 2019 or later, and a large share of 2016 instances sit on Windows Server 2016 — itself out of extended support on 12 January 2027. On that host the in-place options are SQL Server 2022, which accepts Windows Server 2016, or a new host first. There is also a reporting question: SQL Server 2025 consolidates Reporting Services into Power BI Report Server, so an instance running SSRS needs its reports given a destination. The assessment states, per instance, which of those you are looking at and whether a side-by-side rebuild on a new server is the cheaper answer.
Our SQL Server 2016 runs on Windows Server 2016. Does that change the answer?
It usually does. You now have two clocks — SQL Server 2016 already out of support, Windows Server 2016 out on 12 January 2027 — and, if you bridge both with Extended Security Updates, two ESU bills (Windows Server 2016 ESU is likewise enrolled through Azure Arc). An in-place upgrade of the SQL engine alone leaves you on an operating system about to need its own bridge; upgrading both in place is possible but rarely the shortest path. For most such instances the assessment ends up recommending either a fresh host — on-premises or an Azure VM — with a current Windows Server and SQL Server, or a platform move to Managed Instance that ends both clocks at once. The report shows the cost of each so you can choose. Where the host estate is the bigger question, the Windows Server 2016 End of Support Assessment and Roadmap covers every server role, not just SQL.
Which instances should go to Azure SQL Managed Instance, and which to an Azure VM?
Managed Instance is the platform that ends the version treadmill while keeping most of the engine — SQL Agent, cross-database queries, linked servers to SQL sources, CLR — which is why it fits a large share of line-of-business estates. It does not fit everything: FILESTREAM and FileTable, some replication topologies, certain server-level configurations and applications that depend on an operating-system-level feature stay on an Azure VM. Azure SQL Database is for single databases with no instance-level dependencies and is usually the cheapest to run, but it is the target most likely to need application changes. The assessment scores each instance against all three from its actual feature usage rather than from a rule of thumb, and where the answer is Azure it states whether you can go straight to a migration quote or need the deeper sizing assessment first.
How is this different from the $950 SQL Server to Azure Migration Assessment?
Scope, depth and the question being asked. The SQL Server to Azure Migration Assessment takes up to three instances that are going to Azure and answers how: target, method, sizing, storage layout, measured connectivity, a performance baseline and a fixed migration quote with the cutover window in minutes. This assessment takes up to ten instances of any age and answers what: ESU, upgrade, Azure VM, Managed Instance, Azure SQL Database or retire — with dates, licensing and costs — across the whole estate. Many organizations need both: this one first to decide the map, the migration assessment for the instances it sends to Azure. If you have three instances or fewer and Azure is already decided, skip this page and book that one.
What about our SQL Server 2014 and 2012 instances?
They belong in the same register and the report covers them. SQL Server 2014 left extended support on 9 July 2024 and its ESUs end on 8 July 2027 — two years before 2016's — so a 2014 instance on ESU has less runway than you may think. SQL Server 2012's ESUs have already ended. Microsoft's supported in-place path to SQL Server 2025 starts at SQL Server 2014 SP3; 2012 and older need an intermediate upgrade or a migration rather than a direct step, and the report says which. If you tell us about 2008 and 2008 R2 instances we assess those too; the path for them is almost always migrate or retire, and the migration with a server upgrade exists for exactly that case.
Do you need sysadmin access, and will this touch production?
No and no. `VIEW SERVER STATE`, `VIEW ANY DEFINITION` and read access on the databases is enough. Collection runs against catalog views and DMVs, installs nothing, changes nothing, takes no locks on user data and can run during business hours. If policy does not allow external access at all, your staff run our scripts and return the output. Least access is how we work on every engagement, not a concession for this one.
We use SSRS, SSIS and SSAS on these servers. Does that complicate things?
It decides things, which is why the register captures all three. SSIS packages and SSAS models move with an in-place upgrade or to an Azure VM but need their own plan for Managed Instance or Azure SQL Database. SSRS is the sharp one: SQL Server 2025 consolidates Reporting Services into Power BI Report Server, so an SSRS 2016 estate cannot simply ride an upgrade. The report gives every report server a destination, and moving the reports is the SSRS to Power BI migration if you want us to do it.
What counts as an instance for the ten-instance limit?
One installed SQL Server instance — default or named — on one host. A server running two named instances is two; each availability-group replica or failover-cluster node with its own installation counts once; Express and Developer instances count because they still have to be assessed and given a path, even though they cannot be enrolled in ESU. Above ten we scope and quote the estate in writing before we start. Larger estates are the norm at the organizations this page is written for; the fee scales with the count, not with the urgency.
What does the licensing part actually cover?
Enough to price each path honestly. We reconcile the cores in use by edition against the entitlements you show us, establish whether the licenses carry Software Assurance or are subscription licenses — which decides ESU eligibility through volume licensing and Azure Hybrid Benefit on the Azure paths — and state the indicative true-up or new-license cost of each path per instance. It is not a compliance audit and not audit defence; if the reconciliation turns up a gap, the report says so and you decide what to do with the information. Choosing a licensing program is the separate Microsoft Volume Licensing consultation.
Will you just recommend moving everything to Azure?
No. Three of the six paths are not Azure, and the report states which alternatives were considered for every instance and why each was ruled out, so you can check the reasoning. Some instances should stay on ESU until a vendor certifies a newer version; some should be upgraded in place and left alone; some should be switched off. We publish separate fixed-price services for the Azure paths, the ESU enrollment and the in-place upgrade, so the recommendation does not change what we earn.
Do we have to use you for the execution?
No. The report is written to be actionable by your own DBAs or any competent SQL Server team, with the reasoning, the dates and the dependencies spelled out. If you do proceed with us, each path is a separate fixed-price engagement quoted from the report, and you pay after you approve delivery on each.
How long does it take, and when should we start?
Five business days from confirmed access — one calendar week in practice, with the vendor answers the usual reason a week stretches. Start now: the 2016 date has passed, so every week without a decision is a week of unpatched production or unbudgeted ESU. The ESU years run to July 2029; the assessment makes sure you buy only the years you need, for only the instances that need them.