Me, myself, and I, have been both a producer and maintainer of legacy code. If your tool's generating "thousands of violations" (or even hundreds for that matter), forget the tool, it's inapplicable to the situation...
I assume the original developers are long gone and unavailable for discussion. So nobody's around who understands the why's and wherefore's of the design and coding style. Correcting hundreds or thousands of violations isn't going to be a matter of rewriting a few lines of code here and there. Instead, it undoubtedly requires refactoring/re-functional-decomposition. You try doing that to any large existing codebase, without intimately understanding its current design, and you're bound to introduce a whole new set of bugs/problems/etc. Just a new can of worms even worse than the one you now have (or worse than your tool >>thinks<< you now have).
The only sensible approach to address "thousands of violations" would be to rewrite from scratch. A long and expensive effort, and almost impossible to sell to management. And in this case they're probably right...
Legacy code typically just requires tweaks. Like for y2k, or when stocks went from 256th's to decimal. I did loads of both that cr*p. And lots of other similar stuff. It's typically pretty "pinpoint" in that you can "read through" the sometimes-bad style, bad functional decomposition, bad etc, and locate the collection of places that need to be modified. And then, what happens "between those places", i.e., what's the more high-level flow, can remain a mystery to you. Just make sure you understand the localized functionality you are changing, and then test, test, test for any side-effects, etc, your localized knowledge won't be able to anticipate.
If you're unable to see your way through code like that, then you may not be the best person to maintain legacy code. Some people can start with a blank screen and write beautiful programs, but can't start with a large codebase of other people's code and maintain it. Other people can maintain code, but can't start from scratch. Some can do both. Make sure the right people are maintaining your legacy code.
The occasional times you might want to redesign and rewrite your legacy codebase from scratch is when the business (or other) requirements change to such an extent that seat-of-the-pants "tweaks" just can't accommodate the changed requirements any longer. And at that point, you might as well just start off by writing a new functional requirements document in the first place, making sure all stakeholders are on-board. It's basically a whole new ballgame.
The one-and-only >>wrong<< thing to do is try treating legacy code maintenance the same way you'd go about new development. And that one wrong thing seems to be exactly the path you'd like to go down:) Take my word for it, that ain't what you want to do.