I've unfortunately been involved in similar situations a few too many times

The best advice I can give is to keep the two systems running in parallel for testing, and get all stakeholders to sign off on their parts before the final migration.

I don't know what the motivation is for switching, and what your schedule is like, but depending on just how bad the things are you're dealing with, it might be worth trying to upgrade the FreeBSD box (in terms of hardware) to buy yourself a little more time -- if you have to move to a new system, just copy the binaries directly.

For the eventual Solaris migration, I'd also suggest trying to mirror the modules versions from the old system as closely as possible. (if you've been using CPAN for your installs, you should have an install log) You don't want to mess with the perl that's installed by Solaris, or you can potentially break some of their management scripts. (at least you would under Solaris 8 and 9, I've never played w/ 10).

Oh -- and when your boss insists that you make a full tape backup of the system before you move the new one online -- remind him that the old stuff is still online (maybe under a different IP address), so you don't turn a 5 minute outage into a multi-hour outage. (there were reasons we were upgrading ... like only having a 10BT interface)

Once you get it migrated over, then I'll second the recommendation of looking at Perl Medic, as you probably have a deadline that keeps you from following the suggestion before.

And try to keep the old system up for as long as possible -- Finding out that it never worked on the old system can keep you from wasting a week and/or having to deal with a manager chewing you out for something that's not your fault.

Update: this was on my mind because I've done these sorts of upgrades more times than I'd like (5? 6? ... I think I've managed to block a few out) ... so let's look at the specific issues:

There are approximately 300 scripts, spread across several directories, and none of the scripts contains either of the lines: use strict; use warnings;

Unless you get to set the schedule, don't worry about this. Find someone willing to sign off on each script, and don't try to fit the scripts now. Odds are, they're broken in some way, but they've been that way since before you got them -- you can only hope that they don't break worse when the version of perl and any used modules change.

Code has been replicated for each operational area, and each common script has been modified to support the specific aspects of its corresponding functional area

You can modularize it after the move. Unless you want this move to take a year, treat it like the last one.

Subroutines that have been repeatly cut and pasted, and then further modified

Again, don't worry about this one now -- treat it like the others.

Paths and filenames have been hardcoded

Okay, this one's a problem. You really need to get some symlinks in to make the old pathing still translate. If you can't get your sysadmin to fix it, get them to sign off on the fact they're refusing to make the change. You do not want to screw with these things if you don't have to. If the sysadmins don't cooperate, see the next one.

Some system/backtick calls will need need to tailored to Solaris10

This one's the only one that must be dealt with in some way. To some level, if you know what programs they're calling, and it's just a few executables, but a lot of perl scripts, you can adjust the path, and place a few wrappers in there to take the old calling syntax and align it with the solaris usage. (or you can compile the GNU, or whatever versions -- one of the uses of the FreeBSD ports collection)

If there are relatively few perl scripts compared to the number of external commands being called, you're SOL -- the following might help: find ./ -type f | xargs egrep '`|\bexec\b|\bsystem\b' | grep ':' | cut -d: -f1 | uniq | xargs vi (insert your favorite editor for 'vi')

No unit tests are available

Treat it like the first few -- get someone else to sign off on it. Unless you're luckier than I've been, management will be breathing down your neck, and you'll not be able to capture all of the necessary business logic before the move -- deal with it afterwards.