This might not have been a great idea, I'm fairly surprised nobody stopped you before you went through with it.
4.8 is the "final" version of .NET Framework. It's pretty much the longest "Long Term Support" offer Microsoft will ever give for a platform, realistically they'll be supporting it into 2030 and beyond. I'd not start any new projects in it, but upgrading away from it probably wouldn't be the first thing I'd do on a new project.
From .NET5, the framework moved to fundamentally different approach. It's effectively a different framework with the same NET branding on it. Most organisations who decided to move from 4.X to 6.X went through a near total rewrite because the paradigm shift is so massive, lots of organisations decided to stick with the pre-5 versions. The architecture and technology choices probably make a lot more sense in the pre-5 version of .NET, and it's unsurprising that your colleagues are frustrated with this decision, irrespective of the quality of their code.
On top of the move between .NET paradigms, you've moved away from a long-term-support version. NET7 is an 18month short-term-support interim release between two Long Term Support 36month versions .NET6 and .NET8. By moving to 7, you've trapped the company into an early & rapid upgrade path to .NET8 as soon as it comes out in Nov 2023, rather than giving the full 12 month buffer you'd have got if you moved to .NET6, which is in Long Term Support until Nov 2024. You moved the application off of a rock-solid framework with near infinite long-term-support, onto a framework that'll be deprecated before in four months, and out of support entirely in ten.
If I were you, I'd probably not be bringing this decision up in any performance reviews or interviews at new companies.
We moved from 4.8 to 7 because a) the better compiler warnings helped to reduce the amount of shit people where able to check-in AND highlight problems in the existing codebase (beyond "well, it looks like written by the lowest bidder offshore guy drunken on Friday night") and provide management with metrics they could understand (two warnings per LOC is part of your problem). B) it deepened our hiring pool, because it's easier to find people willing to work with current technologies than legacy. C) it allowed us to pull in various modern libraries (BLe especially) which made whole swathes of swamp code irrelevant. D) allowed us to establish a sane Ci/CD Pipeline more easily which we needed to reject bad stuff. F) we ship this product every few months, so not being on lts is not really a problem.
But this crowd believed it obviously. The chief perpetrators already left when I got there, so I could not ask directly. Zero tests, zero documentation and a coding style like somebody tried to write pure C in c#.
Sure it compiles. But often it crashes without rhyme or reason and for some reason, customers hate it.
First thing I did was to get it from .net 4.8 to .net 7 and enable all available errors checkers and style linters.
The other howled, but their builds stopped because they could no longer check-in crap. That helped. But fixing this is more work than what this would have needed if they had done it right the first time.
Funny examples: reinvanted rabbitmw badly using raw TCP and XML. Better hope your network is good, If the messages arrive at the same time, they are merged and the app crashes. So there are lots of time.sleep(50) calls to avoid that. Why is that app slow?
The iot devices can only address 254 states. The UI for that allows ulong devices. It's never checked, but if the vast fails, the app just crashes.