Article
".NET 8 migration cost" isn't one number, because ".NET 8 migration" isn't one kind of project. Moving an app that's already on .NET 6 up to .NET 8 is a routine version bump. Moving an app that's still on ASP.NET WebForms or classic .NET Framework to .NET 8 is a different project entirely, closer to a rewrite than an upgrade. The starting point is what actually sets the number.
The two starting points are not the same project
Already on .NET Core / .NET 5+. These migrations are largely mechanical: update target frameworks, resolve a handful of breaking API changes, update NuGet packages that haven't kept pace, re-run the test suite. Cost here is mostly a function of how many dependencies need updating and how much test coverage already exists to catch regressions.
Still on .NET Framework or ASP.NET WebForms. This is where the real cost lives, because .NET 8 doesn't run WebForms at all - there's no compatibility shim. The application layer has to be rebuilt on ASP.NET Core, which means untangling whatever request-lifecycle assumptions WebForms baked in (ViewState, page lifecycle events, server controls) rather than just recompiling against a newer target. We hit exactly this on a logistics client's operations dashboard, still running ASP.NET WebForms on IIS 6 with SQL queries scattered inline through the codebase - the .NET 8 migration there wasn't a version bump, it was rebuilding the application layer on ASP.NET Core with Entity Framework Core and a proper repository pattern replacing that inline SQL.
What actually drives the number, either way
Third-party and NuGet dependency compatibility. Older packages that were never updated for .NET Core-style hosting are a common blocker, and finding or writing a replacement is real, billable work that's hard to estimate before you've actually audited the dependency list.
How much of the codebase touches framework-specific APIs. Direct System.Web references, HttpContext.Current used as a global, or Windows-specific dependencies all need rework that has nothing to do with business logic - it's migration overhead, and it scales with how deeply those APIs are woven through the code rather than isolated behind an interface.
Test coverage going in. A migration onto .NET 8 with a real test suite already in place can validate correctness fast. One without it needs manual regression testing built into the migration plan, which extends the timeline and the cost - not because the code is harder to move, but because there's no fast way to know if it still works.
Downtime tolerance. A system that can take a maintenance window costs less to move than one that has to stay live throughout. We rebuilt a reservation platform's backend on .NET 8 and ASP.NET Core to eliminate database deadlocks during peak booking spikes - the concurrency fixes and Redis caching layer needed to hit 50ms reads under peak load are a different scope than a straightforward recompile, precisely because the system couldn't come down to make the change.
Why we don't quote a number before an assessment
A real .NET 8 migration estimate depends on which of the two starting points above you're actually in, how many dependencies need auditing, and how much test coverage exists - none of which is visible from the outside. Both of the migrations above only got a real number after someone actually looked at the existing system's architecture, dependencies, and downtime constraints - not before.
If you want a real number instead of an industry average, that starts with an assessment of your specific application.