The Challenging Endeavour of a .Net 6 Migration

For our most important application, the migration from .Net 4.8 to .Net 6 was an adventure. Now that it successfully runs in production, I take the opportunity to share our experience with the migration of our biggest application and the obstacles we run into.

This is part 1 of the mini-series on the .Net 6 migration:

1. The Challenging Endeavour of a .Net 6 Migration
2. 10 Unpleasant Surprises When Migrating From .Net 4.8 to .Net 6
3. .Net 6 in Production: Same Same, but Different

 

Our application

The application written in .Net 4.8 consists of 120 projects that includes multiple web applications, Windows services, various support tools, and the test projects (with unit-, integration- and BDD-tests).

We generate 75% of the revenue of the company with this application, so the stakes are high, and we cannot waste time. Therefore, we prepared our migration carefully and did a few experiments on how to proceed.

 

Why migrate to .Net 6?

While .Net 4.8 will get support over the next years, we already see the lack of testing that .Net 4.8 libraries get. The lack of documentation, and the extra hoops we need to go through to get things like OpenID working, is getting more annoying by the month.

We choose .Net 6 as the target version because it is a long-time supported version. That extra 6 Months of support compared to .Net 7 may come in handy should our priorities change in the next year.

 

Preparations

We did not just start one day and moved the code from .Net 4.8 to .Net 6. It took a while to prepare and to get the most obvious obstacles sorted before we touched the application.

We did an experiment with the .NET Upgrade Assistant to see if it would work with our solution. Unfortunately, the result was terrible. For the non-web projects, we got a long list of things to delete, but no advice on what to use instead for .Net 6. And for the web projects it only created the proxy project in .Net 6 and kept the .Net 4.8 web application in place. That would increase the complexity to run the application and the whole work for the migration was still a manual task – now spread over twice as many web applications.

Because of the importance of the application, we decided to do the migration by copying the files to new .Net 6 solutions. That allows us to keep delivering bugfixes and minor features for the .Net 4.8 application while we work on the migration.

One of the best ideas we had was to create Visual Studio project templates for all the project types we use. We did all the configuration in the template and referenced the most important dependencies. In the migration phase we could create new projects with everything in place, so that we did not waste time with the dependencies and could focus on the required code changes for .Net 6.

We used Roslyn and Python to create a sequence for migrating the projects so that the project dependencies are always fulfilled. That way every project can be compiled right after the migration. Should something go wrong, we know that it is a problem we need to fix right now and that it is most likely a discrepancy between .Net 4.8 and .Net 6.

 

The migration itself

We worked through our sequence and migrated one project at the time. The migration of a single project was basically this cycle of steps:

1. Create a new project with our project templates in the .Net 6 solution.
2. Add the project references as they were in .Net 4.8.
3. Copy all the files (except bin/, obj/, and Properties/) to the new project.
4. Compile the project.
5. Fix Errors if they showed up.
6. Run all tests.

That worked well for all non-web projects. The web projects we kept for last because we know that there would be the hard work.

 

The migration of the web applications

ASP.Net had massive changes in nearly every aspect of the framework, and we did run into many of them as we migrated our web components for the user interface a few months back. Even with that expectation we found plenty of new differences between the two versions of .Net.

Our BDD tests where an enormous help to check if everything worked as expected. We run them constantly and found many problems that only show up when a user interacts with the web application. Each new bug we discovered was frustrating, but it was us who found the problems, not our users.

 

Next

Next week we take a closer look at the nasty surprises we found in our migration. Not everything is in the .Net framework, the projects we depend on also had their fair share of inconsistencies.