If you actually can cost-justify the expense of replacing a PHP script that works with a Perl script that doesn’t exist yet, then the structure of the Perl script is basically going to be the same as whatever the PHP version now reflects.   It will be invoked as a CGI or FastCGI script, handed some HTTP inputs, and it must produce an HTTP response after doing some work with the database.   Instead of using features that are built-in to PHP, which is by design a fairly monolithic system, your Perl script will use components drawn from CPAN, and you would be well-advised to use the highest-level components that you can manage.   (For instance, RPC::Any.)   Nearly all of this requirement is “nothing new,” so do not plan to write “new” code for all of that.

If I were managing this project, though, I’d oblige you to answer me, “what’s so wrong with PHP in this case?”   If that host-side system is doing the job acceptably well, then PHP, also, is a well-proven system, and “I’m not running a Perl school here.”   Consider very carefully whether there will actually be any ROI = Return On Investment here, knowing that I am going to have to put a new line-item for $XX,000.00 on my project budget and to secure approval for that from my boss ... and to sell the idea that replacing a module that is in-service now is “necessary and unavoidable.”   (In the rather unlikely event that I am actually persuaded of this, myself.)   Consider also just what it is that is now compelling you to replace it, so that you can be extremely sure that your Perl replacement does not merely follow in its footsteps to the same end.   Consider also what changes are implied in the client-side JavaScript.   If de-stabilizing changes start showing up there, too, as I expect they will, then I would kick-the-can your project back to start and say, “I’m not buying this.   (Literally.)   Find a way to do this keep doing this in PHP.”