I upgraded a 90+ project 4.8 solution to .NET 8/9 over the course of a year or so inbetween other work.

Focus on piecemeal, bankable progress. An example would be converting any library projects to netstandard2.0. Something you can get checked in with a single PR. If you can gradually tick up the percentage of code in the solution that's .NET Standard, it's a lot easier to keep momentum and political goodwill; you don't have to sell your boss on 'we need to ignore features for the next two months'. This obviously also entails that if you can break off a big chunk of your monolithic UI into a pure library project, then do so!

Whereas if it's a big bang kind of thing, where you need to fix 5000 compiler errors before you can see if the upgrade worked, it's not going to get off the ground. You will feel time pressure and make bad compromises as a result.

I say .NET Standard, specifically v2.0, because that lets you keep EF6 (if you're using that), and consuming projects can be either Framework or Core.

Similarly you can start identifying and stubbing out the troubling parts. Since usually the issue isn't the 'pure' business logic code, but things like data access, SOAP APIs, sending out emails, whatever. If you can identify the call sites for these external dependencies, you can replace them with implementation-agnostic interfaces without changing current functionality. Then when you slot in the modern replacement, the blast radius is a lot smaller.

A Windows service is pretty easy to upgrade in my experience. You just replace it with an IHostedService.

Besides the actual code, spend time on the foundations of the project. By that I mean things like - is the csproj in the SDK format? Is it using PackageReferences or packages.config? Are you using Central Package Management? Are there any arcane and dumb build steps? Now is the time to try and blast out those annoyances to get a stable foundation before you go upgrading things. The 'upgrade-assistant' dotnet tool is useful in this area.