Find out who wrote the code and be nice to them.
Offer to buy them lunch. Pick their brains. Learn all about them.
Were they accomplished programmers or newbies when they wrote the system? Are they careful or slapdash?
Are they domain experts?
What was the political climate when they wrote the system?
No matter how well documented a system, there is
always extra important information and ideas
available only inside the original designer's head.
As you understand a section of code, comment it.
If you see something that looks dubious, mark it with XXX, say.
You can come back to these XXXs when you better understand the
system as a whole and have more time.
Whenever you find a bug in the system, write a test for it.
Grow the test suite over time. I assume (like me) you will
not be given time to write a comprehensive test suite before
taking over maintenance of the code base.
See also Analyzing large Perl code base. and the book Perl Medic by Peter Scott.