.NET 9 launched on November 12, 2024, with runtime, web framework and tooling improvements. Whether an existing business application should move immediately is a separate question.
I enjoy a new release. There are useful ideas to explore, problems to reconsider and usually a feature that makes a developer lean back and say, “Oh, that’s nice.” None of that automatically explains why the accounts team should fund a migration this month.
The November 2024 decision has two parts: what the new version could improve, and what adopting it would commit the business to maintaining.
At launch, .NET 9 was a Standard Term Support release under the then-current 18-month policy. .NET 8 was a Long Term Support release with three years of support. Those are the policy terms relevant to this release-time comparison, rather than a later revision to STS support.
A business already operating reliably on a supported .NET 8 application could reasonably stay there while evaluating .NET 9. Staying supported still requires patches, compatible dependencies and an eventual upgrade plan. LTS is a maintenance arrangement, not permission to put the application in a drawer.
The new runtime may bring worthwhile performance improvements, but Microsoft’s benchmark results cannot be pasted onto a client’s hosting bill. An application waiting on a database query or an external API may see a very different result from a runtime benchmark.
Measure the operations people actually use. That might be loading a large order, calculating a quote or processing a scheduled import. Compare response times, resource use and correctness under a representative workload. If the bottleneck is an unhelpful query, the runtime deserves better than being asked to disguise it.
Somebody has to own the quiet, unglamorous work. See our hosting and support plans.
Separate the runtime decision from the feature experiment
HybridCache is a good example of why release headlines need a little unpacking. It offers a unified way to use local and optional distributed caching, with protection against repeated concurrent work for the same cache entry. At the .NET 9 launch, the library was still in preview.
That distinction matters. Exploring a preview library in a contained experiment and adopting a supported runtime across a production system are different decisions. A newer runtime does not require turning every interesting package into part of the release.
Caching also leaves business rules to us. A fast product description and a current stock commitment have different freshness requirements. The library cannot decide how much stale information your operation can tolerate.
Pairs well with .NET 8 is here. Will your customers notice?
Before approving an upgrade, I want a short answer to four things:
- What measurable problem or support requirement justifies the move?
- Which hosting components, libraries and integrations need compatibility checks?
- Which business journeys will be verified before and after deployment?
- Who owns rollback and the next supported upgrade?
A small, well-maintained application may make that exercise straightforward. A heavily customized system may need more preparation. The version number alone tells us very little about the effort.
There is room for curiosity without confusing it with urgency. Try the new capabilities, learn where they help and keep the production decision attached to a real outcome.
If .NET 9 earns its place, make the move deliberately. If the supported application is doing its job and the benefits remain theoretical, a scheduled evaluation is a perfectly respectable result. The release party will manage without your purchase order.