You just want to split them into multiple .pm files and then include those into your application pm with the use command.

If it's a small application it's okay to drop them all in the same directory and then perl will find them without you fiddling with the @INC paths

# main pm file
use ajax;
hello();
[download]

#ajax.pm
sub hello
{
   print "hello\n";
}
[download]

Notice that there is no package declaration in the ajax.pm file. This means that all of the functions will be imported directly into your namespace with no fuss.

All this will work, but may become a problem in the future if the application grows too large. It might be wise to separate things into their own namespaces, and use Exporter to only expose the necessities. You'll have to judge for yourself on that one.

It is, unfortunately, very hard to make categorical statements about “what should be done” with a poorly-organized legacy application like this one.   (Dealing with stink-pots is a lot of what i do.)   The biggest gotcha that is going to warrant a lot of careful investigation is ... those AJAX-driven but individual scripts.   You need to figure out exactly how they are being invoked, and how they contribute output to be sent back as part of the reply stream.   Anything goes as to what you might find here, and the thing that you must hope you will not find is “namespace collisions” of any sort between them.   A traditional CGI application is a one-shot:   the designer knows that it will receive the request, then somehow gather-together the right bits of code to handle it, then handle it, then go-away.   If the requests are packaged as individual Perl scripts as you say, presumably only one of them would be loaded at a time so conflicts between them would not be an issue.   If you now seek to assemble them into one file, you could well be changing the situation in a way that your (hapless...) predecessor did not bother to consider before s/he split town, because now all of those modules will be loaded at the same time.

I would suggest starting with a very careful inventory of the entire application, looking at each and every one of those independent files to ascertain the commonality between them ... and how they might conflict with one another if brought into one file.   You definitely need to understand how the dispatching mechanism works right now ... presumably a CGI::App “run mode” gets you as far as “ajax” and one module takes it from there ... somehow.   As you seek, then, to re-factor this thing to use a more intelligent strategy, you also must consider a way to do it in stages, not all-or-nothing.   The monstrosity somehow has to remain in-service the entire time it is being rehabilitated.

You probably should figure out some way to set up a test-machine pointing to a test-database, and look at Selenium or a similar web-GUI testing mechanism so that you can verify automatically that the functionality of the total site is not being interrupted by any of your changes.

Articles and Tutorials on CGI::Application
http://www.cgi-app.org/index.cgi?BestPractices
CGI::Application::Tutorial::Namegame, A Tutorial for CGI::Application
CGI::Application - OrderOfOperations
Examples of CGI::Application in use
CGI::Application Organizing your App
Splitting a project into smaller files, general advice finding duplicate code
Titanium
cgiapp-starter / titanium-starter / cas-starter.pl