Mojolicious is a good choice. I haven't used Dancer2, so if that style is more to your liking, either one would work.

Deployment with a modern PSGI-style framework like either one will be more interesting. You'll probably end up running a Perl webserver in its own process and configuring Apache/IIS/Nginx to proxy to the backend. This isn't as exciting as it sounds once you get it up and running, but it's a different execution model from the CGI fork-process-per-request model you were probably using.

The other interesting part is that both Dancer and Mojolicious (and most other modern web frameworks) separate "generate HTML/CSS/JS" from "handle incoming query and post data" from "look up data in the database". Back in the day we didn't do that much with CGI and it made a mess for larger applications. The framework will help you keep these concerns separate, manage sessions and login, and maintain persistent database connections. Your job is to manage the logical separation and connections between these various Model, View, and Controller layers. Essentially that means that the first thing you have to figure out is what these frameworks will call "routing", or mapping the URLs exposed in the web app to functions/methods in the Controller layers.

There's a little bit of stuff to learn, but that should give you a few hints in the right direction.

I have recently written a quite complex application with Dancer2, and can vouch for its effectiveness. The documentation is very well laid out and easy to follow, and like Mojo, it takes only a few minutes to stand up your first application to get you started by following said fine documentation. The devs are very responsive via many mediums, and has a very large community when one has questions. I have only "played" with mojo very briefly, then decided on Dancer.

I don't remember the reasons why I went with Dancer now, but I do know that it wasn't based on any negative experiences I had with mojo. Probably because I tried it after mojo, and just kept coding.

My recommendation would be to start your research by checking out Mojolicious. Great documentation, fun to work with. You can get started with Mojolicious::Lite and grow from there.

If you are not in the need of a complete framework like Mojolicous or Dancer and due to the fact that you are already familiar to Perl::CGI you should probably have a look at the CGI::Fast Module.

This is a set of terrible—strangely overly-generic and overly-specific: use any DB, the DB was specified; use memcached, why? how?; CGI::Application? Hacka', please—recommendations that look as though you did not read the OP.

Reminds me of the best advice I ever got in my professional career. I pass it along for other readers. My supervisor at Amazon said: Answer the question that was asked, not the question you wish had been asked.

Of course, if you would like to provide a little code, perhaps you could show me where I'm wrong or misunderstanding your advice.

Nothing in the OP particularly suggests anything that calls for a higher-level framework like Catalyst or Dancer ... CGI::Application and its brethren just might be good enough. Expressed concerns about the number of rows in the database-tables being queried are irrelevant so long as the queries and table-indexes are properly designed. Expressed concerns about the number of sessions are much the same – it will not matter. (Portions of requirements like this one can also be handled using tools like RPC::Any if the decision is made to do most of the presentation client-side using JavaScript.) Frameworks can be very helpful but they also introduce complexity which might not be necessary in an apparently-specialized internal use case like this one seems to be.