Microsoft platform end-of-support dates that matter for .NET shops
This page tracks the Microsoft platform components most relevant to mid-market .NET shops and the dates they reach end of support. It is not comprehensive. Microsoft publishes the full lifecycle catalog at learn.microsoft.com/lifecycle ↗, which is the authoritative source for every product they ship.
What we publish here is the curated subset that matters operationally for the kind of organizations we work with: SQL Server, Windows Server, .NET, .NET Framework, and Visual Studio versions that mid-market teams are actually running in production. We exclude products that are already out of support, Azure-specific services, and anything outside the .NET stack.
Dates come directly from Microsoft's lifecycle pages. Commentary reflects what we see in the field, not what Microsoft says in its own marketing. Both have their place. This is the second one.
Out of supportDate has passed.
Ends soonDate is in 2026.
ApproachingDate is in 2027 or 2028.
Plan aheadDate is 2029 or later.
Forward anchorIn mainstream support; included as the reference point.
Bars span from today to each product's end-of-support date. Short bars mean an imminent date; long bars give more runway. Colors match the status badges above.
2027202820292030
SQL Server 2016
Jul 14, 2026
.NET 8 LTS
Nov 10, 2026
Windows Server 2016
Jan 12, 2027
.NET Framework 4.6.2
Jan 12, 2027
SQL Server 2017
Oct 12, 2027
Windows Server 2019
Jan 9, 2029
Visual Studio 2019
Apr 10, 2029
SQL Server 2019
Jan 8, 2030
SQL Server 2022 (still in mainstream support, and the landing point most legacy estates actually pick) is omitted from the chart; it is the reference point below (mainstream support to January 11, 2028; extended support to January 11, 2033). SQL Server 2025 (GA November 2025) is the newest on-premises release and is likewise omitted. .NET Framework 4.7 through 4.8.1 follow the underlying Windows OS lifecycle and have no standalone end date; see the entry below for the distinction.
SQL Server 2016
Ends soon
Extended support ends July 14, 2026.
This is the nearest deadline on the page. After July 14, 2026, no more security patches under the standard lifecycle. ESU (Extended Security Updates -- Microsoft's paid program to keep patching software past its end-of-support date) is available for three years, but it's a paid bridge: for SQL Server 2016 it is sold as a subscription (typically Azure Arc-enabled, billed for as long as you stay on it), priced as a large fraction of the license cost each year, and Microsoft has said the pricing structure is changing -- so validate current pricing with Microsoft or your licensing partner. The licensing arithmetic still points one way: three years of ESU spend rivals or exceeds the licenses an upgrade would have bought. The harder problem: SQL Server 2016 rarely runs alone. It usually sits under a .NET Framework app on Windows Server 2016. All three hit end of support within six months. Migrate one in isolation and you have a half-modernized environment that's worse to operate than the original.
If you're running this: You don't have time for a clean RFP cycle. Pick a path (in-place upgrade, Azure SQL MI, or rebuild the app tier at the same time) and start. ESU is a bridge, not a destination.
.NET 8 is on Microsoft's long-term support (LTS) track and reaches end of support in November 2026. That's a tighter runway than most teams have priced in. .NET 10 LTS (released November 2025) is the upgrade target, supported through November 2028. Moving 8 to 10 is a routine version bump for a healthy app: days to weeks. Don't confuse this with .NET Framework to modern .NET, which is months to years. The trap: teams on .NET 8 think they're "modern" and deprioritize the deadline because the codebase already crossed the harder bridge. The runway is now short enough that the assumption stops holding.
If you're running this: Start the .NET 10 upgrade now. The deadline is close and the calendar fills up fast with everyone making the same move.
The January 2027 date sounds comfortable until you look at what it's hosting. Typical mid-market deployment: SQL Server 2016 on Windows Server 2016 hosting an ASP.NET Framework app. All four (OS, SQL, IIS, and Framework) hit end of support inside a six-month window between July 2026 and January 2027. IIS 10 ships with Windows Server 2016 and has the same date. IIS doesn't have its own lifecycle. If your Framework app is hosted on IIS on Windows Server 2016, the IIS migration is the OS migration. Teams figure this out late.
If you're running this: Plan it as one coordinated migration across all four layers. Exception: teams that have already separated the database tier and can move it independently. Most haven't.
15 months behind 2016. Mainstream support ended October 2022, so 2017 has been security-only for three and a half years. No new features, no perf work, no non-security fixes. We see this version most often in shops that skipped 2016, landed on 2017, and now have the same conversation 15 months later, usually with a more tangled environment because they postponed.
If you're running this: Don't wait for the deadline to drive the plan. The shops migrating in panic mode in late 2027 will all be hitting the same partners and vendors at the same time.
4.6.2 ends January 12, 2027. 4.7 through 4.8.1 follow the underlying Windows OS lifecycle and have no standalone end date.
This is the entry that gets misread. Microsoft says 4.8.1 will ship with future Windows versions and will be "supported" indefinitely. That sounds like permission to stay. It isn't. "Supported" means critical security patches. No new features since 4.8.1 shipped August 2022. No perf work. No new APIs. No modern C# beyond what 4.8 supports. No cross-platform. No path to the AI integration patterns being built into modern .NET. All runtime and language innovation moved to modern .NET and Microsoft has been explicit it isn't coming back.
If your app uses Web Forms (the older Microsoft way of building web pages), the path forward is a rewrite. Web Forms doesn't exist in modern .NET. WCF server-side hosting (the older Microsoft technology for connecting applications to each other) isn't in modern .NET either -- CoreWCF, a Microsoft-supported open-source port, carries many services across without a rewrite, but which bindings survive has to be checked service by service. And some Windows-only integration libraries you've probably forgotten are in the project have no path at all. VB.NET still runs in modern .NET but is in maintenance mode with no new language features, so modernization is usually the right time to consider a C# rewrite alongside the platform move.
The mistake: treating "supported indefinitely" as "you have indefinite time." You have indefinite patches. You don't have indefinite time before the gap to current .NET makes the migration twice as expensive.
If you're running this: The support date is the wrong question. Ask how long the team can afford to be on a platform that isn't being improved. For most mid-market shops, the honest answer is shorter than the team thinks.
Extended support ends January 9, 2029. Mainstream ended January 9, 2024.
Same operational position as SQL Server 2019. Mainstream over for two years. Security updates only. Looks safe because the date is far. The platform is fine for now. The strategic question is whether to move to Windows Server 2022 or 2025 as part of a broader modernization, or skip on-prem entirely and shift workloads to Azure or AWS. That decision is driven by the app portfolio, not the OS deadline.
If you're running this: Use the runway. Teams that start discovery in 2028 will find, like the 2016 cohort is finding now, that discovery takes longer than the migration.
Extended support ends January 8, 2030. Mainstream support ended February 28, 2025.
You're already past mainstream. Security updates only, no feature work, no non-security bug fixes. 2019 also predates the cloud-connected features in 2022 (Synapse Link, Azure SQL MI integration, Purview), the security improvements, and native ledger tables. The 2030 deadline sounds far away. The platform is frozen now.
If you're running this: It's the version you migrate from, not to. Plan on your timeline, not the deadline's.
Extended support ends April 10, 2029 (on 16.11 baseline). Mainstream ended April 9, 2024.
This one's on the list because it quietly blocks modernization and teams don't see it. VS 2019 can't target .NET 9, .NET 10, or C# 13. Teams planning a move to modern .NET hit this wall the first time they open the project file. The Copilot integration, the modern debugger improvements, the current language tooling: none of it is coming back to 2019. The IDE has a ceiling and it's below where modern .NET work actually happens.
If you're running this: The IDE upgrade goes before the modernization project. Move the team to VS 2022 or 2026 before the work starts. Otherwise you're paying for friction every day.
Mainstream support ends January 11, 2028. Extended support ends January 11, 2033.
This is the reference point. Mainstream through January 2028, security through January 2033. SQL Server 2025 shipped in November 2025 and is now the newest on-premises version, but 2022 remains the landing point most legacy estates actually reach, and the cloud-connected features (Synapse Link, Azure SQL MI integration, Purview) work on 2022 or later. The real architectural question for most teams is "should we stay on-prem or jump to Azure SQL MI or Azure SQL Database." That depends on the app, not the database.
If you're running this: You're on a fully supported engine with years of runway. Modernization energy belongs on the apps running on top of it.
When a support date becomes someone else's question
For an engineering team, an end-of-support date is a planning input. For everyone else, it's a question on a form. The same dates on this page show up in cyber-insurance renewals ("are you running supported software?"), in audit findings ("unsupported platform identified"), and in private-equity technical due diligence ("what's the remediation plan for the end-of-life estate?"). The date didn't change. The person asking did.
The distinction that decides those conversations is between a claim and evidence. A claim is what you say on the call; evidence is what survives the follow-up email. "We're on supported versions" is a claim. The inventory that names each platform, states its support status, and attaches a dated plan for anything past end of life -- that's evidence. Auditors, carriers, and diligence teams have learned the difference, and the follow-up email is where the claim gets tested.
The gap between the two is almost always the unknowns: the SQL Server instance nobody has logged into this year, the 4.x application whose owner left, the server whose support status no one can state without checking. Closing that gap is discovery, not a memo, and the triage checklist is where that inventory starts. (Requirements vary by auditor, carrier, regulator, and contract; this is operational guidance, not legal or insurance advice.)
What you receive
One fixed-scope deliverable: the Legacy Modernization Risk Report (LMRR), delivered in 7 to 10 business days, written for both leadership and technical teams.
A 0 to 100 Modernization Readiness Score with Red / Yellow / Green zones, traceable to the published methodology -- deterministic findings underneath, judgment labeled as judgment.
A prioritized risk register -- each finding with severity, evidence, and what it blocks.
An evidence appendix that connects findings to supporting artifacts such as .csproj files, stored procedures, jobs, dependencies, and configuration.
Modernization sequencing guidance -- what to address first, what to delay, and why.
Pages from the SocialGoal sample report: a real public codebase (SocialGoal, an open-source ASP.NET MVC application), scored 44/100 Red. The supporting evidence is checkable against the source.
This work is for teams who need clarity, not reassurance.
Good fit
A real end-of-support date and a dependency chain you cannot fully account for.
Several Microsoft components reaching end of support in the same window.
Budget or board pressure to commit before the system has been measured.
Not a fit
You already hold a current, evidence-backed inventory and just need execution hands.
A single trivial in-place version bump with no coupling.
You want the migration done, not the risk documented.
What happens after you check fit
The fit review leads to a short call -- 20 to 30 minutes -- to find out whether Modernization Shield fits your situation. Not a sales pitch.
We confirm the platform and the rough scope: which legacy .NET and SQL Server systems are in play.
We identify the deadline and the pressure behind it -- the end-of-support date bearing down on the estate.
We decide together whether Modernization Shield is the right next step. If it is not, we tell you that.
No implementation pitch. Evincia sells no migration or build work, so there is nothing to upsell.
A deadline is rarely just one component.
Modernization Shield maps the applications, SQL Server dependencies, runtimes, and host platforms surrounding an end-of-support date. It shows what has to move together, what is most likely to break first, and where the deadline creates budget or operational risk.
The SocialGoal sample Modernization Risk Report shows how that dependency chain is documented and sequenced for the people who own the deadline.
