Well, Perl gives you several different ways to “split a program into multiple modules,” and (especially when dealing with older, legacy applications) it can be hard to “usefully generalize” such things.   Instead of trying to go for a cross-referencing tool or any sort of “[automated] refactoring” tool ... instead of chasing seriously after what’s likely to be a white-rabbit ... I would simply look at each of the subs that are known to be provided by, say, lib1, and use “good ol’grep -iw” to chase-down occurrences, one at a time.   Look at the use lib1 statements ... do they specify qw(subroutine names)?   Is the lib1::subroutine nomenclature being used?

And, finally but most-importantly, “where and how does it hurt?”   If you decided that you only had time and resources to commit to changing 20% of the occurrences, which 20% would it be, and why?

“Refactoring” kinda makes me nervous, like the billboards that I see advertising “iLipo-suction.”   The billboards always feature a curvaceous model who obviously never required liposuction in her life, and promise that the procedure can be done “without downtime.”   Well, I know of someone who died from liposuction:   merely putting an “i-” in front of it does not make it risk-free, nor painless.   And, likewise, I’ve seen some pretty-stable applications which became extremely unstable as a result of “refactoring” that sought to address an “issue” that, in the grand scheme, really didn’t exist.   I would suggest approaching the task very deliberately, and manually, bearing in mind that the task must include a comprehensive test-suite to prove both present-state and future-state.   Don’t attempt to refactor 100%.   Seek the 20% that can be shown to make 80% of the business difference with 5% of the risk.   Identify those pieces, and what you intend to do with them, and how you intend to prove the work, first.