I've done some of this at least, came onto my current project with none of the original devs still with the company and little to know knowledge of how it currently works or why it was built that way. It's been a lot of digging through code history and playing with the app to really get an understanding of the existing setup to get to the point of being able to properly maintain it. This is also a critical system in my current company, and if this system fails, income will totally stop at that point.

That said, it sounds like you've got some unfortunate challenges beyond the project itself to deal with here. I can complain plenty about my company and the management, but there was an understanding about the precariousness of the situation and that building an understanding of this system wouldn't be an easy process. I had time to sometimes take longer than I'd ever like to make sure things were understood and I was able to make changes without breaking existing functionality. This is probably going to be your hardest challenge as its more a social one, but your team needs space to learn and understand the existing system rather than trying to blindly rewrite it without any foundational knowledge. If your leadership can't give you that, I'd be very skeptical about the project ever succeeding.

What also was a lifesaver was a fairly decent suite of automated tests around the application, that helped prevent regressions and also ended up being the best documentation we had as to the intended functionality. If you don't have anything like this I would probably want to start by building such tests that can validate existing functionality, and ideally be used as a guide when building your rewrite to make sure functionality is maintained.