What Perl Actually Looks Like Inside Companies Right Now

Perl rarely shows up in a company's public technology stack page. It shows up in the systems nobody wants to touch: billing pipelines, network provisioning scripts, log parsers, data migration jobs, and the glue code that moves files between 2 systems that were never designed to talk to each other. This is not a coincidence. Perl was built for exactly this kind of work, and the code written for it in the 1990s and 2000s has, in many cases, simply kept working.

A few examples make this concrete. cPanel, the web hosting control panel used by a large share of shared hosting providers worldwide, has been in continuous development since 1996 and its core is still written largely in Perl, alongside PHP, C and C++. Community reports and engineering discussions from Booking.com have described Perl as a significant part of their back end for years, handling large scale, high traffic logic that would be expensive and risky to rewrite without a clear business reason. Git, the version control system most engineering teams use every day, ships with some Perl based tooling under the hood, a small but persistent example of how deeply the language is embedded in infrastructure that has nothing to do with "Perl projects" on the surface.

Beyond individual companies, entire industries lean on it for reasons that have not changed much in 20 years:

That last row is not a joke. A large share of legacy Perl in the wild survives because the business logic buried in it was never documented anywhere else. The script is the specification.

It is also worth separating 2 very different categories of legacy Perl, because they call for different responses. The first category is small, isolated utility scripts, things like a nightly file transfer job or a one off report generator, where the blast radius of a failure is limited and the cost of leaving it alone is genuinely low. The second category is core business logic, systems that calculate invoices, validate transactions, or route customer data, where the same neglect carries real financial and reputational risk. Companies that get into trouble usually treat both categories the same way, either ignoring everything equally or trying to modernize everything at once. A more useful approach starts by sorting your own inventory into these 2 buckets before deciding anything else.

The TIOBE Comeback, and Why It Does Not Settle the Question

If you searched around this topic in the past year, you probably saw headlines about Perl's surprise return to the TIOBE index, a widely cited measure of programming language search popularity. The numbers are real. Perl fell outside the top 30 in early 2025, then climbed month over month to reach roughly 9th or 10th place by the end of that year, a jump that even surprised TIOBE's own team. By mid to late 2026, that position had slipped again, with Perl settling back down into the low 20s alongside Ruby.

TIOBE's own explanation for the spike was partly technical and a little unusual: Perl related books listed on Amazon outnumbered PHP books by roughly 4 to 1 at the time, which fed into the index's scoring formula. The more durable explanation offered was that Perl 5, the version almost everyone actually uses, had spent years overshadowed by the long, troubled development of Perl 6, which was eventually renamed Raku. Once that confusion settled and Perl 5 was clearly understood as "the real Perl" again, search interest recovered somewhat.

The reason this matters for your decision is simple. A popularity index measures search and discussion volume, not the number of production systems quietly running a language, and not whether your specific script still meets your business needs. Hiring Perl developers for legacy systems does not get easier or harder because of a monthly ranking swing. What actually matters is the condition of your code, the size of your talent pool, and the cost of the alternative. Treat the TIOBE story as an interesting footnote, not as evidence either way.

Why These Old Scripts Refuse to Die

There is a pattern behind why so many companies keep Perl running well past the point where a newer language might, on paper, look like the obvious choice.

• Text and regex handling remains genuinely strong. Perl was built around pattern matching and reshaping raw text, and for log parsing, data cleaning, and format conversion work, that strength has not been meaningfully replaced by newer languages. It has been matched in places, not exceeded.
• Rewrite risk is almost always underestimated. A script that has run in production for 10 years has absorbed years of edge case fixes, most of which are not documented anywhere except in the code itself. Rewriting it means rediscovering every one of those edge cases the hard way.
• CPAN dependency chains are deep and often unglamorous. Many legacy scripts rely on CPAN modules that have not been updated in years but still work fine. Untangling those dependencies to move to another language is a project of its own, separate from the rewrite itself.
• The economics rarely favor a rewrite on schedule. A working script that runs unattended overnight and causes no incidents does not generate urgency. Budget tends to go toward visible, customer facing work instead, and legacy maintenance gets whatever is left.
• Perl ships almost everywhere by default. On most Linux and BSD distributions, a Perl interpreter is already present. For system level scripting and small automation tasks, that removes a dependency headache that other languages introduce.

None of this means every Perl script deserves to stay. It means the decision has to be made on the specific system in front of you, not on a general assumption that old code is automatically a liability.

What It Actually Costs You to Ignore Legacy Perl

Choosing not to touch a working script feels like the safe, zero cost option. It is not. The costs are just deferred and less visible, which makes them easy to underestimate until they show up as an incident.

Security exposure builds up quietly. Perl itself is actively maintained, with security relevant fixes continuing to land in Perl 5.40 and later releases, but a script pinned to an old interpreter or a stack of unpatched CPAN modules does not benefit from any of that. If nobody has reviewed the dependency chain in 3 or 4 years, you likely have unpatched vulnerabilities sitting in production without anyone tracking them.

Institutional knowledge disappears faster than expected. CPAN's own community reporting shows the rate of new contributors joining the ecosystem has slowed considerably over the last decade, even as a smaller core of very active maintainers keeps the archive growing. As of early 2026, CPAN had accumulated more than 43,500 distributions over its lifetime, but a shrinking base of people deeply fluent in older idioms means the person who understands your script's logic is increasingly likely to be a single individual, not a team.

Compliance and audit findings pile up. Auditors and security reviewers increasingly flag unsupported runtimes and undocumented business logic as findings, regardless of whether the system has ever actually failed. A script with no tests, no documentation, and a single point of institutional knowledge is a recurring line item in every audit until it is addressed.

Recruitment gets harder, not easier, the longer you wait. Waiting for "a better time" to modernize does not shrink the talent pool problem. It grows it, because every year that passes is another year of Perl focused engineers retiring or moving into other specialties, and another year your internal documentation goes further out of date.

Small operational failures become expensive. When something in an old script finally does break, usually after an OS upgrade, a dependency conflict, or a data format change nobody anticipated, the fix often takes far longer than it would for actively maintained code, simply because nobody has looked at that file in years.

Maintain, Modernize, or Rewrite: A Practical Framework

Most legacy Perl decisions get framed as a binary choice, keep it or replace it, when in practice there are at least 3 reasonable paths and the right one depends on specific, answerable questions about the system itself. This is usually the point where whether Perl is still worth maintaining in 2026 stops being a language question and becomes a straightforward cost and risk exercise, the same one you would run on any aging piece of infrastructure.

Maintain is the right call for stable, low change scripts that already work and have a reasonably documented purpose. Spend just enough to patch security issues and keep the environment supported.

Modernize fits systems that are business critical and stable in scope but need better integration, monitoring, or testing. This often means wrapping the existing Perl logic in an API layer, adding automated tests around the parts that matter most, and gradually improving code quality without touching the core logic that already works.

Rewrite makes sense when the system needs to change frequently, when nobody can safely modify it anymore, or when the talent required to support it has genuinely disappeared. Even here, a full rewrite in one step is rarely the safest approach. A gradual, piece by piece migration almost always beats a single cutover.

Hiring Perl Developers for Legacy Systems: Why It Is Harder Than It Looks

Hiring Perl developers for legacy systems is a different exercise than hiring for a mainstream language, and treating it the same way is where most companies go wrong.

The first difference is the size of the pool. Perl is not taught in most computer science programs anymore, which means the people who know it well typically learned it on the job, often 10 or more years ago, and have since specialized into senior or staff level roles. You are not hiring a junior developer who picked up Perl in a bootcamp. You are usually hiring someone with a broad systems background who happens to have deep Perl experience as one part of it.

The second difference is what "good at Perl" actually means for legacy work. Writing clean new Perl is one skill. Reading 15 year old Perl written before modern object oriented conventions were common, understanding its implicit context switching, and safely modifying it without breaking behavior nobody documented, is a distinct and rarer skill. When you are screening candidates, ask less about syntax and more about how they approach an undocumented codebase.

A few practical filters help separate genuine legacy expertise from surface familiarity:

• Ask candidates to walk through how they would approach adding a test suite to a script that has none, rather than asking them to write new code from scratch.
• Look for real experience with CPAN dependency management, not just familiarity with the language syntax. Legacy Perl work is often more about dependencies than logic.
• Ask about their experience with Perl's context sensitivity (scalar versus list context), a common source of subtle bugs that trips up people who only know the language superficially.
• Check whether they have worked with older Perl idioms such as typeglobs, symbol table manipulation, or CGI based scripts, since a lot of legacy code still uses these patterns even though newer Perl code rarely does.
• Ask how they would handle a production script with no version control history, since this is more common in legacy environments than most job postings admit.

Given how narrow this pool is, most companies end up choosing between 3 paths: retaining or training existing staff who already know the codebase, working with a specialized agency that maintains a bench of legacy language developers, or bringing in freelance specialists for a defined, time boxed engagement. Each has tradeoffs worth weighing honestly rather than defaulting to whichever option is fastest to start.

It also helps to set realistic expectations about timelines before the search even starts. A mainstream language role might take 2 to 4 weeks to fill through a normal hiring process. A legacy Perl role, especially one that requires domain knowledge on top of the language itself, regularly takes longer, and rushing the process tends to produce candidates who know the syntax but not the judgment required to work safely in old, undocumented code. Building in extra time for a paid trial task, a short audit of a real script from your codebase, catches this gap far more reliably than a standard interview loop built for mainstream hiring.

What Perl Maintenance and Modernization Actually Cost in 2026

Cost is usually the question underneath the question. Below are typical market rate bands seen for Perl focused engagement types in 2026, though actual numbers vary by region, vendor, and the complexity of the specific codebase.

These figures tell only part of the story, and the part they leave out is usually what causes budget overruns. A few hidden costs come up repeatedly in real Perl maintenance projects:

• Dependency archaeology. Before anyone can safely touch the code, someone has to figure out which CPAN modules are in use, which versions, and which of those are no longer maintained upstream. This discovery work is rarely scoped into the initial estimate.
• Environment recreation. Old scripts were often built against a specific OS version, a specific Perl interpreter, and specific system libraries. Recreating that environment safely, especially in a containerized or cloud setup, can take longer than the actual code changes.
• Building tests that never existed. Legacy Perl scripts frequently have zero automated test coverage. Any serious modernization work has to budget time for writing tests before making changes, not after, or the project carries unacceptable risk.
• Knowledge transfer from the one person who understands it. If a single retiring employee is the only person who understands the script's business logic, budgeting time for structured knowledge transfer sessions is not optional, it is often the single highest value activity in the entire engagement.
• Documentation debt. Writing down what the system actually does, not what anyone assumes it does, is unglamorous work that rarely gets its own line item but consistently saves money on every future change.

In House Team, Freelancers, or a Dedicated Team

Once you know roughly what the work involves, the next decision is who does it. There are 3 realistic models, and each suits a different kind of legacy Perl problem.

In house retention or training works when you already have engineers who understand the system, even partially, and the ongoing workload is steady enough to justify keeping that knowledge internal. This is usually the cheapest long term option if the people are willing to stay in the role.

Freelance or contract specialists make sense for a well scoped, time boxed project, such as a security audit, a specific modernization sprint, or documenting a system before a planned transition. The risk here is continuity. A freelancer who finishes the project and moves on takes the newly rebuilt context with them unless documentation is explicitly part of the deliverable.

Working with an agency to hire dedicated developers fits situations where the legacy system is business critical, the internal team lacks the specific expertise, and you need a more predictable, ongoing relationship than a single freelance engagement can offer. A dedicated team model means a developer or small group works specifically on your codebase over an extended period, building the kind of deep context that ad hoc contractors rarely get the chance to build. For companies running Perl systems that touch billing, compliance, or customer data, this model tends to reduce the knowledge loss risk that shows up repeatedly throughout this article.

Whichever model you choose, insist on documentation as a deliverable, not an afterthought. A maintained script with no written record of what it does has simply moved the original risk from "unmaintained" to "maintained by one person who might also leave."

A Migration Path That Does Not Require a Rewrite

For teams leaning toward modernization rather than a full rewrite, the good news is that Perl's own ecosystem has matured enough to make gradual change realistic.

Frameworks such as Mojolicious and Dancer let teams modernize the parts of a system that face the outside world, adding a clean, modern web layer around older core logic, without rewriting that core logic itself. This is often the fastest way to make an old system easier to monitor, test, and extend, while leaving the parts that already work alone.

A strangler pattern approach, where new functionality is built in a modern language and gradually takes over responsibilities from the old script piece by piece, tends to be safer than a single cutover. It lets teams validate each piece against real production behavior before removing the Perl code it replaces, rather than betting the entire system on one big release.

Wrapping legacy logic behind a well defined API is another low risk step. It does not require touching the internals at all, but it does let other systems interact with the legacy script through a stable, documented interface instead of reaching directly into files or databases the way older integrations often do.

None of these approaches require choosing between "keep everything as is" and "rewrite everything in Python or Go." Most successful modernization projects use some combination of all 3, applied gradually, with the riskiest and most business critical parts touched last, not first.

A Short Checklist Before You Decide

Before committing budget in either direction, it helps to answer a short set of questions honestly.

•    Does anyone currently on staff fully understand what this script does and why?

•    Has this system had a security or dependency review in the last 2 years?

•    Is the business logic documented anywhere outside the code itself?

•    Does the system have any automated tests at all?

•    How often does this script actually need to change?

•    What would actually break, and for how long, if this system failed tomorrow?

•    Have you priced out a scoping or audit phase, separate from the fix itself?

If most of your answers point to "nobody knows" or "not recently," that alone is useful information. It usually means the real first step is not a rewrite or even a maintenance contract, it is a proper audit. Answering these honestly is, in practice, how most teams actually settle whether Perl is still worth maintaining in 2026 for their own systems, long before anyone writes a line of new code.

Key Takeaways

• Perl's TIOBE ranking swings are a popularity signal, not a reliable indicator of whether your specific legacy system is worth keeping.
• Industries like telecommunications, bioinformatics, and financial services keep Perl running because rewrite risk and stability requirements outweigh the appeal of newer languages.
• The cost of ignoring legacy Perl is deferred, not avoided. Security exposure, knowledge loss, and audit findings accumulate quietly until they become urgent.
• A maintain, modernize, or rewrite decision should be based on business criticality, code quality, and how often the system actually changes, not on general assumptions about old code.
• Hiring Perl developers for legacy systems requires different screening than hiring for mainstream languages. Prioritize experience reading undocumented code over syntax knowledge.
• Hidden costs like dependency archaeology, environment recreation, and knowledge transfer are where most legacy Perl budgets go wrong.
• Gradual modernization, using API wrapping, modern frameworks like Mojolicious or Dancer, and strangler pattern migrations, is usually safer than a full rewrite.

So, Is Perl Still Worth Maintaining in 2026?

The honest answer is that the question itself is slightly wrong. It is not really about Perl as a language. It is about a specific script, running in a specific system, doing a specific job that your business depends on. That script does not care what TIOBE ranking Perl holds this month, and it will keep running whether or not anyone reads another article about the language's revival.

What matters is whether you understand what it does, whether the risk of it failing is something you have actually planned for, and whether the cost of maintaining it honestly compares to the cost, and the risk, of replacing it. For a large share of companies still running Perl in 2026, the answer to maintaining it is yes, at least for now, provided that maintenance means real security patching, real documentation, and real investment in the people who understand it, not just leaving it alone and hoping it keeps working. For a smaller number of systems, particularly ones that change often or have already lost their institutional knowledge, the honest answer is that continued neglect, not the language itself, is the actual risk.

Either way, the decision deserves the same rigor you would apply to any other piece of business critical infrastructure. Perl earned its place in your systems by being reliable for a very long time. It deserves an honest evaluation, not a default in either direction.

If there is 1 practical next step worth taking before any budget gets committed, it is a short, scoped audit of the systems in question, done by someone who can read old Perl comfortably and tell you plainly what state the code is actually in. That single step tends to save far more money than it costs, because every option after it, maintaining, modernizing, or rewriting, gets cheaper and safer once the guesswork is gone.