Perl Scripts · 2026.10.17

Maintain or Rewrite a Perl Application? How to Decide

By Manu Mathew, Technical Lead Engineer · Published 17 October 2026 · Last updated 17 October 2026

Your Perl application still runs the orders, the reports or the nightly jobs. But every change feels slow, the original developer has moved on, and someone in a meeting has said, “Shouldn’t we just rewrite it?” Before you rewrite a Perl application, it is worth pausing on what you would gain and what you would put at risk.

This post sets out the signs I weigh, how a rewrite compares with steady maintenance, and the staged middle path that often fits best. It is written for the people who have to make the call, not only for developers.

Quick answer

Keep maintaining a Perl application when it does its job and changes are possible with care. Consider replacing it when the platform it needs can no longer be kept safe, or when the business has changed so much that the code fights every request. Most teams do best with a middle path: stabilise first, then replace parts in stages.

When does it make sense to keep maintaining a Perl application?

Keep maintaining it when the application still does what the business needs and the main problem is how hard it is to change.

Old code is not the same as bad code. A system that has run for years usually holds business rules nobody has written down anywhere else. Those rules are the real asset.

Maintenance is usually the right call when:

• The core logic is still correct. Customers are served and the numbers add up; the pain is in making changes.
• The problems are local. A few fragile modules or jobs cause most of the trouble, not the whole design.
• The platform can be kept current. The server, the Perl version and the supporting libraries can still be upgraded and patched.
• People can learn it. With some notes and tests, a new developer can follow how a request moves through the code.

In that situation, the next step is usually tests around the risky paths, a written map of how the system fits together, and small improvements in a sensible order. My earlier post on testing legacy Perl code covers that first safety net.

What are the signs you may need to rewrite a Perl application?

The strongest signs are a platform you can no longer keep safe and a business that has moved far beyond what the code was built for.

Be honest about which of these are true, rather than how the code feels to read:

• The platform is stuck. The application depends on an operating system, Perl version or library that can’t be upgraded without major surgery. The Perl support policy explains which release series still receive security fixes.
• The design blocks the business. New products, integrations or rules need workarounds every time, because the data model no longer matches how you work.
• Every fix breaks something else. Changes in one area regularly cause failures in unrelated areas, even with care and testing.
• Nobody can safely run it. Deployments are manual and risky, and there is no staging copy to try things in.

One sign on its own is rarely enough. A stuck platform can often be fixed with an upgrade project rather than a rewrite. Several signs together are a better reason to plan a replacement.

What are the risks of a full rewrite?

The main risk is losing behaviour the business depends on, followed by a long period where two systems need attention.

A rewrite from scratch looks clean on paper. In practice, the old system keeps hidden rules: odd rounding, special cases for one customer group, a report someone checks every month. A new system that misses them can quietly get things wrong.

A rewrite also takes longer than most plans expect, because the old system keeps changing while the new one is built. That doesn’t make rewrites wrong. It means they need a clear reason and a careful plan.

Is there a middle path between maintaining and rewriting?

Yes: stabilise the current system, then replace it piece by piece while it keeps running.

This is sometimes called the strangler fig approach: new parts grow around the old system and take over one area at a time, until little of the original is left. For a Perl application, that might look like this:

1. Stabilise. Add tests around the most important behaviour, write down how it is deployed, and fix what is actively unsafe.
2. Draw boundaries. Find areas that can stand on their own, such as a report, an import job or one section of the web app.
3. Replace one area. Build the new version, compare its output with the old one, and switch over with a way back.
4. Repeat or stop. After each step, decide whether the next area is worth replacing or whether the rest is fine as it is.

The same thinking applies to an old CGI application. It can often move to a modern setup in stages, with each step tested and the application kept running throughout. The new parts may stay in Perl or use another language; that choice should follow the team’s skills and needs, not fashion.

How do I help a team decide?

I take a short, read-only look at the code, then write up the options so the decision rests on evidence, not frustration.

My usual steps:

• Understand the business side. What the system does, what hurts today, and what needs to change in the next year or two.
• Map the system. Entry points, scheduled jobs, data flows, dependencies and how deployments happen.
• List the risks. Which parts are fragile, which are outdated, and which are fine despite looking old.
• Write up the options. Usually three: keep maintaining, a staged replacement, or a full rewrite, each with its trade-offs in plain language.
• Agree a first step. Something small and useful whichever way you go, such as tests on a money path or a safer deployment.

A Perl code review is often the natural starting point, because it gives you the map these decisions depend on. Whether you’re searching for a Perl developer in India, a Perl developer in Kerala or someone closer to home, judge the plan by how clearly it explains the trade-offs.

Frequently asked questions

Is Perl still a sensible language to maintain an application in?

Yes, for many systems. Perl is still maintained, with regular releases and security fixes for recent versions. The bigger questions are usually whether your application’s platform is kept up to date and whether your team can find people to work on it, not the language itself.

How long does it take to rewrite a Perl application?

It depends on how big the system is, how well its behaviour is understood and how much it keeps changing. A rewrite of a large, poorly documented system can run far longer than planned, which is why replacing it in stages is often the safer choice.

Should we rewrite in another language or stay with Perl?

Choose based on who will maintain the system and what it needs to do, not on trends. Staying with Perl keeps the existing knowledge and code useful. Moving to another language can make sense if your team already works in it and plans to support it long term.

Can we keep adding features while we modernise?

Usually, yes. A staged approach is designed for this: the current system keeps serving the business while one area at a time is improved or replaced. It does need clear priorities, so the team isn’t building the same feature twice in two systems.

What should we do first if we can’t decide yet?

Start with work that helps either way: tests around the most important behaviour, written notes on how the system runs and is deployed, and an upgrade plan for the platform. These lower the risk of every later decision, whether you maintain, replace in stages or rewrite.

Need help deciding what to do with a Perl application?

If you have Perl code that needs fixing, extending or upgrading, or you’re weighing up a rewrite, I’m happy to take a look. The Perl development page covers the kinds of work I take on, including careful moves from old CGI apps to a modern setup.

You can reach me through the contact section or email me at manu@manu.co.in. A few lines about the system and what you need is a good start.

Back to the blog