After our CB convo, I decide to try to follow my own advice, this is what I got for Programs.pl:

#!/usr/bin/perl
use strict;
use warnings FATAL => qw( all );

package my::site::Programs;

sub get_data {
    my $self = shift;    # not used but passed with '->' notation
    return q{This is a list of B<programs> that I am using or have use
+d. I can not account for I<all> the software we have had and used ove
+r the years. Some of it was so bad, we blanked it out of our heads. T
+his list does not include a full list of hardware drivers either. So 
+much software, so little time or in this case patience.};
}

1; # not sure if this is actually needed here, but would be if you mov
+ed this to a .pm that is "use"d or "require"d

# replicate the functionality of the original Programs.pl
package main; 

use CGI::Carp qw(fatalsToBrowser);

use lib '../files/lib';
use Base::Page qw(page story);
use Util::StoryMagic qw(program_magic);

my $magic = program_magic;
page( 'code' => sub { story(my::site::Programs->get_data(), { 'line ma
+gic' => $magic }) }); # note you'll have to change how you handle wha
+t was passed as "*DATA"
#
# NOTE, since you're now not using __DATA__ (via *DATA handle), you ca
+n make the "main" content
# minimal by passing in just the code reference:
#
# package main;
# use lib '../files/lib';
# Base::Page->page( code => \&my::site::Program::get_data, story => q{
+Util::StoryMagic} );
#
[download]

The goal here was to show what I meant by making the catagory files into modules and to drop __DATA__. This offers no change to how things work now, but by converting all of your .pl files to a module internally, this sets you up for some things:

1. incrementally put your data into module-like libraries
2. move them to functional libraries by turning the above into a modulino - allows you to  use require q{../file/Programs.pl}, e.g.,
3. once they work as they do now, but can be used us libraries as modulinos, you are free to experiment with Dancer2 or Mojo since they will fundamentally differ from your existing code being router/dispatch based and not file based (e.g., require content modules in the route handlers)
4. then you can decide how to proceed, but this allows you to retain the functionality of the site now while exploring a more modern approach

Then eventually if you made them full libraries, you'd pull them into to the framework like:

# in framework route handing
require q{path/to/Programs.pl};
my $data = my::site::Programs->get_data();
#...now do something with $data
[download]