Service 02
Perl Migration
The scripts nobody lists on an architecture diagram and everybody depends on. We find them, write down what they do, prove it with tests, and then decide with you which ones move and which ones are better left where they are.
- Perl 5.8 CGI, mod_perl, no tests- 47 cron entries, 12 still needed+ documented, golden-file tested + ported or stabilized, one by one
01 · Where we come in
The systems that never made it onto the diagram.
- A CGI script behind Apache that finance runs every month end, written by someone who left before the current CFO arrived.
- Cron entries that accumulated over twenty years, an unknown number of which no longer do anything.
- A mod_perl application on an operating system that stopped getting security updates a while ago.
- A report generator whose output format is defined nowhere except in the code that produces it.
- Perl 5.8 or 5.10 running on hardware you have been told you cannot replace.
- DBI code pointed at a database version that went out of support two migrations ago.
- A script that was edited directly on production, because there was never anywhere else to edit it.
02 · The honest fork
Not every script deserves a rewrite.
A small Perl script that has run correctly every month for fifteen years is not a problem to be solved. It is an asset with poor documentation. Part of what you are paying us for is the judgment to tell those apart, and the willingness to recommend the cheaper answer.
The script is in your way
It changes often. Someone needs a feature it cannot support. It blocks a platform upgrade elsewhere. The hosting it depends on is going away. Nobody left can safely modify it and it keeps needing modification.
The script is just quiet
It runs on a schedule and has not failed in years. The logic is small and the output is stable. Nobody is asking it to do anything new. Here we document it, test it, put it on a supported Perl, and leave it be.
Recommending "stabilize" makes us less money than recommending "port". We would rather give you the correct answer twice than the profitable answer once, because the second engagement is where the money actually is.
03 · The work
What we actually do.
Find everything first
Every script, cron entry, scheduled task, and web endpoint that actually runs. Clients are routinely surprised by their own inventory, in both directions.
Write down what it does
Inputs, outputs, side effects, database writes, files touched, and who consumes the result. In plain language, checked against observed behavior rather than assumed.
Golden-file tests
Real inputs captured from production, real outputs recorded byte for byte. Nothing gets ported until we can prove what the original produced.
Onto something maintainable
Python, Java, Go, or current Perl. The deciding factor is what your team can hire for and maintain, not what we enjoy writing.
Byte-exact output
Fixed-width and delimited formats reproduced exactly, down to padding and line endings, because the systems reading them were written to be unforgiving.
Scheduling you can see
Cron moved onto something observable, with alerting for the failure mode nobody catches: the job that quietly does not run at all.
04 · Engagement
How it runs, and what it costs.
Perl work follows the same five steps as everything else we do, set out on the home page. Discovery matters more here than on a Java project, because the hardest question is usually what exists rather than how to move it.
- Start with
- A discovery pass across the servers involved. Two to three weeks on a weekly written cadence, priced on its own, and it ends with an inventory and a port-or-stabilize recommendation per script.
- Then
- We work through the list in an order you approve, usually most-at-risk first. Each script is finished and handed over before the next one starts.
- You bring
- Server access, sample production inputs, and someone who can tell us who consumes each output.
- Pricing
- Fixed scope per batch of scripts once discovery is done. You can stop after any batch.
- Subcontract
- We work under a prime contractor or agency, under your name, on your paper.
05 · Questions
What people ask before hiring us.
What do you port to?
Whatever your team can maintain after we leave. If your shop is a Java shop, we port to Java. If you have Python people, Python. If you have neither and the script is fine, we leave it in Perl and bring the Perl up to date. Handing you code in a language nobody there writes is a way of creating your next legacy problem.
Some of these scripts might be dead. Can you tell?
Yes. We instrument them and watch for a full business cycle, usually a month or a quarter depending on what the schedule looks like. Anything that never fires gets flagged, and you decide whether to retire it. Deleting things is often the cheapest win in the project.
Nobody here knows what one of them does.
That is expected and it is fine. We read it, run it against captured inputs in an isolated environment, and write down what it actually does. Then a person on your side confirms whether that is still what it is supposed to do, which is a different and more interesting question.
Can you just keep it in Perl?
Often the right call. Modern Perl is maintained and perfectly respectable. Moving from 5.8 to a current release on a supported OS, with tests and documentation added, solves the actual risk without a rewrite. We will say so when we think so.
What if a port changes the output slightly?
Then it is not finished. Golden-file tests exist precisely to catch that, and a difference is a defect until you tell us in writing that the difference is acceptable.
Contact
Send us the script nobody will claim.
admin@burningsapp.comPerl version, where it runs, and roughly how many scripts is enough to start.