The reality is that the business side of the company will only release funds for patching code, not for doing wholesale rewrites from scratch. But we are hoping that over time we can adopt a strategy to improve the code in fundamental ways over the next few years.

It sounds, (on the basis of very scant information, I may well be jumping to the wrong conclusion), like you are trying to expand what is primarily a maintenance role, into something more. Whilst I fully understand that motivation, I've been there myself, I strongly urge you to proceed with extreme caution.

If you break something during the process of refactoring for the sake of 'improving the codebase', or 'fixing' something that hasn't been explicitly documented as broken--by the owners or users of the codebase, not you or your team--then your good intentions will not save you from their wrath.

• Your very first priority should be to make sure that you get the code--every last line of it--into a version control system (VCS) if it isn't already.

  And if it is, make sure that a very clear checkpoint is made before you touch anything. Even supposedly benign things like beautifying with PerlTidy.

• Next, you need to set up regression tests.

  I'm not talking about cutesy ok/not ok one-liners. It is almost impossible to safely apply unit and functional verification tests to an existing codebase. Even if the code has been meticulously commented and/or documented, what they say the code does, and what it actually does are nearly always two quite different things.

  All code contains bugs. And in an established system, both up-stream and down-stream processes will have knowingly or inadvertently been constructed so as to work with or around those bugs. The simple act of correcting something obviously wrong in your part of the process can bring the system down around your ears.

• You need to obtain a complete set of real (or if privacy/security reasons prevent that, at least very realistic), inputs (and outputs as produced by the current codebase), exercising as much of the functionality as possible.

  And set up a test environment that allows you to verify that when you supply those inputs, you get back those outputs. This becomes your "spec" for what the system currently does. Which may be markedly different from what people and/or any written specs say it does.

  Only once you've successfully exercised the current code in your test environment and verified that you can produce the same outputs given realistic inputs, should you even consider making 'proactive' changes to the system. And then...

• Fork the codebase in the VCS, and confine your proactive changes to the fork whilst performing documented, assigned bug fixes to the original.

  Don't be tempted to merge the two back until you've a) proven it thoroughly through the test setup. b) documented the business benefits of the changes.

Move cautiously. Get sign-off for rolling unassigned refactoring back into production systems.