When I've implemented large scale re-factoring on projects, I've generally used the strategy of doing the architecture afresh, and proving the architecture first, whilst development continues on the original project. When the new architecture has been proven, there is a large amount of transferring existing logic to the new architecture. This seems to be best done quickly, rather than as a background task.
Is it worth doing? That's a difficult one to judge without being there on the project but think about these issues:
Is the existing code base stable and bug free? If you are having to spend significant time finding and patching the existing code without really understanding it, the time saved by a reduction in support by reimplementing using understood code can be significant.
Do you have at least as much knowledge of the product as the original coders? How much of the complexity is due to bug fixes for unexpected situations, and how much was poor design?
Do you have the time to finish the task? One of the things I value most about a code base is consistency. Inconsistent code is a nightmare to support, extend and introduce to new members of the team.
If you have not got a substantial understanding of the products business rules, you are likely to do worse job than the current version.
Conclusion - based on the questions updates, is that you do not have enough knowledge of the project to do a re-implementation. In your current situation, even doing a significant re-factor is risky. The good news at least, is that the current customers are not hit with bugs that prevent them from using the product, which means you have time to understand the code base. This needs to be your first goal.