Rewriting a project of this size is doomed to fail due to the reasons in Michael Kohne's post.

Refactoring a buggy codebase is difficult because you'll never know if bugs are due to your refactoring or due to the original code.

I would take the approach of doing nothing but bug fixes for a significant period of time. As part of these bug fixes, you can rewrite small sections that are blatantly wrong. The benefits of this are:

1. Gives the developers the opportunity to learn a lot about the code, architecture, and product behavior. You will need this knowledge to do any significant refactoring.
2. Stabilizes the codebase prior to any major restructuring work.
3. You can sell the stabilized product while major changes are made later.

Rewriting a project of this size is doomed to fail due to the reasons in Michael Kohne's post.

Refactoring a buggy codebase is difficult because you'll never know if bugs are due to your refactoring or due to the original code.

I would take the approach of doing nothing but bug fixes for a significant period of time. As part of these bug fixes, you can rewrite small sections that are blatantly wrong. The benefits of this are:

1. Gives the developers the opportunity to learn a lot about the code, architecture, and product behavior. You will need this knowledge to do any significant refactoring.
2. Stabilizes the codebase prior to any major restructuring work.
3. You can sell the stabilized product while major changes are made later.

It also sounds like you desperately need a bug tracking system and some sort of QA to find bugs & verify fixes.