Mind you, refactoring can happen at a fairly high level -- if you identify the worst, most broken part of the code and first lock down/simplify its interfaces, you can write a drop-in replacement for that whole chunk. Just remember that if writing your drop-in replacement is going to take weeks (rather than days)... or if your estimate keeps sliding..., you've probably chosen too large a chunk and should slice & dice a bit more.
I've had this discussion so many times that now I just have it with myself, and generally only say aloud the correct answer (though it's disappointing).
Psychologically, it's a beautiful thing to wipe the slate clean and just do everything fresh from the start. If only this worked as planned more often (and budgets were hefty enough to support "doing it right", and there were not already a user base who actually wanted to keep some of the broken bits because they knew how to use them already, and you didn't have to deal with a few team members who seemed to always be writing more code just like the old stuff, etc etc)...
One major way to tell: can you clearly specify what the revised version should be doing, in a way that doesn't involve "whatever the old version did"? Another litmus test: do you fully understand the old code and why it sucks the way that it does?