News
Devs Discuss Updating Backend Code from .NET 8 to .NET 10: 'Like a Breeze'
Developers discussing updating code from .NET 8 to .NET 10 on social media are generally positive about the move, noting few breaking changes and making comments like an upgrade going "like a breeze" and another saying: "It's worth it. That's it. That's the answer."
That seems to be unusual for social media discussions about software updates, which often focus on problems and frustrations. But in this case, the feedback seems detailed and thoughtful as well as positive, occurring in the
.NET thread on Reddit, started by a developer who opened the discussion nine days ago with this:
Did any backend dev here migrate their .NET 8 code to 10? Is it worth it at this point?
Im usually the 1st to migrate my serverside (my own of course, not work related) to the latest .NET LTS but recent microsoft shenanigans have discouraged me from touching anything new they make
Is there any feature in .NET 10 that makes it worth the risk? How we feeling about it?
Despite the kickoff question being for private code, many seemingly enterprise developers chimed in with their experiences in about 36 comments.
Here's a tl;dr summary:
Breaking Changes
- System.Linq.Async replaced by built-in async enumerable support: Several replies clarified that System.Linq.Async has effectively been replaced by System.Linq.AsyncEnumerable. As a result, developers need to remove the external package and update code that uses methods such as SelectAwait, which require changes when migrating.
- EF Core 10 dynamic conditional bulk delete change: One commenter explicitly called out a breaking change introduced in EF Core 10 affecting dynamic conditional bulk deletes, noting it separately from core .NET 10 changes.
- Non-incremental source generators obsoleted: Developers reported that non-incremental source generators are obsoleted in .NET 10 and must be rewritten as incremental source generators.
- OpenAPI-related breaking changes: Multiple commenters cited OpenAPI friction, including deprecated methods and changes in default OpenAPI document generation. .NET 10 generates OpenAPI 3.1.1 by default, which caused issues for some Azure API Management CI/CD tasks, requiring teams to pin generation back to OpenAPI 3.0.x.
- Host creation changes: One commenter said the only breaking change they encountered was related to host creation, without additional detail, suggesting a startup or hosting API adjustment.
- Dependency ecosystem gaps (Entity Framework providers): Several developers reported upgrade blockers tied to dependencies rather than the runtime itself, particularly EF Core database providers that had not yet released .NET 10-compatible versions, including PostgreSQL and MySQL providers such as Pomelo.
- Tooling requirements: One commenter noted needing to install a newer version of Visual Studio in order to target .NET 10.
Even with these issues surfaced, commenters generally characterized them as limited, well-understood, or dependency-driven. Many said the upgrade amounted to little more than changing the target framework unless a specific library, generator, or OpenAPI integration required follow-up work.
Upgrade Effort and Scope
- Several developers said the upgrade required little more than changing the target framework, describing it as taking "a few minutes," or "20 min work," along with the "like a breeze" comment.
- Multiple commenters cited large-scale upgrades, including dozens of projects, multi-tenant SaaS platforms, large monoliths, IIS-hosted backends, Windows services, and WPF clients.
- Some developers reported longer upgrade timelines measured in days or weeks, but still described the process as smooth, even when handled by a single person.
- Several comments emphasized that code changes were minimal or unnecessary unless teams chose to adopt new .NET 10 features.
Across a wide range of project sizes and deployment models, developers consistently characterized the upgrade effort as straightforward. Even teams working with large, multi-project and multi-service codebases reported that the transition was largely limited to retargeting projects, with additional work driven mainly by specific dependencies or optional feature adoption.
Why Developers Say It's Worth It
- Many commenters described the move to .NET 10 as a "free performance upgrade," citing faster execution, reduced memory usage, and runtime improvements.
- Some developers pointed to specific performance areas, such as regex improvements and faster initial loads.
- Several commenters said Long-Term Support (LTS) was the primary motivation, noting that upgrading extends support timelines and reduces security risk.
- Others framed upgrading as unavoidable due to .NET's support lifecycle, particularly for web-facing applications.
Rather than focusing on new language or framework features, most developers framed the value of upgrading in practical terms: performance gains, continued LTS coverage, and staying within a supported and secure runtime. In that context, commenters repeatedly said the upgrade was worth doing even if no new features were immediately adopted.
About the Author
David Ramel is an editor and writer at Converge 360.