Struggling with legacy code maintenance tasks?

I would stress the last part: Legacy code is not only bad. It is working code that obviously has solved business problems for a long time. Very often, the underlying business rules and requirements can only be found in the software because of lack of documentation. While technically there are many problems, you should never disregard that this software has value and that you must keep the relevant value (there is likely code for obsolete requirements as well) when transforming the old solution or migrating to a new one.

In my experience the risk of introducing bugs is the highest. There are simple refactorings (like upgrading dependencies). However, if you need a rewrite (for example because you want to move to another programming language or framework) then things get more tricky. Furthermore, isolation and modularization in old software is often not adequate. The first changes should isolate the areas that you want to change, establish clear interfaces and APIs before you move onward.

Documentation can be concerned with the "what" (i.e., code structure, modules, algorithms), and the "why" (decision reasoning). Most important is to document the "why", because you cannot re-create it. I likely have forgotten why I decided something after 3 months. So the hardest part in understanding and documenting a legacy application is the why. Try to find people having worked with the code to give you at least some important reasons why things are the way they are. Otherwise, you will likely encounter the hard way why these structures were chosen.

In my experience having good, automated tests is the most important thing. Creating these tests can be a good way to understand the code base but they take time to create. Project managers often don't like this, but good automated (unit) tests make changes later on less risky and will pay off quickly.