This is one version of the "What do I do with this old code?" question. Basically, you're looking at maintaining cruft and how to do that safely. Personally, I would go through the following steps:

1. Document the assumptions you find. At least review the documentation. We're going through this right now with some old VB code. We have no idea what language the app will end up being in, but at least we have some idea of what's going on, in case the primary maintainer gets hit by a bus. Twiki is good for this, and easy to set up. Plus, management can read it, if they care.
2. Start adding unit tests. Add tests for everything you touch, plus one additional test. The tests may start out being stupid, but at least you'll have something. Plus, you're only testing those items you change. Stuff that isn't broken and isn't being touched, theoretically, doesn't need to be looked at ... at first.
3. Eventually, you'll end up with a critical mass of documentation and unit tests. At that point (3-9 months down the road), you'll be able to make better decisions about what to do with the code. You might have accidentally rewritten some of it by that time. At the very least, you'll be able to make better cases to management for whatever decision you choose to make.

Basically, you need to triage based on need for new functionality. Most applications tend to have between 50% and 90% of the code touched every 18 months, or so. This is a rule of thumb, based on my experience.