I have the exact same situation with OSX: there is a native perl that system relies on and my own updated version. perlbrew was the way to go for me.

Now, use of perlbrew, requires to set an env-var and use #!/usr/bin/env perl as the shebang of all your perl scripts. Do you have to mess with system's perl scripts, or Apache's etc. and change their shebangs to this new env thingy? Most likely no. This is just a warning from me and very likely a false alarm!

Because from my experience on OSX, I use perlbrew but the system still uses its own perl without me ever needed to mess with system's shebangs. So, in my case perlbrew works as I and the system expect it, but you should confirm that perlbrew will not require you to change anything in system's perl scripts neither require Apache or cron or whatever to setup perlbrew-specific env-vars.

Btw, this came up in a search : https://stackoverflow.com/questions/4764025/how-to-specify-which-version-of-perl-to-use-on-centos

Second caveat is of course the use of perl-command switches in the shebang (e.g. #!/usr/bin/perl -w). You will find that your new shebang #!/usr/bin/env perl -w does not work in linux (expected behaviour, you must remove the '-w' at the end and find a way to put it somewhere else. Where? Someone knows a definite guide on this?) but works in OSX (BSD-based), see here: shebang anomaly

Once using perlbrew, you may also want to install modules using cpanm (App::Cpanminus) rather than cpan. Great program! Transparent and efficient: cpanm install Test::More

Alternatively and for the sake of completeness, I mention update-alternatives. It is the linux-specific way to handle multiple versions of the same program, e.g. gcc. I have used it with gcc and java and never had any problem. Though I never bothered to learn more about it than copy-paste some one-liners from net. I assume it can handle all these because gcc/java, just like perl, rely on other programs, libraries, installation paths etc.