A .NET Framework to .NET 10 migration should target .NET 10, not .NET 8. Microsoft's support policy ends .NET 8 and .NET 9 on 10 November 2026, two weeks from today. .NET 10 is the current long-term support release, which shipped on 11 November 2025 and is supported until 14 November 2028.
This post doesn't revisit whether you have to migrate: .NET Framework 4.8 has no end date of its own, as we explain in .NET Framework 4.8 end of support. It covers the differences that matter, the order Microsoft recommends, and the technologies that need a decision before anyone estimates.
- Target .NET 10. Microsoft ends support for .NET 8 and .NET 9 on 10 November 2026; .NET 10 is supported until 14 November 2028.
- Microsoft's own porting overview still says to consider .NET 8. Its support table says .NET 8 has two weeks left.
- Port bottom-up: SDK-style projects and PackageReference first, then libraries, multi-targeted where needed, then apps.
- .NET Upgrade Assistant is deprecated. Microsoft now points to the GitHub Copilot modernization agent.
- Web Forms, WCF server, Workflow Foundation, AppDomains and Remoting need decisions, not conversions.
Why .NET 10 and not .NET 8?
Because .NET 8 ends before most migrations would finish.
| Release | Type | Released | Support ends |
|---|---|---|---|
| .NET 10 | LTS | 11 November 2025 | 14 November 2028 |
| .NET 9 | STS | 12 November 2024 | 10 November 2026 |
| .NET 8 | LTS | 14 November 2023 | 10 November 2026 |
| .NET Framework 4.8 | Windows component | 18 April 2019 | With the Windows version it runs on |
| .NET Framework 4.8.1 | Windows component | 9 August 2022 | With the Windows version it runs on |
Checked 27 October 2026 against Microsoft's .NET support policy and .NET Framework support policy.
The policy says "LTS releases are supported for three years after the initial release." Here's the catch. Microsoft's own porting overview, last revised in September 2025, still advises: "CONSIDER targeting .NET 8, which is a long-term support (LTS) release." By Microsoft's support table, .NET 8 has two weeks left. A team that follows that line finishes one migration and owes another. Follow the support table.
.NET Framework vs .NET 10: what's the difference?
.NET Framework is the original, Windows-only framework. In 2019 Microsoft said 4.8 "will be the last major version of .NET Framework." Modern .NET, formerly .NET Core, is the cross-platform successor, and Microsoft releases a new major version of it every year. Older guides talk about how to migrate .NET Framework to .NET Core; the target today is .NET 10, the current release of that same line.
| .NET Framework 4.8.x | .NET 10 | |
|---|---|---|
| Platforms | Windows only | Windows, Linux and macOS |
| Support | With the Windows version it runs on | Until 14 November 2028 |
| Future versions | 4.8 was the last major version | A new major version every year |
| Web framework | ASP.NET (Web Forms, MVC 5, Web API 2) | ASP.NET Core |
| Project format | Often the older .csproj format with packages.config | SDK-style projects |
Microsoft's porting overview puts it plainly: ".NET Framework is a Windows-only component," while .NET "is designed to be cross-platform."
How does a .NET Framework to .NET 10 migration work, step by step?
Bottom-up. Microsoft's porting overview and prerequisites page give the order:
- Inventory dependencies. Microsoft says to examine dependencies first, because they "must target .NET, .NET Standard, or .NET Core." Each package that never shipped a modern version is a replacement or a fork. Note every use of the blockers in the table below.
- Retarget to .NET Framework 4.7.2 or later. Microsoft recommends this so the latest API alternatives are available "for cases where .NET Standard doesn't support existing APIs."
- Move to PackageReference and SDK-style projects. Convert packages.config first, then each project file. Microsoft notes the SDK-style format "also works with .NET Framework," so this step can ship before any code moves.
- Port libraries first, multi-targeted. For a library still used by .NET Framework projects, Microsoft suggests .NET Standard 2.0 or targeting both frameworks. For web apps, its ASP.NET guidance says to upgrade libraries in "postorder depth-first search ordering": leaf libraries first, the main application last.
- Port the applications. Retarget to .NET 10, add the Microsoft.Windows.Compatibility package if Windows-only APIs are missing, and test. ASP.NET apps move to ASP.NET Core, usually one route at a time.
Migrate a .NET Framework project to SDK-style
Microsoft's try-convert tool converts projects to the SDK-style format, but Microsoft says it "isn't recommended if your project has a complicated build process such as custom tasks, targets, or imports." For those, convert by hand, one project at a time, and check the build output still matches before moving on.
What about .NET Upgrade Assistant?
It's deprecated. Microsoft's Upgrade Assistant page says ".NET Upgrade Assistant is officially deprecated" and points to the GitHub Copilot modernization chat agent, "included with Visual Studio 2026 and Visual Studio 2022 17.14.16 or later." Microsoft's upgrade overview says to use Upgrade Assistant only if you can't use the agent. Either tool helps with mechanical changes. Neither tells you which parts of the application the business still depends on.
What can't move to .NET 10: the blockers
These are the .NET Framework technologies Microsoft lists as unavailable on modern .NET, with the alternatives it names.
| Technology | On .NET 10 | What Microsoft suggests instead |
|---|---|---|
| AppDomains | Creating more isn't supported | Separate processes or containers; AssemblyLoadContext to load assemblies |
| .NET Remoting | Not supported | Pipes or memory-mapped files on one machine; HTTP, gRPC or Web API across machines |
| Code Access Security | Not supported | Operating system boundaries: virtualization, containers, user accounts |
| Security transparency | Not supported | The same operating system boundaries |
| System.EnterpriseServices (COM+) | Not supported | No replacement named |
| Workflow Foundation | Not supported | CoreWF, an open-source port Microsoft links to |
| WCF server | Not included | The CoreWCF NuGet packages |
| ASP.NET Web Forms | Not ported | Pages rebuilt on ASP.NET Core; Microsoft points Web Forms developers to Blazor |
Checked 27 October 2026 against Microsoft's list of .NET Framework technologies unavailable on .NET 6+ and its guide Blazor for ASP.NET Web Forms developers.
WCF services and Web Forms pages are usually the items that set the size of the job. Each has its own guide: WCF in .NET Core and Web Forms end of life. Servers that pass their support dates while you migrate bring the problems in the risks of running end-of-life software, and an estate that mixes all of the above is common on any list of legacy system examples.
What to know before anyone estimates
The blockers table says what can't move. It doesn't say how much of each your code uses, or which parts the business still needs. The 30-day assessment is fixed in scope, at a price agreed before we start. Over 30 days we read the solution and the architecture around it, map how the projects, libraries, services and databases fit together and the order they'd have to move in, find the hidden architectural debt, and flag the security and compliance gaps, including packages with no modern version and anything on a runtime that leaves support on 10 November 2026.
The report says in plain language what is broken and what it would take to fix it. Your own team can act on it, or we can do the migration as a separate project with its own scope and price. Either way, the report stands on its own.
Pick a time to talk about the solution you'd move first.