You do the same thing you do when you walk into a workplace where your predecessor is unavailable.
First you look for any requirements documents and read them if available. If the predecessor never got any training on the requirements, it may be possible these don't exist.
Then you prioritize learning based on the areas most commonly changed (your source control can help you here) and most important to the business (your users can help you here and your manager) and the current items in the queue for support. Everything else can be learned as it comes up. Once you have a list, discuss the priority of learning with your boss.
Take those things, read the code for the sections in priority order and try to understand what it does right now. Document that. Discuss what you found with users, account managers, business analysts, your boss, whoever the stakeholders are. In an undocumented system, you are likely to find that what the code does and what the users think it does are two very different things. Do not change the code based on these documents without an official request in your ticketing system. If things are very far off, set up a meeting to discuss that and what should be done about it, but it is up to the business to decide if they want to make a change at this time.