in reply to Looking for a CMS
Pursuing the thought made by Anonymous Monk, maybe the best approach would be to .. at least temporarily .. allow the old and the new to co-exist side by side. Apache rules (say...) could be used to separate the web requests very precisely, based on the contents of the URL string, so that, g-r-a-d-u-a-l-l-y (and should the need arise, reversibly ...), a different piece of software handles some of them. (The user will never know the difference.)
In terms of what that “different piece of software” ought to be, there are really an endless number of choices ... such that “the implementation programming-language” makes no real difference at all. Those thousands-of SHTML files are obviously crown-jewels because there are “thousands of” them, but, y’know, you say they’re static, and Apache knows how to serve-up a static file with no help whatsoever. Therefore, the place to start is by identifying what is the business role of this system: literally, what does it do, and for whom. That is what you must painlessly replace, no matter how you do it.
Since there is a lot of real-world experience here, in a great many languages besides just Perl, why don’t you tell us as much as you can about the business requirement? What do those “too many Perl scripts to replace” actually do, for the business? What sort of business-rules does it implement? How is “what this system does” both similar and different to, say, what WordPress does? (And never mind “how.” Questions of “how” should not be on-the-radar yet.)