Start with a base installation of the Perl of choice – probably ActiveState because of the availability of paid support – then carefully inventory all of the packages that are now installed on the old system which do not appear on the new, and which cannot be obtained directly from the installation vendor. These will need to be installed using conventional cpanm techniques, and there are a few main issues here:
- Many Perl packages make use of underlying binary libraries using so-called XS technology. All packages must be installed through cpanm from the latest available sources. Binaries may be compiled on the target. You cannot simply copy the Perl library directories, for this and other reasons.
- Some packages rely on third-party binary libraries (e.g. libxml2) which they obtain in object-code form, and a different version of that library is likely to have been used. But these differences should have been taken care of for you.
- Hopefully, none of the Perl packages upon which you now rely have been deprecated, and all of them have been actively maintained – but, check them one-by-one to make sure.
- Unlike PHP (grrr...), Perl package-makers are usually very good at maintaining backward compatibility with the past, but you should carefully review the release-logs in search of any signs of trouble.
- I strongly recommend that your new Perl target should be 64-bit to reflect the native architecture of the underlying OS. Hopefully your programmers didn’t play games with pack/unpack or freeze/thaw.
- If your application interacts with the OS environment e.g. the Registry, expect trouble, since the security architecture has changed considerably. Your application might encounter (e.g.) permissions issues that may or may not be related to the Perl source-code. If your application runs under say, IIS, there are many differences there.