I like a faster runtime. I like it considerably more when we can explain what it will do for the business paying for the upgrade.
.NET 8 arrived on November 14, 2023, with long-term support and improvements across performance, deployment and development tools. That’s a worthwhile release. It is also the point at which a very enthusiastic benchmark chart can accidentally become somebody’s project brief.
A customer using your portal probably won’t notice that the runtime compiles code more intelligently. They will notice whether their order history opens promptly and the export finishes before they lose patience. Those outcomes are related, but there are several things between them.
Take a hypothetical account page that needs two seconds to respond. If most of that time is spent waiting for a database query, making the application code faster addresses the smaller part of the delay. It is the software equivalent of buying running shoes for the person waiting at baggage claim. Lovely shoes. Still waiting.
If the application spends its time performing repeated calculations or processing large amounts of data, the upgrade could make a more noticeable difference. You need to know which situation you have.
.NET 8 enables dynamic profile-guided optimization by default. The runtime uses information about how code executes to make better compilation decisions. Changes in memory management and commonly used libraries offer other opportunities to do existing work more efficiently. Stephen Toub’s extensive performance analysis explains many of those improvements through small benchmarks.2
The important word is small. A benchmark can demonstrate that a particular operation improved. It cannot promise that your checkout, database and shipping provider will improve by the same percentage out of professional courtesy.
This is the kind of problem our custom development team enjoys.
Make the upgrade earn its place
Zulu Shack recommends establishing a baseline for the journeys that matter before estimating the benefit. Record response times during a representative workload, inspect the slow requests and identify the dependencies involved. Then compare the upgraded application under similar conditions.
Correctness belongs in that comparison. An export that finishes sooner but changes the totals is not the sort of surprise anyone requested.
Supportability can be a good business reason to upgrade even when the performance gains are modest. Make that purpose explicit. Review packages, authentication, scheduled tasks, deployment scripts and the integrations the application relies on. A successful build is encouraging; it doesn’t prove that existing customers can still sign in and complete their work.
Pairs well with .NET 9 is here. The upgrade still needs to earn its place.
Also distinguish an application already using a recent .NET release from one using the older .NET Framework. The latter may need a broader migration. Calling both an upgrade is convenient language, but the estimates should not pretend they’re the same job.
Some release features deserve separate evaluation. Native AOT, which compiles suitable applications ahead of time, can change startup and memory characteristics but needs compatibility checks. The first .NET Aspire preview introduces useful ideas around dependencies and diagnostics. In November 2023, it is a preview to investigate, not an automatic production requirement.
Give the proposed work a clear pass condition: a supported application, verified behavior and a measured improvement where improvement was promised. Include a release plan and a way to recover if something goes wrong.
Then, if the evidence supports it, upgrade. A sound investment doesn’t need a theatrical before-and-after chart. It needs to leave the people using and maintaining the system better off.