Java pattern for refactoring abused MVC controller class

So I inherited this spaghetti back end service code base which has probably 10 years of history, it is written in Java and maven.
the original author put tons of stuff in a RequestController class, which has functions like

processPostRequestV1
processPostRequestV2
....
processPostRequestV6

and

getRequestV1
getRequestV2
...
getRequestV6

and all the utility functions in just this one class.

they all read and write to the same DB (thank god), but this class has close to 20 dependent beans and 3000 lines of code.

I am wondering, what is the best pattern for refactoring this kind of code, it seems to be a orchestration layer, but what pattern should be used to manage the versions for it? (some of the versions don't even make sense, e.g. code from older version is sharing code with new one, using new dependencies etc, but that is a different matter)

In a MVC pattern, controller is supposed to gather/update data from the Model/Business layer which looks exactly like what this RequestController class is doing, what am I missing here?

First of all... Do you have tests for that class? Test that you trust? If not, do not refactor. Write the tests first.

Because refactoring means

> Change the structure of code without it's behavior

If you have tests I would create a the new structure and change the RequestController class's methods to delegate to the new structure.

Maybe the new structure is something like the clean architecture, the BCE (boundary controller entity) or the hexagonal architecture.

In case of the clean architecture. The RequestController will pass request models through the use case's input boundary and pass the use case an output boundary that the request controller will adapt to return the result.

Take a look at https://softwareengineering.stackexchange.com/questions/388578/clean-architecture-is-the-input-boundary-necessary