Migration from .NET 6.0 to .NET 8.0: Compatibility and Considerations

Question

Hello everyone,

We have a solution with a vast number of projects, and we are aiming to migrate some of the components to .NET 8.0. Before proceeding with the migration, we want to ensure that we will have full compatibility and support for it.

Our App Services are currently running on-premises on Windows Server 2012 and on Azure over Windows environments.

Currently, we have a Host App (Rest API host app) running on .NET 6.0. Before the end of support for .NET 6.0, we are looking to migrate those host apps to .NET 8.0.

These host apps consume a variety of modules, mostly in .NET Standard 2.0, and some of them are still in .NET Core 3.1.

On the other hand, we have some webapps in Framework 4.8 that also consume those shared modules in .NET Standard 2.0/.NET Core 3.1.

Stage 1: Migrate Rest API from .NET 6.0 to .NET 8.0

Stage 2: Migrate Shared Modules from .NET Standard 2.0/.NET Core 3.1

Stage 3: Migrate Web Apps from Framework 4.8 to .NET 8.0

The question is about compatibility/effort and value of it. Are there any known issues that would prevent us from proceeding with this migration?

Simplified diagram

Thanks in advance, best regards. Juan

Answer 1

upgrading from .net6 to .net8 is basically changing the framework version, and updating nuget packages. the same should be true of the 3.1 code. the upgrade assistance can be used, but its pretty simple:

https://dotnet.microsoft.com/en-us/platform/upgrade-assistant

as for your approach. you should upgrade the netstandard 2.0 last.

1. upgrade .net 6 and 3.1 libraries (optional) to net 8 (simple)
2. rewrite 4.8 code to net 8 (bulk of the migration)
3. upgrade .netstandard to .net 8 (simple)

upgrading the 4.8 code complexity will depend on the 4.8 features used. all webform code will need to be rewritten to MVC or razor pages. if you used MVC, the binding is much more strict, and may need refinement. there is no support for HttpContext.Current. WCF and SOAP calls are not as well supported in net 8.

as the project file structure is different between 4.8 and net8, its easiest to create a new net 8 project and add the 4.8 code as you port it.

note: if you run into issues with the nuget packages, runtime libraries used by the .net standard library, you can change it to a multi-framework project and build netstandard 2.0 and net 8 libraries. But as they currently work with net 6, this is probably not an issue.