It is really hard to imagine how someone could accumulate 6 MB of content into a single perl script and keep it functional (presuming it actually does still function on a system that still uses 5.8.x), let alone maintainable (which, as you are discovering, it is not). No single script should ever get that big. (update: this consideration applies to source code in any programming language, not just perl)

If you do still have a system running 5.8.x, and this script does still run (and does what it's supposed to do) on that system, I would recommend breaking the big script apart into smaller chunks, testing the "decomposed" version on the 5.8 system to make sure it produces the same results as the original, and port the multi-file version to the 5.10 system.

I would expect that in the process of splitting it up, you will find numerous opportunities to refactor the code and eliminate lots of repetitive content. (One sure way of making a script too long is to use the "copy/paste/modify" style of coding, whereby a few lines of code get repeated dozens of times with minor alterations, instead of being written once as a proper subroutine with sensible parameters.) The app as a whole is likely to end up much smaller as a result, and that would be a Good Thing.

One thing is for certain: if the code gets split into different source files, it will be a lot easier to isolate/locate problems.

If the app needs to be around for a while, I would argue that this is the only sane and sustainable strategy -- don't propagate the mistakes of the programmer who left this mess behind. If/when it needs to be migrated again, it'll be easier at that time if you make the effort to refactor it now. Otherwise, you'll just have to face the same problem again later.

One other thought: do you have access to a unix/linux box that you could try this out on? (Would it make sense to do that, or is the process really Windows-bound?) Options and tools for diagnosis, analysis and refactoring might be better in that other environment.