You are not alone. Throughout my business life I have worked with old code written by someone else (To be honest, I've hardly ever written new code).

As others have recommended, a good set of tests is absolutely necessary for such a refactoring. Old code is often battle hardened: It covers some edge cases in ways which are hard to understand because back then it seemed to be the easiest way to fix a long forgotten bug. Probably you'll need to write a lot of tests before even writing the first line of your new code.

I also recommend to refactor only when you have a concrete goal in mind: Some new feature, better security, whatever. Don't write the feature right now, but think about how you would like to integrate the new feature, if only the old code would allow it. Then refactor the relevant parts of the old code, still without changing its behavior - and only when you're done with that, add the new feature. Or, in other words: Don't refactor just for the fun of refactoring. Subroutines with more than 100 lines aren't immoral.

The details depend on the ecosystem of the code:

• Does the code have a test suite? Unit tests and/or application tests? Good. Still, add your own tests. This will go a long way to understand the old code. The test coverage can also be helpful to decide where to start.
• Do you have a source code repository? Good. Does it contain good commit messages? Even better. Reading those together with the old code can help to avoid re-introducing bugs, because that's really embarrassing. If your code dosn't have a source code repository, start one. Also, grow the habit to write good commit messages: If you are new to the code, you might want to revisit your first decisions when you're more familiar with it.

So, to sum it up, my recommendation is: Don't focus on the code alone. Improve the ecosystem as well: Documentation, tests, tools. If the old code is still relevant (why else would you have to work with it?), then there are chances that you need to pass it to someone else in the future.