The basic criteria will probably be the time ( = money).
The estimation is always hard when something is big. Split it to the smallest chunks.
Mind the point of view. Your estimation will probably differ from the estimation of the previous programmers, as it will be biased by the style you prefer. Maybe a better choice would be to hire the previous programmers to "fix" the code.
Anyways, you should state the minimum requirements to call the app well written and easy to maintain, discuss this with the boss and the team, split to smallest possible sprints and estimate the time required for all of them.
If you are able to convince your boss that the rewrite will return in better ROI overall, do rewrite. Otherwise, learn the "new style". If you have the comfort to stop the business for the time of the rewrite, or a spare time to do it, you're lucky. You're even more lucky if the code is testable, or you have at least some unit tests. If this is not possible, you should implement functional tests at least to help with both cases (refactoring or rewrite).
Note, that each one of us will probably prefer to rewrite from scratch, than to refactor. Then rewrite this rewritten...
So refactoring is always a good choice, assuming you already have tests or you are able to easily implement the tests.