You're going to have to be careful about this. If you translate COBOL to Perl mechanically, you're going to be churning out an awful lot of very bad Perl code. Variables in COBOL are global and the "PERFORM" statements generally involve setting a variable and having the correct global variables set when the PERFORM is done. Because COBOL was designed before structured programming was common, it typically does not support features that we today would consider good programming. As a result, an automatic translation will take COBOL and turn it into really, really bad Perl.

Unfortunately, manual translations suffer because they're so expensive and obscure business rules which have been translated into COBOL may get lost. Further, it's been my experience that the older the COBOL, the more difficult it is to follow. Trying to translate spaghetti code faithfully without realizing which code is dead can waste a lot of time.

Let's say, however, that you decide to go the mechanical translation route. How are you going to translate a COBOL table into a Perl data structure? It's certainly not a trivial task. What you would probably need to do is define a bunch of core Perl routines which duplicate common features/keywords of COBOL. COBOL's tables are one example. The UNSTRING command is another. The latter doesn't really translate well into Perl's split command, though it appears to at first glance. You'll also have to take into consideration which versions of COBOL you are using. Older versions were shy on operators, but newer versions weren't. Thus, you could have several ways of writing the same statement but you'd want to translate all of them the same way.

I would probably suggest having the COBOL replaced one program at a time and not move too fast, but that's just an ad-hoc comment given that I don't really know the full scope of your problem. Good luck!