Presumably you're talking about ASP.NET Core. Because the last major release of ASP.NET MVC is over 8 years old. I hope you're not replacing a dead technology with one that is on life support.
What you need to keep in mind is that monster has a decade of decisions, behaviours and subtle side effects that could be a nightmare to replicate in a new code base. Or those behaviours may even be completely undesired so are you prepared to discuss and negotiate with the business about the new requirements? Are you prepared to be told to keep the monolith, but fix the mess in it?
Also, how much of it is covered by tests? Are you confident that when you change something, you will know very easily if you broke something or not?
If the answer is yes, then great. The code may suck, but it works, so leave it. If the answer is no, then any non-trivial change will likely bring a world of pain. I would only change the bare minimum, and if possible I would try to write some tests before I make the change - to make sure I don't break anything. In fact, writing tests first, then refactoring, is the only good way of making changes to legacy code.
Unless you're given the green light to rewrite the system, with new business requirements, with old requirements dropped or updated, then your work should be more focused and low level, and should be done on a case by case basis. But even then the result would not be significantly different to what you have now, but rather a bit cleaner and more reliable.