Backlog and Sprint Goal

I believe that you should first understand the organisations vision and where the product fits into it.  This should help you create your own vision for the product as well as a product goal which is the commitment to the product backlog and is included in the PB. 

Remember that the PO is accountable to maximise the value that the scrum team creates with each increment. 

To understand the current PBIs you should have the developers and stakeholders explain to you what the product actually does, etc. 

You may also wish to decide to remove any existing PBIs that are of a certain age, because if they are still important they will be requested against by the relevant stakeholder. 

During sprint planning, the scrum team come up with a sprint goal based on your product goal, and use that to select the relevant PBIs from the PB for placement into the sprint backlog. 

In order to develop a plan of action for each sprint, what is the recommended approach?

Agile practice is about mastering the ability to innovate by learning to build the right thing at the right time. Each Sprint is an opportunity to do so. What do you want to learn first about the product and the value it provides?

The first step is to become more acquainted with the product, the vision for the product (the Product Goal, if the organization has adopted the latest Scrum Guide), the key stakeholders, and any other elements of the context (such as legal, regulatory, industry, or business information). Since the Product Backlog is an ordered list of work that must be done to achieve value, it's important to understand what is valuable, who it's valuable to, and why it's valuable.

Once you have the right context, you can start to maintain the Product Backlog more effectively. 120 items isn't necessarily that big, but I'm not sure with how you are using "feature", "epic", and "user story". The Scrum Guide talks about "Product Backlog items", but there may be different ways to classify items depending on what they are. The ordering of the items depends on value, which requires the context that I mentioned. I will suggest making sure to consider the Developers as a stakeholder - having a lot of bugs or technical debt on the Product Backlog that isn't being addressed can have a significant impact on the team's ability to do other work.

How you go about ordering the Product Backlog depends a lot on the context and the vision for the product. There is no one-size-fits-all approach to how to get a handle on a backlog. Hopefully, the previous Product Owner did a decent job on backlog maintenance or there are still people who can help you understand the context and evaluate decisions until you have enough contextual knowledge to do so on your own.

You have gotten some great responses so far.  I'm going to give one slightly different. 

My suggestion to you is to stop looking at the type of items (story, bugs, epics, features, etc) and see them all equally as an item describing work that needs to be done to the product.   Understand the reason for the work being described and order them all to ensure that the work being done by the Developers will be delivering the right value. 

This is why I advocate that you have a single item type in your backlog.  When you enter them as different types, human nature is to treat them differently.  Empiricism will treat them all equally.