While Perl's design philosophy has aimed to maintain backward compatibility as much as possible, there are conditions that may be problematic. I started to list them, and realized that the more I listed the more I was coming up with, and that listing them isn't the right approach.
The right approach is to set up a test server with your new environment installed on it, migrate the app, and begin testing. Hopefully a good test suite is in place for the application. If not, you're going to have to get started on implementing that as well.
Ok, I can't resist... here's a massively incomplete list of potential issues. It may also be massively hyped. ;)
- Modules that were part of the Perl core as of 5.8 have been dropped as of more recent versions of Perl.
- Modules that implement some feature now don't implement that feature anymore.
- XS modules may fail spectacularly, as the XS/guts/perlapi spec has changed little by little over the past decade.
- Handling of Unicode, and even the utf8 pragma have changed over the past decade or so.
- Hash randomization ordering has changed. Code that relies on some form of consistency may break.
- External shared libraries that some XS module wraps may have changed over the years in ways that are incompatible. A newer XS-module with an older external library, or vice versa may be problematic.
- If the program uses pseudo-hashes or some other obscure feature of 5.8, it will probably break under versions of Perl that have eliminated that obscure feature.
- Some special variables such as $* have changed or been eliminated.
- Bug fixes along the way may also have created undiscovered bugs.
At minimum you must test in a non-production setting.