If “you don’t know where to start,” then that is where you must start.

The first thing that you’ll need to be making here is a defensible business case, and a defensible and implementable business plan.   This plan must consider all currently-available options, including commercial offerings and also including leaving the system right where and as it is.

There’s no law against a system that smells bad, if it works and if it still has commercial life left in it.   That “commercial life span” is surprisingly short in some cases, but perhaps longer than you wish.   In any case, if the business case exists for fundamentally changing the system that you have inherited, your approach is going to have to be an incremental one.   It might involve Perl.   It might not.

I am familiar enough with Python, and with Twisted, to say with considerable confidence that the life of such a system ought to be nowhere near “over,” and, even though you will never look at the Tab key in the same way again, it is to me just about as impressive a tool as Perl is.   And there is a lot of very solid stuff out there ... Django, anyone? ... which is pumping a lot of iron.   If you tell me that such a system “has to be” decomm’d, I will not be persuaded easily.   Let’s say for the sake of argument that, “that door is now at least for now Officially Closed.™   You can’t rewrite the system.”   What else might we consider to do?

Perhaps what you need is better workflow-processing.   Farming out the work to a batch system that could be written in any number of languages (and which probably will consist of an off-the-shelf existing tool).