.NET 8 and 9 Are Almost Out of Support. Time to Get Moving.

Well, this is awkward.

.NET 8 and .NET 9 are both reaching end of support on November 10, 2026. That's right around the corner. If you're still running either version in production, it's time to start thinking about that upgrade.

And no, ignoring the calendar doesn't count as an upgrade strategy. I've checked.

What's happening?

Microsoft has lined up the end-of-support dates for both releases:

Version	Release type	End of support
.NET 8	LTS	November 10, 2026
.NET 9	STS	November 10, 2026
.NET 10	LTS	November 2028

.NET 8 is an LTS release, normally supported for three years. .NET 9 is an STS release, and its support period was extended to 24 months. The result? Both versions get shown the door on the same day.

After November 10:

• No more regular security updates.
• No more servicing fixes.
• No more Microsoft technical support for those releases.

Your applications won't suddenly stop working at midnight. They'll keep running. But they'll be running on an unsupported platform, and any newly discovered vulnerabilities won't get patched through the normal support lifecycle.

That's not a great place to be.

You can read the details in Microsoft's announcement.

The obvious answer: .NET 10

.NET 10 is the current LTS release, supported through November 2028.

For most applications, the first step is straightforward: update the target framework in your project file.

<PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
</PropertyGroup>

Of course, changing one line doesn't magically migrate your entire application. You'll still need to:

• Update your SDK and development environments.
• Check NuGet package compatibility.
• Review breaking changes.
• Test your application.
• Update your hosting environment.

And if you're maintaining several applications, you'll want to make sure none of them get lost in the upgrade shuffle.

What about your feature flags?

Here's the part relevant to this little corner of the .NET ecosystem.

If you're using Microsoft's Microsoft.FeatureManagement libraries, don't assume your feature flag setup needs to be redesigned just because you're upgrading the runtime.

Feature management is a separate concern from the .NET runtime version. Your flag definitions, filters, and application integration may need package updates or compatibility checks, but the basic concepts remain the same.

This is actually a good opportunity to review how you're managing those flags.

Are they still buried in appsettings.json? Does changing one require a deployment? Are you maintaining separate configuration files for every environment?

An upgrade is a reasonable time to clean up some of that technical debt. Just don't turn a runtime upgrade into an excuse to rewrite everything. That's how a two-week project becomes a fiscal-year initiative.

Don't let feature flags become upgrade blockers

Feature flags can make application upgrades safer.

For example, you can use them to control the rollout of code changes while you're migrating to .NET 10. Keep a new implementation disabled initially, deploy it, and enable it when you're ready to test.

You can also use a kill switch to disable a problematic feature without immediately rolling back an entire deployment.

Just remember: a feature flag doesn't make an unsupported runtime safe. It helps manage application behavior; it doesn't replace security patches.

A quick checklist

If you're still running .NET 8 or .NET 9, here's the short version:

• [ ] Identify all applications targeting .NET 8 or .NET 9.
• [ ] Check your SDKs, NuGet dependencies, and hosting environments.
• [ ] Plan the move to .NET 10.
• [ ] Test the upgrade before deploying to production.
• [ ] Review your feature flags and configuration strategy.
• [ ] Make sure your deployment and rollback plans are ready.

One last thing

.NET 8 and .NET 9 don't stop working on November 10. But the support safety net goes away, and that's a pretty good reason to get moving.

Use the upgrade as an opportunity to tidy up your feature management while you're at it. If you're looking for a straightforward way to manage Microsoft .NET feature flags without relying on Azure App Configuration or maintaining your own dashboard, FeatureFlags.app is one option.

Now go check those target frameworks. Your future self would appreciate it. Probably.