Just make it work like [system XYZ] does.
Ok, and exactly what does [system XYZ] do? Is that really what the client wants? You know it's a little difficult to reproduce in 5 months what originally took 10-12 years don't you? Maybe we could prioritize which features really do get ported?
Two years ago I was part of a semi-successful rewrite effort of some truly heinous VB6 code. The tribal knowledge was gone, and the code was extremely difficult to follow (hence the rewrite). We ended up pulling most of the detailed requirements out by creating characterization tests by running inputs through the old code and setting up automated tests to ensure our new code did the exact same thing. That's a double edged sword because the characterization tests aren't particularly readable or understandable -- and you potentially end up rewriting existing bugs!
The absolute worst was a project I was on in 2003 where our mission was to "refactor" (we reused the graphics and threw away the rest, including the HTML) a purchased system until it was ready for production. The business partner really wasn't interested in the project, so our total requirements were to make it work like XYZ. The problem was that in this case XYZ was an unfinished prototype, so we basically made up the requirements the best that we could. In the end, nobody walked away happy.
Actually, come to think of it, there was a vague functional spec written very early on that nobody ever looked at again.