Microsoft ends support for both .NET 8 and .NET 9 on November 10, 2026. .NET 8 is an LTS release reaching the end of its three years. .NET 9 is a standard-term release, and its support was extended to 24 months, which lands it on the same day. Apps on either keep running after that date, but they stop getting security fixes. .NET 10 is the current LTS release and is supported until November 2028.
So a lot of teams are retargeting to net10.0 this month. If your app uses feature flags, here is a short checklist.
Update Microsoft.FeatureManagement
Version 4.7.0 added .NET 10 support, and 4.8.0 is the current release. The package ships net8.0 and net10.0 builds, so updating is a version bump:
dotnet add package Microsoft.FeatureManagement.AspNetCore
Read the release notes for the versions you skip. Most of the 4.x changes add features rather than break things, but it's worth knowing what moved under you.
Test with flags in both states
An upgrade changes the runtime under code paths you rarely run. The code behind a flag that has been off for months is exactly that kind of path. Before you ship, run your tests with each long-lived flag on and with it off. A flag whose "on" path no longer compiles against new APIs is better found in CI than in production.
Clean up while you're in there
You're already reading every project file. Flags that have been on everywhere for months are finished: delete the flag and the dead branch. Fewer flags means fewer paths to test in step 2, and it keeps you under any plan limit.
Decide where your flags should live
If your flags are in appsettings.json, changing one means a deployment. That's fine when flags change with releases. It's painful when you need to turn something off now.
The upgrade is a natural time to move them, because you're already changing Program.cs and redeploying. The FeatureFlags.app client requires ASP.NET Core on .NET 10, so once you've upgraded it's an option:
dotnet add package Acmi.FeatureFlags.Client
using Acmi.FeatureFlags.Client;
builder.AddFeatureFlags();
AddFeatureFlags() replaces AddFeatureManagement(). Don't call both. Your IFeatureManager, [FeatureGate], and <feature> code stays the same. You can import the feature_management section of your appsettings.json from the dashboard, and export back to the same format on any plan. Our post "Moving Feature Flags Out of appsettings.json" walks through it step by step.
Changes reach your apps on the client's refresh interval, 15 minutes by default. If you rely on kill switches, set CacheExpirationInMinutes lower.
Or don't
If a handful of flags change only with deployments, appsettings.json is still the right answer, and the upgrade doesn't change that. The point of the checklist is steps 1 to 3. Step 4 is only for you if redeploying to flip a flag has already hurt.
An upgrade deadline is the one time everyone agrees to touch the old code. Use it.