The first thing you need is a test environment. You *really need to build a test environment* to pull this thing off, since:

• Testing in production is no option
• The risk to introduce bugs while fixing is very high
• You need to test to understand the program
• Building a test environment will make you understand your inputs and outputs
• You will be the one to blame after you touched this thing, so you better be able to explain its functionality exactly, and to demonstrate it can do what you advertise
• Building a test environment will make you understand your limits in fixing this thing, so you can advertise them to your superiors, or even pull out of the operation

After you have the test environment, you can start to refactor using one of the strategies outlined above. But I honestly warn you to touch this thing or assume any responsibility for it unless you are allowed the time to construct a test environment. If they won't allow you to build this, they are not looking for a solution, but for a scapegoat. Decide if you want to be this scapegoat. If people actively resist sensible approaches to problem solution, the best strategy is to get out of their reach and to document your reasons for doing so.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com