It is a tough call.

Obligatory Joel reference: [Things You Should Never Do, Part I][1]

That said, there are of course cases when it is still better to rewrite from scratch than to keep fixing the fundamentally broken. Causes I can think of:

- there are no automated tests,
- the original project team is gone, and noone knows how the product is implemented, thus making any changes is incredibly difficult and results are unpredictable,
- the product is so low quality that replacing it with a new, bug-fested implementation would not make a major difference,
- the technology used is so obsolete, there is a pressing need to replace it with something new (e.g. in order to support some desired major feature).

If all of these applies to your case, you probably have a reason to rewrite from scratch. (If only some... well, that's the tough one to decide, especially with the little information you told us.) At any rate, you would also need the following conditions to give you at least a chance of making such a move successful:

- time-to-market is not a point - customers are patient enough to wait a looong time for a promised, fundamentally better version,
- there exists live, detailed knowledge (ideally in well written specifications, but also in several people's heads) on how the damn thing should actually behave in any specific situation,
- management is at least open to the idea, and ideally they understand the potential costs vs benefits.

All in all, you must take into account that rewriting from scratch is going to take a *lot* more time, effort and pain than anticipated.


  [1]: http://joelonsoftware.com/articles/fog0000000069.html