After ... please, please, please ... this posting has been edited to use code-tags and other tags as spelled out in “Markup in the Monastery” ....

... I approach problems like this one by further breaking-down the code into individual subroutines which are called by higher-level code in a meaningful way.   I also try to encapsulate, to eliminate if possible, and in any case to isolate, global variables.   I want the “visibility” of data is as compartmentalized as possible.

But you also need to start, from the very beginning, by constructing test cases which will represent the actual behavior of this module so that you can run both the original version and the rewritten version in parallel and objectively demonstrate that they are functionally identical.   You need to do the entire effort using a version-control system (such as git, which doesn’t require any server), because you need to carefully document each change and to be able to reliably restore the system to any prior state.   (You also need to be able to “experiment,” which branches allow you to do, and to “tag” specific revisions that have or have not passed the suite of validation tests.)

One thing that is working in your favor in this case is the fact that the existing code appears to be very well documented.   I suggest that you should, before you start the reconstruction process, build a project-plan for yourself, and follow it.   Keep a daily “running log,” or diary, and keep it scrupulously up to date.