Usually there is some very-important production system that is absolutely dependent, source-code wise, on some early version of Perl.   What I suggest that people should do in that case is to define an environment-variable in the production context, named, say, $PERL_CMD.   This variable is hard-coded to the Perl interpreter needed by this program, which, in turn, has been hard configured to refer to an isolated set of CPAN libraries which it, itself, has built ... i.e. without resorting to PERL5LIB, which of course also is given a known value.   Every script invokes Perl by reference to $PERL_CMD.   What you achieve by doing this is to isolate the Perl that this system relies-on from the system at large.   You include all of the scripts, and all of the documentation, in the source-code control system tree for that app.

This, if done correctly, relieves you from the obligation to keep “the system at large” at an older level, and it also circumvents any interdependency between two similar apps that might both need to run on the same boxes.   The only “cost,” which becomes inconsequential through the use of SANs and so-forth, is disk space.

It does get a little bit more interesting when the distro-maintenance software for a Linux system also runs in Perl, as many do.   To handle this case, newer versions of Perl can be set up in /usr/local/whatever.   It does, alas, get a little bit messy at times.