I'm going to address each of these in a separate comment.

1. The reason I'd want one file is to make it easier to admin when updates are made available, which happens often.

   This is a fallacy. It's actually easier to manage changes made to very small items that are independent from one another. That way, you know that the change's impact is limited to a very small area. This is called decoupling, and it is an extremely important concept in change manamagement.

2. Testing can be done easier by simply running a separately named script.

   It is much easier to test small, independent items than it is to test a big complex thing. For one thing, you can more easily determine what the failure cases are. Plus, if you have a monolithic thing, you have to take into account every interaction every time you make a change. If you have a bunch of small, decoupled bits of code, you only have to worry about how the one piece you're looking at behaves. It's easier to work with 100 lines at a time than 10,000 lines.

3. The script and supporting files are hardcoded to run out of a specific directory, ...

   Just because it's only ever going to run with one set of parameters doesn't mean you should limit yourself to that. Hard-coding is almost never good, outside of a configuration file. For one thing, you can't test the code outside of a production environment. If you have a configuration file, you can test in a temporary directory and feel confident that it will work in the production directory.

I once spent two days adding configuration to a database connection class so that I could test it. I've yet to actually work with more than one database, but the ability to add 300 tests was absolutely critical. For one thing, I fixed a bug that had been annoying me (and my users) for three months. Impossible to do if I had to work directly with the database. (As in, impossible for me to make the effort to do it, not impossible from a technical sense.)

I'd be humiliated if I had to admit that I wrote it.

Undoubtedly we've all written code that a few years later we look back on and regret decisions made. It's important to remember that the code is what's evaluated and not the person.

It sounds like you have two issues to deal with (if I can guess at what's behind your questions). The first is how to improve the code. The second is how to implement a test suite or test process. Those are both broad topics and Super Search on 'Refactoring' and 'Test Suite' should give you good reading.

Testing can be done easier by simply running a separately named script. The script and supporting files are hardcoded to run out of a specific directory, so I cannot create a new one with updated module files.

perl's -I switch exists to get around this problem. Use it to specify which directory to use modules from for testing.