Perl Support, Migration & Modernisation
keep what works, and get it off the server nobody will touch.
For businesses that depend on Perl: old web applications, reporting scripts and scheduled jobs that move data overnight. We read the code, keep it supported, bring it up to a current Perl on a current server, and replace it in stages where that is the better answer.
More about this service
We are an Australian team working remotely with businesses in the United States, the United Kingdom, New Zealand and Australia. Every engagement starts with a scoped technical assessment, so the estimate that follows is based on your code and your data.
- Assessment A scoped technical review before any estimate
- 18+ yrs Building business software
- Independent No licence commission, no reseller agenda
- US UK NZ AU Australian team, working remotely
Built here. Your data stays here.
- No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
- Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
- Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.
It still runs every night, and nobody wants to open it
Perl ran much of the early web and a great deal of the overnight work behind it. Order forms, intranets, report generators and the jobs that pass files between systems were written as CGI scripts, the oldest way for a web server to run a program, or on mod_perl, which runs Perl inside the Apache web server. They were written once and left alone, because they worked.
Read more
Perl itself is not the problem. It is still released every year. The obstacles are practical: a server held on an old operating system so that an old Perl keeps running, modules from CPAN, the public library of Perl code, that nobody maintains any more, and few people left who read Perl comfortably. Each has a known answer.
Our Perl developer service is for businesses in Perth, Melbourne, Sydney and Brisbane. It covers three kinds of work: code fixes and updates, migration to a modern technology stack, and ongoing maintenance and support.
Three ways forward for a Perl system
The first is the right answer more often than people expect.
-
Keep it and support it
The code stays in Perl, on the version it runs on today. We put it into source control, write down every module it needs, build a copy of the server that can be rebuilt, then fix faults and make changes. This suits scripts that work and mainly need somebody who can read them.
-
Upgrade it to a current Perl
The same code is moved to a supported Perl on a current operating system. Abandoned modules are replaced with maintained ones, old CGI and mod_perl code is brought up to date, and tests show the output has not changed. It stays Perl, on a platform that still gets security fixes.
-
Replace it in stages
Where a web application needs a modern interface, or nobody can be found to maintain Perl, sections are rebuilt as a modern application one at a time against the same database. Background jobs that work are often the last to go.
What we do with Perl systems
Six kinds of work. Most engagements are two or three of them.
-
Perl maintenance
Faults fixed and changes made in existing scripts (.pl and .cgi), modules (.pm) and templates.
-
Module audit
Every CPAN module the code loads listed, with its version, whether it is still maintained and what would replace it.
-
Perl version upgrades
Code moved from an old Perl, often 5.8, 5.10 or 5.16, to a current release, with whatever the newer version rejects repaired.
-
CGI and mod_perl updates
Old CGI scripts and mod_perl 1 code moved onto a current web server setup, where they can be run and tested safely.
-
Server moves
Scripts, scheduled jobs, credentials and file paths moved off the old machine onto a current operating system that can be rebuilt.
-
Staged replacement
Sections rebuilt as a modern web application or service one at a time, where staying in Perl no longer suits the business.
Supporting it, upgrading it and replacing it are different projects
Each trades cost against how much old code and old server remains.
-
Stay on the old Perl
Lowest cost. The code is documented, in source control and supported. It stays tied to an old operating system and to modules nobody maintains, which matters most for anything that faces the internet.
-
Upgrade to a current Perl
Most of the code is reused and behaves the way staff expect. The system ends up on a supported Perl and a supported server. It is still Perl, so somebody who reads Perl is still needed.
-
Rebuild in another language
Nothing depends on Perl afterwards, and developers are easier to find. It takes longest, and the rules buried in old scripts have to be found and proven first. Worth it for an application people use all day, less often for a job that runs at night.
What a Perl assessment looks at
Perl the language is current. The risk is in the version gap, the modules and the server. The release and support facts are from the Perl and Apache projects.
-
Which Perl version
Old servers often run Perl 5.8, 5.10 or 5.16, first released in 2002, 2007 and 2012. Perl 5.44 was released on 15 July 2026. The Perl project fully supports the two newest release series and gives security fixes to releases from the past three years. Anything older gets nothing.
-
The source and where it lives
Scripts (.pl and .cgi), modules (.pm) and templates, whether a web framework such as Catalyst, Mason or Dancer is involved, and whether the code is in source control or only on the live server. Code edited in place on the server, with no history, is common and is fixed first.
-
CPAN modules
Every module the code loads and the version installed. Some have been abandoned, and some are compiled against the old Perl and have to be rebuilt for a new one. A file that lists them all (a cpanfile) rarely exists, so one is written early.
-
CGI and mod_perl
The CGI module was removed from the standard Perl installation in version 5.22, so it now has to be installed separately. mod_perl 1 only works with the Apache 1.3 web server and was last released in May 2009. mod_perl 2 works with Apache 2.4.
-
The server
The operating system, the web server and whether the machine could be rebuilt if it failed. Apache 2.2, for example, is at the end of its life, with a final release in July 2017. Often the old Perl is the reason the server was never updated.
-
The database and files
Which database the code talks to, and which driver it uses with DBI, the layer Perl reaches databases through. Also the files it reads and writes: exports, imports, spreadsheets and anything collected from another system by file transfer.
-
Scheduled jobs and integrations
What runs on a timer (cron jobs), what each job feeds, and which other systems send or expect files, emails or web requests. The list is usually longer than anyone expects.
-
Tests and security
Whether any automated tests exist, how input from a web form is checked before it reaches the database or the operating system, and how passwords are stored. Many old scripts were written before current practice.
A Perl script the business relies on, and nobody left who can read it?
What the assessment needs from you
A fixed-scope piece of work with a written result: the options, the risks of each, and a staged estimate. No production data is sent by email. We agree a secure way to share it first.
-
Version
The Perl version if known, and the operating system the server runs.
-
The code
Where the scripts and modules are kept, and whether they are in source control.
-
Modules
Any CPAN modules you know of, and whether anybody recorded how the server was set up.
-
The server
Where it is hosted, who has the logins, and whether it has ever been rebuilt.
-
The database
What the data is stored in, its size and where it lives.
-
Scheduled jobs
What runs on a timer, when, and what depends on the result.
-
Integrations
Files in and out, emails sent, and other systems the scripts talk to.
-
What is hurting
The two or three problems that started the conversation.
-
The way back
How long the business can run on the old system if a cutover has to be reversed.
From assessment to a supported system
Done remotely, with meeting times agreed to suit your time zone.
-
Technical assessment
We establish the Perl version, find every script and scheduled job, and list each module the code needs and how it reaches its data. You get a written list of options with the risks of each and a staged estimate.
-
A copy that can be rebuilt
The code goes into source control and is made to run on a second machine built from written steps. Until the system can be rebuilt somewhere else, no change is safe.
-
Tests and a proof of concept
The outputs of the important scripts are captured as tests. Then one representative script is taken to a current Perl and shown to produce the same result.
-
Staged work
The work is done in stages agreed from the assessment, each with its own scope and estimate, starting with whatever is hurting the business most.
-
Comparison and user testing
Old and new are run side by side on the same data, and your staff test the work they do every day.
-
Cutover and support
Each switch is planned with a way back. We watch the first days of live use, then maintain the system for as long as it stays in service.
What people ask us about Perl
Is Perl still supported?
Yes. Perl 5 is still developed, and Perl 5.44 was released on 15 July 2026. The Perl project fully supports the two newest release series. The old versions found on many business servers, such as 5.8, 5.10 and 5.16, are long past the end of their life.
Was Perl replaced by Perl 6?
No. Perl 6 was renamed Raku and is a separate language with its own team. The Perl project calls it a sister language, not a replacement. Perl 5 carries on, and a Perl 5 program does not have to become anything else to stay supported.
Perl still works. Why would we change anything?
Often you should change very little, and we will say so. The trigger is usually a server that cannot be updated without breaking the scripts, a module with a known security fault, or not being able to find anyone to make a change.
Can we simply install a newer Perl?
Not without testing. Perl is careful about keeping old code running, but some things changed. Since version 5.26 Perl no longer loads code from the current folder by default, which stops many old scripts, and modules compiled for the old Perl have to be rebuilt. It is tried on a copy first.
Should it be rewritten in another language?
Only if there is a reason beyond fashion. A web application that staff use all day, with nobody to maintain it, is a fair candidate. A job that runs at night and does its work is usually cheaper and safer to keep in Perl on a supported server.
The person who wrote it has gone. Is that a problem?
It is the usual situation. Perl can be written in very personal styles, so the first job is reading the code and writing down what each script does, what starts it and what depends on it. That record is useful whichever path you choose.
Do you provide Perl developers in Perth, Sydney, Melbourne and Brisbane?
Yes. We are an Australian team and we take on Perl work for businesses in Perth, Sydney, Melbourne and Brisbane, and elsewhere in Australia. Most of the work is done remotely, by video call and screen share, with secure access to a copy of your system. The service is the same in every city: code fixes and updates, migration to a modern technology stack, and ongoing maintenance and support.
How does this work from the United States, the United Kingdom or New Zealand?
Remotely. We are based in Australia and do not have offices elsewhere. Discovery is done by video call and screen share, with meeting times agreed to suit your time zone. Confidentiality, who can reach your systems and where your data is held are agreed in writing before work starts.
What does it cost?
The assessment is a fixed-scope piece of work with an agreed fee. The estimate for anything after it comes from what the assessment finds, in stages, so you are not asked to commit to a whole project on a guess.
Sending your details…
You can stay on this page while we send it.
Tell us about your Perl system
What the system does, the Perl version if known, where it runs, and what is forcing the question. Include your country so we can suggest meeting times. Please do not send production data.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
Kasun Wijayamanna, founderYou deal with Kasun from scope to delivery. No account managers and no offshore handoff.