Ouch, Ovid..
Sounds exactly like what I'm doing here (re-writing the core system of two old, messy and (to this company) rather vital sysems).
The code I have to deal with is a mish mash of shell (either csh, bash or ksh, with no real standard), perl and C. And it evolved over about 8 years of use, from the very start of the company, to a system processing gigs of data a day.
If things are truly in the disarray you mention (like it was here), and nobody knows the 'big picture', or at least, cannot document it properly, then don't expect to build this just once.
Because there were too many caveats to write down exactly what the code did from reading various sections of code, I wrote a prototype 'new' system for various areas. This gave me the familiarity with the way things operated, to the level that I could actually get the system working the way it should.
Then, after having this prototype ready, and documented with notes, it was far easier to do a production level set.
It's time consuming, and a tad annoying, but, once you know what you're really writing, it's easier to build the correct modules for what's actually required, and from there, more efficient to build the production system.
This may not be very applicable to you where you are, but, it worked for me. :)

Cheers,

Malk.