The .NET Upgrade Assistant does an excellent job of updating your classic .Net Framework projects to target the new .NET binaries. It is not a "fire-and-forget" process, however, and you will want to watch out for these common issues.
Old Package References
If the Upgrade Assistant can't find a version of a Nuget package that targets your chosen framework, it will keep the old version if it is binary compatible with the target version. This means your app will compile and run inside Visual Studio, but it will potentially be using libraries that target the .Net Framework.
Delegate.BeginInvoke Is Deprecated
Delegate.BeginInvoke is a pretty old construct at this point, but it was heavily used in the past and likely exists in thousands of code bases. The summary is that APM has been replaced by TAP and APM was not brought forward in .NET Core/5/6/7.
This article does an excellent job of explaining the details so I won't duplicate Mike's amazing explanation.
Project File Crud
On top of whatever legacy tags might already exist in your project files, the upgrade process may add some more that you didn't want. After your upgrade is complete, open the csproj files with a text editor and remove any fields you don't want moving forward. Now is the best time to do it as it might expose some features or flags you weren't aware of. Here are some examples:
The Upgrade Assistant analyzers are added by default.
ASP.NET in Non-Web Projects
If your desktop app references any ASP.NET libraries, the Upgrade Assistant may think your project is a web project. Since .NET is more modular than the .Net Framework, you will only want to make these references intentionally.
You might have been using Windows Forms without realizing it.
Code analysis rulesets might come along for the ride.
Nullable
After creating the final versions of your upgraded projects, you should work with your team to set a Nullable strategy moving forward. In my opinion, this is one of the most significant changes to .NET since version 3.5.
Assembly Versions
Okay, here's a trick question. What will the version number of the compiled assembly (dll) below be?
The answer is whatever is in the legacy AssemblyInfo.cs file. By default, the AssemblyInfo.cs files are used but you can still add the version numbers to the project file without generating errors. This can be confusing at first and lead to errors on build servers. The GenerateAssemblyInfo tag determines which source to use.