The .NET 5 release in November 2020 was a useful milestone for teams deciding what to do with an existing .NET estate. A new runtime, however, does not remove the assumptions built into an old application.
Inventory before rewriting
List each deployable application, its runtime, its operating system and the packages that bind it to that environment. Include scheduled jobs and maintenance tools. A forgotten import utility can block a migration just as effectively as the main website.
Next, identify boundaries. Which components expose HTTP contracts? Which share a database schema? Which call Windows-specific APIs? A module with a clear interface is a better first candidate than a module whose callers depend on its implementation details.
Use a small compatibility experiment
Choose one representative workflow and reproduce it in an isolated branch. Exercise authentication, serialisation, persistence and deployment. Record the incompatibilities rather than immediately replacing every library.
The experiment should end with a decision: migrate directly, introduce an adapter, or leave this component in place while another moves first. Keep the business behaviour stable so the team can attribute failures to the platform change.
This is historical context, not a recommendation to deploy .NET 5 now. For a migration undertaken today, choose a currently supported target and check its package compatibility separately.