While I understand there are times when you can't get around it, I
really hate maintaining legacy perl trees. This tends to work ok if the machine's environment is relatively static. The problem I've seen with this is that as you upgrade the machine's OS, C compiler, libraries, etc then legacy code becomes more and more brittle and can eventually break in some hard to detect/fix way. Worse, if you need that upgrade to keep your newer code running smoothly, you now have a dilema (e.g. downgrade and workaround it; keep the upgrade, reinstall the old perl tree, and hope it works).
I tend to compromise on this by keeping two versions of perl -- the vendor's ancient perl (/usr/bin/perl); and my own in it's own tree where I symlink to it from /usr/local/bin/perl. Any script that uses /usr/local/bin/perl tacitly agrees it will work with newer versions of perl. When I rebuild perl in a new tree, I make sure the modules in the old tree are installed in the new one as well. This allows me to move the tree easily to similar machines once it's configured properly.
Of course, in order to actually verify that the older code works with a newer perl, it needs to be easily testable. This is where a test suite is crucial, and may actually be worth adding to your legacy code if you don't already have one. If it's not possible, you may be able to make a similar policy that you only support perl versions x and y and that any new code must have a test suite.
