While the tone of this message leaves me a bit confused I will attempt to help you despite not having access to enough of the code to actually understand the structure. It seems like you have some problems with mod_perl in addition to the constraint that apache won't be available, almost as if you think programming for mod_perl is in and of itself a bad thing. I don't think anything you've posted here looks "clever" or "old" or anything else. Apache and mod_perl are proven, stable platforms that offer a lot of benefits (and like any technology choice, also some drawbacks).

The lines you see are common for mod_perl applications, they give you access to underlying apache objects that are really helpful and extremely fast compared to typical CGI.

All that said, I think you should start at the entry points of your application. Those declared in handler functions. You will have to find all the $q objects (which are similar to $cgi objects) and look at the methods that they are calling. Generally these will be compatible with $cgi although some aren't -- for example, the header handling functions are different under mod_perl.

All the "Const" includes are to pull in constants such as SERVER_ERROR or FORBIDDEN, so look for any constant (capitalized bareword in this case) that could be an http return code. You can get the full list here.

You will have to look for function calls also, like a function called "status" which sets the status of the response, any references to redirect, etc.

This is typically the opposite of what I've encountered, usually the jobs I do around mod_perl are around converting CGIs to mod_perl apps.