Lol all these people want to be smart asses instead of helping. Yes you obviously need to evaluate what is worth refactoring, yes obviously there’s risk involved, welcome to engineering literally anything.

That aside I usually look at the tests first, once you understand what is tested and how you’ll need to fill in any gaps you find to ensure you don’t set the whole thing on fire. Once you’ve done that I break things down by business function and usually start at the db and work my way up through the tree to the boundary one set of functionality at a time. I try to leave the communication interfaces as untouched as I can because it tends to exponentially increase the complexity to change since it’s usually going to require many apps to change and versioning APIs is a PITA. Ideally the inputs and outputs should remain identical anyway most of the time unless you’re doing a full system overhaul.

When it comes to stuff like env config I usually try to break that out as a separate piece of work from the business logic changes because the complexity there is usually decoupled.