Guide · .NET Framework

.NET Framework 4.6.2 support ends on 12 January 2027.

Microsoft stops security fixes, other updates and technical support for .NET Framework 4.6.2 on 12 January 2027, the same day Windows Server 2016’s extended support ends. It affects any server or PC still on 4.6.2, such as a Windows Server 2016 machine left at the version it shipped with. Versions 4.7 and later have no fixed end date: they’re supported for as long as the Windows they run on.

Ends: 12 Jan 2027
Version: .NET Framework 4.6.2
Stays supported: 4.7 – 4.8.1, with Windows
Same day: Windows Server 2016
Verified: 7 Oct 2026

What ends: Security fixes, other updates and technical support for .NET Framework 4.6.2.
When: 12 January 2027, the same day as Windows Server 2016’s extended support.
Move to: .NET Framework 4.8.1, or 4.8 on Windows Server 2016 and 2019: supported for as long as the Windows they run on. .NET 10 for the longer term.
Who it affects: Machines whose installed .NET Framework is 4.6.2. A machine with 4.8 or 4.8.1 installed runs a 4.6.2 app on that newer, supported version.
First step: Check the installed version on every server and PC that runs the app, then test it on 4.8.1, or 4.8 where 4.8.1 isn’t available.
Source: Microsoft’s .NET Framework lifecycle, dates verified 7 October 2026.

Before you change anything. This guide is general information, not advice for your system. The dates and steps come from Microsoft’s published pages, checked on 7 October 2026, and Microsoft can change them, so confirm on the linked source before you plan around a date. Back up, test every change on a copy that isn’t in production, keep a way back, and follow your own change process. You follow these steps at your own risk (terms). SnowDriven isn’t affiliated with Microsoft (trademarks).

What ends, and what doesn’t

End of support is about fixes and help from Microsoft. Nothing switches off.

From 12 January 2027, Microsoft no longer ships security fixes or other updates for .NET Framework 4.6.2, and its support teams no longer help with it. An app on 4.6.2 keeps running. What changes is that any vulnerability found in the runtime after that date stays open on those machines.

Only 4.6.2 has a fixed date. Since version 4.5.2, .NET Framework is a component of Windows, so 4.7, 4.7.1, 4.7.2, 4.8 and 4.8.1 are supported for as long as the Windows version they’re installed on. Microsoft hasn’t announced an end date for 4.7 or 4.7.1.

The same day, Windows Server 2016 reaches the end of its extended support. It shipped with .NET Framework 4.6.2, so a 2016 server that was never moved to a newer version is the first place to look. Installing 4.8 there fixes the runtime but not the server: it needs replacing too. See Windows Server 2016 end of support for the upgrade paths.

Some of the estate on PHP? See PHP 8.2 end of life.

Check what you run

Two questions: which version is installed on each machine, and which version the app was built for.

Installed on the machine

On each server or PC that runs the app, open PowerShell and run Microsoft’s documented check. It prints a number, the Release value from the registry:

(Get-ItemPropertyValue -LiteralPath 'HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' -Name Release)

Compare it with the table: the installed version is the first row whose value it equals or exceeds. If the key is missing, the machine has no .NET Framework 4.5 or later at all. A value below 394802 is a 4.x version older than 4.6.2, whose support has already ended.

Release value to version
Release at least	Version	Support
533320	4.8.1	Supported with Windows
528040	4.8	Supported with Windows
461808	4.7.2	Supported with Windows
461308	4.7.1	Supported with Windows
460798	4.7	Supported with Windows
394802	4.6.2	Ends 12 January 2027

Built for, in the app

Ask whoever maintains the app to look in the project files. Older project files say <TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>; newer SDK-style ones say <TargetFramework>net462</TargetFramework>. A desktop app or Windows service may also name it in its .config file, as sku=".NETFramework,Version=v4.6.2".

The two can differ. Version 4.6.2 and later are in-place updates of the earlier 4.x versions, so an app built for 4.6.2 runs on 4.8.1 when that is what the machine has. Support follows what’s installed, so the machines are the urgent part. Retargeting the project to the installed version comes next, so the app is built and tested against what it actually runs on: 4.8.1, or 4.8 on machines that can’t take 4.8.1, since an app built for 4.8.1 won’t run where only 4.8 is installed.

Your three options

Most teams do the first before January and decide on the second or third afterwards.

Option 1 · The fast, supported stopgap
Move to .NET Framework 4.8.1
Install the newer runtime on each machine, retarget the project, and test the main workflows on a pre-production copy before rolling it out. Take a snapshot or full backup of each machine before installing: 4.8 and 4.8.1 replace 4.6.2 in place, and backing one out isn’t always a simple uninstall. Microsoft describes 4.6.2 and later as compatible, in-place updates and says recompiling isn’t necessary, though a few fixes can change behaviour for some apps.
Where
4.8.1: Windows 10 version 20H2 or later, Windows 11, Windows Server 2022 and 2025. On Windows Server 2016 and 2019 the newest is 4.8.
Good
The smallest change. Supported for as long as the Windows version it runs on. No code moves.
Trade-off
Still .NET Framework: Windows only, security fixes but no new features. It buys time; it doesn’t make the app easier to change.
Option 2 · The longer-term move
Move to modern .NET 10
.NET 10 is the current long-term support release: released 11 November 2025, supported until 14 November 2028. Long-term support releases get three years, so moving to the next one before then is part of the plan. Don’t start a port on .NET 8 or .NET 9: Microsoft ends support for both on 10 November 2026 (what that means for apps already on them).
Usually moves with fewer changes
- Business logic and class libraries
- Windows Forms apps (still Windows only)
- Windows services, rebuilt on the Worker Service host
- Entity Framework 6 data access, which runs on modern .NET
Needs rework or a replacement
- ASP.NET Web Forms pages: Web Forms won’t be ported to modern .NET, so each page is rebuilt, for example in Blazor
- ASP.NET MVC and Web API: moving to ASP.NET Core is non-trivial for most production apps; Microsoft recommends doing it incrementally
- WCF services: move to CoreWCF, whose HTTP, NetTcp and WebHttp packages Microsoft supports; check every binding you use
- Workflow Foundation, AppDomains, .NET Remoting, Code Access Security and COM+ (Enterprise Services) aren’t available
Good
A supported, actively developed platform with a published support window, and a codebase that’s easier to change and test.
Trade-off
Real engineering work, larger for Web Forms. It won’t be finished by January, so it follows option 1 rather than replacing it.
Option 3 · When the app no longer earns its keep
Replace it
Buy a product that does the job now, or rebuild a small app from scratch when there’s little worth keeping. It fits apps with few users, few custom rules, or a commercial product that has caught up.
Good
No .NET Framework left to maintain.
Trade-off
Data migration, retraining, and the business rules nobody wrote down, which tend to surface late. Keep the old app supported on 4.8.1 until the replacement is live.

Which option fits

A simple way to choose. Most situations start with option 1.

If	Then
The app works, rarely changes, and its servers run Windows Server 2019 or later	Install .NET Framework 4.8.1 (4.8 on Windows Server 2019), retarget to the version installed, test and roll out. Revisit the bigger move when the app next needs real change.
It still runs on Windows Server 2016	The server’s own extended support ends the same day. Move to a newer Windows Server with 4.8.1, or make that move the first step toward .NET 10.
It changes every month and the business will rely on it for years	Take 4.8.1 now as the supported stopgap, then move to .NET 10 in stages, with tests around the behaviour that matters first.
Most of it is Web Forms pages or WCF services	Take 4.8.1 now. Rebuilding the Web Forms pages is the bulk of any later move; WCF services can move to CoreWCF if their bindings are covered.
An off-the-shelf product now does what the app does	Price a replacement, including data migration and retraining. Take 4.8.1 meanwhile: a replacement rarely lands by January.

The next 90 days

Order matters more than speed: know what you have, make it supported, then plan the bigger move.

Take an inventory
List every server and PC that runs the app, with its Windows version and its Release value. Note what the project targets, who can build and release it, and whether anyone can still build it at all.
Test the 4.8.1 upgrade
Install 4.8.1 (4.8 on Windows Server 2016 or 2019) on a pre-production copy, retarget the project to the version you installed and run the workflows the business depends on. Check Microsoft’s application compatibility list for anything your app uses.
Roll it out before 12 January
Update production through your normal change process, one machine or group at a time, with a way back. Take a snapshot or full backup of each machine before installing: 4.8 and 4.8.1 replace 4.6.2 in place, and backing one out isn’t always a simple uninstall. Flag any Windows Server 2016 machine for replacement, since its support ends the same day.
Plan the bigger move
With the runtime supported, decide between staying on 4.8.1 for now, moving to .NET 10 in stages, or replacing the app. Count the Web Forms pages, WCF services and abandoned libraries first: they decide how big the move is.

How we can help

If you’d rather not do the inventory and the plan alone.

Scoped and quoted on its own

Modernization audit

The code, dependencies, data, hosting and releases reviewed, the risks ranked in a written report, and a step-by-step plan. Nothing beyond the audit is committed until you decide to go further.

Start with an audit How a modernization runs See a sample report

No email needed

Modernization readiness check

Ten yes-or-no questions about the system, including whether it runs on a version that no longer gets updates, and the first step we’d suggest.

Take the readiness check See the runway on every runtime

Questions about 4.6.2 end of support

Will our app stop working on 12 January 2027?

No. End of support doesn’t switch anything off. After that date Microsoft no longer ships security fixes or other updates for .NET Framework 4.6.2, and no longer gives technical support for it. The risk grows with every vulnerability found after the date.

Do .NET Framework 4.7 and 4.7.1 also reach end of support in January 2027?

Not according to Microsoft’s published lifecycle as of 7 October 2026. Only 4.6.2 has a fixed end date. Versions 4.7, 4.7.1, 4.7.2, 4.8 and 4.8.1 are components of Windows and are supported for as long as the Windows version they’re installed on.

Can we install .NET Framework 4.8.1 on Windows Server 2016 or 2019?

No. Microsoft lists 4.8.1 for Windows Server 2022 and 2025, and for Windows 10 version 20H2 or later and Windows 11. On Windows Server 2016 and 2019 the newest version is 4.8, which is supported for as long as that Windows version is. Windows Server 2016 itself reaches the end of extended support on 12 January 2027.

Do we have to recompile the app to run it on 4.8.1?

Usually not. Microsoft describes 4.6.2 and later as compatible, in-place updates and says recompiling isn’t necessary. A small number of changes can still affect some apps, so Microsoft recommends updating a pre-production copy first. Retargeting the project when you next build it means it’s tested against the version it runs on.

Should we move to .NET 8 or .NET 9 instead of .NET 10?

No. Microsoft ends support for both .NET 8 and .NET 9 on 10 November 2026. .NET 10 is the current long-term support release, supported until 14 November 2028.

Sources · support dates verified 7 October 2026

Part of SnowDriven Research: see this date in the deadline table beside every other date we track, and how we verify them.

General information, checked on 7 October 2026. Confirm dates with the vendor; follow at your own risk. Terms.

Start a project

Still on 4.6.2? Let’s plan the move.

Tell us what the app runs on and what it does for the business. We reply within one business day, with questions or a time to talk.

Start a project Request a scoping call

Pittsburgh, PA · Since 2015 · First step: a 30-minute call