Scripts Perl antigos que ninguém quer tocar

Um diretório Perl com quinze anos raramente é um único sistema. Normalmente é um amontoado de tarefas cron, utilitários copiados, correções de emergência, integrações com software de terceiros e um ou dois programas que ainda movimentam dinheiro ou dados de clientes toda noite. O primeiro trabalho não é reescrever tudo. Primeiro, é preciso provar quais arquivos participam do comportamento em produção.

Já vi equipes começarem pelo maior script, limparem sua sintaxe e descobrirem depois que a produção chamava uma cópia menor por meio de um agendador em outro host. É assim que um projeto organizado de modernização quebra um processo feio, mas funcional. Trate o sistema em execução como fonte de provas. Monte o inventário a partir da execução e só então decida o que merece ser removido, isolado, reparado ou substituído.

Comece pela execução, não pela árvore de código

Uma árvore de código não diz o que ainda roda. Você precisa de provas vindas de agendadores, registros de processos, definições de serviços, histórico do shell, inicializadores de aplicações, datas de arquivos e sistemas que consomem a saída. Um arquivo pode parecer abandonado enquanto um processo financeiro trimestral ainda o chama. Outro pode receber alterações diárias de um processo de implantação e nunca ser executado.

Procure em todo agendador capaz de iniciar trabalho, não apenas no crontab do usuário atual. Verifique diretórios cron do sistema, temporizadores de serviços, agendadores de lotes, tarefas de banco de dados, sistemas de integração contínua, painéis de controle e o agendador corporativo que a operação esqueceu de mencionar. Em hosts parecidos com Unix, esta primeira passagem produz pistas úteis sem atribuir à máquina mais certeza do que ela pode oferecer:

ps -eo pid,lstart,args | grep '[p]erl'
find /etc/cron.d /etc/cron.daily /etc/cron.hourly -type f -exec grep -nH 'perl\|\.pl' {} \;
grep -R -n 'perl\|\.pl' /etc/systemd/system /usr/lib/systemd/system
find /opt /srv /usr/local -type f \( -name '*.pl' -o -name '*.pm' \) -print

A saída típica de um processo contém o PID, a hora de início e a linha de comando completa. Os argumentos importam porque muitas vezes selecionam o modo de negócio real:

1842 Mon Aug 10 01:00:02 2026 /usr/bin/perl /opt/billing/bin/post.pl close

Repita a amostragem de processos ao longo do calendário do negócio. Uma única captura perde tarefas que duram segundos. Para cada execução observada, guarde o caminho original, o caminho do interpretador, o diretório de trabalho, o usuário, os argumentos, a origem do ambiente, a condição de início, a frequência, as entradas, as saídas e o consumidor posterior. Se você não consegue nomear o consumidor, o inventário não terminou.

Examine os registros de implantação como uma fonte separada. Um manifesto de pacote pode revelar um script instalado fora do caminho do repositório que você pesquisou, e um script antigo de entrega pode renomear ou gerar Perl durante a instalação. Compare hashes entre hosts em vez de confiar em nomes de arquivo iguais. Marque os arquivos gerados como tal e encontre o modelo ou comando que os cria. Caso contrário, uma implantação posterior pode restaurar silenciosamente o código que você julgava removido. Pergunte também à operação sobre chamadas manuais, em especial correções de fechamento do mês e novas execuções depois de falhas parciais. Esses eventos muitas vezes não deixam uma entrada permanente no agendador.

Os logs dos hosts podem reforçar as provas. Contabilidade de processos, logs de auditoria, logs do agendador e telemetria dos equipamentos podem mostrar execuções antigas. Se essas fontes nunca foram ativadas, registre isso no inventário. Não transforme a ausência de registros na afirmação de que um script morreu.

Um grafo de chamadas precisa de arestas fora do Perl

O grafo de chamadas útil inclui shell, JCL, entradas de agendadores, configuração do servidor web, tarefas de banco de dados, chegada de arquivos e pessoas que seguem manuais de operação. A análise estática de Perl cobre apenas parte desse grafo. Um require dinâmico, nomes de módulos construídos, eval, callbacks e tratadores escolhidos pela configuração podem esconder arestas até dentro da linguagem.

Comece com referências literais e shebangs e siga para fora a partir de cada ponto de entrada confirmado:

grep -R -n 'use \|require \|do ' /opt/legacy-perl
grep -R -n '/opt/legacy-perl\|perl ' /opt /srv /usr/local/etc
find /opt/legacy-perl -type f -perm -u+x -exec head -n 1 {} \;

Crie um registro com uma linha por arquivo executável. Dê a cada linha um estado de prova: observado, configurado, referenciado ou sem referências. Mantenha os estados separados. Uma entrada no agendador prova configuração, não uma execução bem-sucedida. Um nome de arquivo em um manual prova intenção humana, não uso atual. Um processo ativo é uma prova forte, mas pode ser uma tarefa travada, não uma tarefa saudável.

Registre então as arestas de entrada e saída. As de entrada explicam como a execução começa. As de saída incluem módulos, executáveis, bancos de dados, filas, retransmissores de e-mail, hosts remotos e arquivos. Registre também os formatos dos dados. Um arquivo separado por tabulações com uma ordem de colunas não documentada é uma interface, mesmo que ninguém o tenha chamado assim.

A remoção exige duas formas de prova: nenhuma aresta de entrada observada ou configurada durante um período operacional representativo e nenhuma saída exclusiva esperada por outro processo. Coloque um candidato em quarentena antes de removê-lo. Tire sua permissão de execução ou mova sua entrada do agendador para um arquivo desativado e versionado, e observe se alguma expectativa falha. Mantenha uma forma rápida de restauração. Código antigo não merece imunidade sentimental, mas incerteza não é prova.

Reproduza o interpretador antes de corrigir o código

O comportamento do Perl depende de mais do que o arquivo .pl. Registre o interpretador exato e suas opções de compilação antes de testar qualquer coisa. /usr/bin/perl pode ser diferente de um Perl instalado em /opt, e um wrapper pode alterar PERL5LIB, localidade, fuso horário ou diretório atual. Essas diferenças podem mudar a resolução de módulos, a leitura de datas, a ordenação e o tratamento de texto.

Execute os comandos a seguir como o usuário de produção, no diretório de trabalho de produção, removendo segredos da saída salva:

command -v perl
perl -v
perl -V
perl -e 'print join("\n", @INC), "\n"'
env | grep '^PERL\|^LANG\|^LC_\|^TZ'

perl -V informa como o interpretador foi construído e mostra valores de configuração que explicam falhas de portabilidade. A saída de @INC mostra onde o Perl realmente procurará módulos e em qual ordem. Guarde ambos com o inventário. É fácil perder uma dependência em um diretório privado da aplicação se você examinar apenas a lista de pacotes do sistema operacional.

As verificações de compilação são úteis, mas interprete seu alcance corretamente:

perl -c /opt/legacy-perl/bin/post.pl

Um resultado como syntax OK prova que a compilação terminou naquele ambiente. Não prova que exista um módulo carregado dinamicamente em um caminho raro, que uma conexão de banco de dados funcione ou que o script produza a saída correta. Compile cada ponto de entrada confirmado com o mesmo usuário, ambiente, argumentos e diretório de trabalho usados em produção. Nunca comece adicionando use strict ou alterando avisos em toda a árvore. Essas são boas práticas para código mantido, mas mudam a superfície de diagnóstico antes que você tenha registrado o comportamento de referência.

Colocar o ambiente antigo em um contêiner pode ajudar na reprodução, mas um contêiner não é uma máquina da verdade arqueológica. Bibliotecas nativas, comandos do sistema, certificados, DNS, permissões do sistema de arquivos, dados de localidade e comportamento do agendador continuam fora da lista de dependências Perl. Registre essas arestas em vez de presumir que a imagem as capturou.

Observe com segurança antes de instrumentar

A observação em tempo de execução deve começar fora do processo, porque alterar um script antigo pode mudar tempo, ambiente e tratamento de erros. Comece pelas marcas do agendador, duração do processo, arquivos abertos, processos filhos, destinos de rede, status de saída e mudanças no sistema de arquivos. Colete esses fatos numa cópia do ambiente sempre que possível. Em produção, use recursos somente de leitura já permitidos pela operação e defina uma janela curta de observação.

O rastreamento de chamadas do sistema ajuda quando o código esconde caminhos atrás de variáveis ou configuração. Um rastro pode mostrar qual arquivo de módulo foi aberto, qual executável o script iniciou e qual arquivo de configuração ele tentou antes de usar uma alternativa. Ele também registra muitos dados sensíveis e pode tornar lento um processo ocupado. Filtre operações de arquivos e processos, grave o rastro em armazenamento protegido e peça a aprovação de um operador para o comando. Não se conecte sem cuidado a uma tarefa de pagamento ou liquidação só porque o rastreamento parece passivo. Observar tem custo operacional.

Compare o processo antes e durante a sonda. Registre início e fim, uso de CPU e memória, status de saída, contagem de linhas ou arquivos e o sinal normal de falha. Se a execução instrumentada levar muito mais tempo ou mudar a ordem, descarte-a como referência de comportamento e investigue o motivo. Uma sonda que altera o sistema ainda pode revelar dependências, mas não deve definir a paridade.

O registro dentro da aplicação vem depois. Ative-o por uma variável de ambiente desligada por padrão e emita eventos nos limites do negócio, não em cada chamada de sub-rotina. Um evento útil informa o modo selecionado, o identificador da entrada, o resultado da regra, o caminho da dependência, a ação externa e o status final. Não registre linhas brutas só porque o código antigo não classifica dados. Oculte valores antes da serialização para que dados sensíveis nunca cheguem ao destino do log.

Um wrapper costuma ser mais seguro do que alterar o script. Ele pode capturar o diretório de trabalho, o ambiente higienizado, os argumentos, os horários de início e fim, o status de saída e hashes de resultados definidos. Mantenha a ordem dos argumentos e use exec quando o wrapper precisar preservar o comportamento de processos e sinais. Teste a propagação de sinais, pois agendadores podem usar sinais de término para impor uma janela de execução. Um wrapper que engole o sinal altera o contrato de produção.

Não deixe rastreamento temporário sem responsável e data de remoção. Pontos de diagnóstico tendem a virar permanentes, em especial quando produzem o único registro útil de falha. Se um ponto merecer permanecer, trate-o como observabilidade mantida: documente esquema, rotação, controle de acesso, ocultação de dados e comportamento em falhas. Decida o que acontece se o destino dos logs encher ou desaparecer. Um lote antigo não deve parar de lançar faturas porque um novo disco de diagnóstico ficou cheio.

O resultado da observação deve atualizar linhas específicas do registro. Troque um caminho de módulo suposto pelo caminho observado, adicione um novo processo filho ou mude um ponto de entrada de configurado para observado. Guarde o rastro bruto separadamente, com controles de acesso mais rígidos, e registre como ele foi coletado. Essa separação mantém o inventário útil sem transformá-lo em depósito de dados de clientes ou segredos.

Reconstruir o CPAN é trabalho de comprovação

Um módulo citado em use não é automaticamente uma dependência do CPAN. Ele pode vir com aquela versão de Perl, ser instalado por um pacote do sistema operacional, morar no repositório ou ser uma cópia alterada localmente que usa o nome de um módulo público. Por outro lado, um script pode carregar um módulo de forma dinâmica sem uma instrução use visível. Monte o conjunto de dependências a partir do ambiente em execução.

Para cada ponto de entrada confirmado, registre os caminhos dos módulos carregados em um ambiente seguro de teste:

perl -MData::Dumper -e 'END { print Dumper(\%INC) } do shift' /opt/legacy-perl/bin/post.pl

Essa sonda simples não é segura para um script que faz trabalho assim que é carregado. Use-a somente em uma cópia do ambiente com escritas externas bloqueadas ou adicione temporariamente um ponto de diagnóstico a um branch de teste. %INC associa nomes de módulos carregados aos arquivos escolhidos pelo Perl, expondo cópias privadas e surpresas na ordem dos caminhos. Teste mais do que o caminho feliz, pois os carregamentos condicionais só aparecem quando seu branch roda.

Compare quatro fontes: importações encontradas no código, %INC de execuções representativas, arquivos em diretórios locais de bibliotecas e distribuições instaladas informadas pelo host original. perldoc perllocal pode conter um registro de módulos instalados por ferramentas do CPAN, embora pacotes do sistema e cópias manuais possam deixá-lo incompleto. O banco de pacotes do sistema operacional fornece outra parte. Nenhuma fonte deve ser a única autoridade.

Escreva as dependências diretas reconstruídas e suas restrições de versão no cpanfile. Fixe o que a aplicação demonstra precisar, não todo módulo transitivo presente num servidor antigo. Em seguida, use Carton ou outro instalador controlado para resolver e instalar em um diretório isolado. Guarde a saída do resolvedor e os logs de compilações com falha como provas do projeto.

requires 'DBI', '1.643';
requires 'DateTime', '1.54';
requires 'Text::CSV_XS', '1.49';

Essas versões são ilustrativas, não recomendações. Suas restrições devem vir do host funcional, dos requisitos do código-fonte e dos testes de comportamento. Se nenhuma versão foi declarada, primeiro registre a versão instalada que produziu a referência. Só relaxe a restrição depois que testes mostrarem que outra versão preserva o comportamento.

Quando uma versão antiga deixa de instalar, identifique a falha exata. Um compilador ausente, uma biblioteca C indisponível, uma distribuição removida, um teste com falha e código incompatível com um Perl novo exigem soluções diferentes. Não resolva os cinco copiando o antigo diretório site_perl. Essa cópia pode preservar um módulo binário compilado para a ABI errada e deixar uma falha que só aparece mais tarde sob carga. Arquive distribuições e correções originais quando as licenças permitirem, mas torne a nova compilação reproduzível a partir de entradas declaradas.

Expressões regulares são regras executáveis

A regex perigosa raramente é a mais longa. É aquela cujo resultado decide um preço, uma classe de conta, um destino de roteamento, um motivo de rejeição ou uma marca de conformidade. Trate essas expressões como regras de negócio mesmo que estejam dentro de uma substituição ou de um grep de uma linha. Regex de formatação e regex de decisão precisam de revisões diferentes.

Encontre candidatas com a busca no código e classifique-as pela consequência. A sintaxe do Perl torna pouco realista uma extração estática perfeita, então examine os branches e as saídas próximas em vez de contar metacaracteres. Preste atenção especial a substituições, variáveis de captura como $1, alternativas com vocabulário de negócio e padrões construídos a partir da configuração.

O manual perlre explica que o Perl escolhe primeiro a correspondência mais à esquerda e que os quantificadores são gulosos por padrão. Esses fatos parecem básicos, mas se transformam em comportamento de negócio quando alternativas se sobrepõem ou capturas alimentam cálculos posteriores. Uma limpeza futura que mude a ordem das alternativas ou acrescente uma âncora pode alterar quais registros de clientes se qualificam. Mudanças em Unicode e localidade também podem alterar classes de caracteres e conversão entre maiúsculas e minúsculas.

Transforme cada expressão com consequências em uma tabela nomeada de exemplos antes de refatorá-la:

my @cases = (
    ['ACCT-001-EU',  'eu',       1],
    ['ACCT-001-US',  'domestic', 1],
    ['acct-001-eu',  undef,      0],
    ['ACCT-001-EU ', undef,      0],
);

for my $case (@cases) {
    my ($input, $class, $accepted) = @$case;
    my ($got) = $input =~ /\AACCT-\d{3}-(EU|US)\z/;
    my $ok = defined $got ? 1 : 0;
    die "acceptance changed for <$input>" if $ok != $accepted;
}

Os valores de exemplo foram inventados para mostrar o formato de um teste de caracterização. Casos reais devem vir de entradas de produção anonimizadas, registros rejeitados, exemplos dos operadores e condições de limite. Preserve espaços iniciais, codificação, finais de linha, campos vazios e entradas malformadas. Normalizar os dados de teste cedo demais apaga o comportamento que você precisa descobrir.

Não traduza uma regex densa diretamente para outra expressão igualmente densa na linguagem de destino. Primeiro nomeie a regra em termos do domínio, mantenha o padrão original como oráculo dos casos e escreva testes para valores aceitos, rejeitados e campos extraídos. Algumas expressões devem virar código normal de análise ou uma tabela porque a regra precisa ser revisada por pessoas que não falam regex.

Registre o comportamento nos limites do sistema

Testes unitários adicionados a partes internas antigas muitas vezes oficializam acidentes de implementação e deixam de lado o contrato do qual outros sistemas dependem. Primeiro, capture o comportamento nos limites: arquivos de entrada, argumentos de comandos, leituras do banco de dados, linhas emitidas, códigos de saída, saída padrão, erro padrão, mensagens e mudanças de estado. Isso abre espaço para mudar a arquitetura interna mais tarde.

Escolha um conjunto representativo do tráfego de produção gravado ou de entradas copiadas com segurança. Remova ou substitua por tokens os valores sensíveis, mas preserve comprimentos, classes de caracteres, delimitadores e relações que afetam a análise. Para cada execução, guarde a impressão digital do interpretador, o bloqueio das dependências, o ambiente, o hash da entrada, a saída, o status de saída e escritas visíveis externamente. Congele o tempo e as fontes aleatórias quando o programa permitir. Quando não permitir, compare campos estáveis e descreva explicitamente cada campo ignorado.

Um pequeno aparato em shell pode mostrar mais do que uma semana de leitura especulativa:

case_dir=/tmp/perl-parity-case-01
mkdir -p "$case_dir"
cp fixtures/invoice.dat "$case_dir/input.dat"
cd "$case_dir" || exit 1
TZ=UTC LC_ALL=C /opt/oldperl/bin/perl /opt/app/run.pl input.dat >stdout.txt 2>stderr.txt
printf '%s\n' "$?" >exit-status.txt
find . -type f -print | sort >files.txt

Rode esse aparato em um ambiente isolado porque o script pode enviar e-mail, alterar um banco de dados ou chamar outro executável. Redirecionar a saída padrão não contém efeitos colaterais. Substitua destinos externos por gravadores quando possível ou restaure um snapshot do banco entre os casos.

Compare dados estruturados como estruturas. Ordene somente quando o contrato disser que a ordem não importa. Normalize datas e horários apenas se os consumidores os ignorarem. Uma limpeza geral de espaços pode esconder danos num registro de largura fixa; uma ordenação geral de JSON pode esconder uma mudança de ordem numa matriz. Cada normalizador afirma algo sobre o contrato e precisa ser revisado como código.

A responsabilidade mantém o inventário vivo

Um inventário sem responsável vira outro artefato abandonado. Atribua um responsável técnico e um de negócio a cada ponto de entrada ativo. O responsável técnico consegue explicar como ele roda e como restaurá-lo. O responsável de negócio consegue dizer qual resultado ele sustenta e aprovar mudanças nesse resultado. Se ninguém aceitar a responsabilidade de negócio, leve esse fato adiante antes de retirar o código.

Coloque o registro no controle de versão junto com o trabalho de modernização. Uma linha útil inclui estado da prova, última execução confirmada, agenda, identidade do ambiente, entradas, saídas, consumidores, manifesto de dependências, sensibilidade dos dados, sinal de falha, procedimento de reinício e decisão. Evite links para painéis voláteis. Guarde identificadores duráveis que um operador possa pesquisar.

Defina quatro decisões e não finja que são etapas de um único fluxo:

1. Retire código com provas convincentes de desuso e um período reversível de quarentena.
2. Isole código ativo cujo comportamento importa, mas cujo risco de alteração hoje supera seu custo de manutenção.
3. Repare código que possa continuar em Perl com ambiente reproduzível, testes e responsável.
4. Reescreva código cuja função de negócio continue necessária e cujos riscos de ambiente, arquitetura ou equipe justifiquem a substituição.

Um script pequeno pode merecer uma reescrita porque controla uma liquidação. Um programa grande de relatórios pode merecer isolamento porque é estável, separado e fácil de operar. A contagem de linhas representa mal o risco do negócio. Use consequências, frequência de mudanças, capacidade de recuperação, saúde das dependências e qualidade do comportamento observado.

Torne as incógnitas visíveis

Adicione uma coluna explícita para incógnitas em vez de forçar cada linha a um estado de falsa certeza. Entradas comuns incluem um alias de banco não verificado, um diretório de saída sem consumidor conhecido, uma senha fornecida por um wrapper desconhecido ou um módulo encontrado em apenas um host. Dê a cada incógnita um responsável e uma próxima observação. Se não há observação planejada, ela virou silenciosamente um risco aceito.

O registro também deve distinguir uma instância de script de um arquivo-fonte. O mesmo arquivo pode rodar sob duas contas, com configuração, argumentos e permissões diferentes. São dois comportamentos em produção e podem merecer decisões distintas. Calcule o hash do arquivo implantado para descobrir se caminhos aparentemente iguais contêm cópias diferentes. Registre os destinos dos links simbólicos, pois uma troca de versão pode fazer o caminho de ontem apontar para o código de hoje.

Falhas revelam dependências que execuções bem-sucedidas escondem. Examine e-mails do agendador, diretórios de mensagens mortas, arquivos de saída parciais, scripts de repetição e chamados da operação. Um comando de recuperação copiado num manual pode ser a única aresta de entrada para um script de reparo. Se a equipe excluir esse script porque a produção normal nunca o chama, o próximo lote com falha vira o meio de descoberta. Marque como ativos os pontos de entrada usados só na recuperação e teste-os com uma falha reversível.

A retirada também precisa de um contrato de saída. Em um relatório, identifique quem o recebe e o que faz quando ele falta. Em uma transferência, encontre a confirmação ou o registro de conciliação. Em uma tarefa de limpeza, encontre o sintoma de armazenamento, latência ou correção que volta quando ela para. Um script sem chamador visível pode impedir um resultado negativo, como linhas duplicadas ou dados temporários não expirados. Procure a condição que ele suprime.

Use o registro durante incidentes. Quando um operador encontrar uma nova execução, atualizar um interpretador ou descobrir um consumidor, altere o registro no mesmo commit da correção operacional. Depois de vários ciclos de incidentes, o inventário fica mais exato porque incorpora provas obtidas sob pressão real. Uma planilha enviada uma vez à direção envelhece porque as pessoas que aprendem fatos novos não conseguem atualizá-la onde trabalham.

Escolha um limite de capacidade, não um arquivo

Uma reescrita arquivo por arquivo preserva os acidentes da estrutura antiga. Escolha um limite em torno de uma capacidade observável: receber um feed, classificar registros, calcular uma tarifa, gerar um relatório ou lançar um lote. Defina o limite com entradas, saídas, comportamento de erro e mudanças de estado, e então execute os mesmos casos nas implementações antiga e nova.

Implantações do tipo strangler são populares porque reduzem o tamanho da virada, mas estão erradas quando o limite proposto compartilha transações ou estado mutável que não pode ser separado com segurança. Manter dois escritores no mesmo esquema mal compreendido cria mais ambiguidade do que substituir um lote coerente. Nesse caso, crie um leitor em sombra, compare saídas e vire todo o limite de escrita quando a paridade estiver sólida. O limite deve seguir a responsabilidade pelos efeitos, não os nomes de funções em Perl.

Não translitere os idiomatismos do Perl para outra linguagem. Globais implícitas, valores de retorno sensíveis ao contexto, autovivificação, valores verdadeiros e falsos e efeitos colaterais de regex podem ter moldado o programa antigo, mas a arquitetura nova deve deixar estado e erros explícitos. Preserve o comportamento externo do qual os consumidores dependem. Substitua o comportamento interno que existe apenas porque Perl o tornava conveniente.

CodeHero lê toda a árvore com várias linguagens, reescreve Perl em Go, Rust ou TypeScript e verifica o comportamento com um aparato de paridade contra tráfego de produção gravado. Essa abordagem só se encaixa depois que existem provas de execução e casos nos limites. Uma reescrita automatizada não consegue recuperar uma entrada trimestral que ninguém registrou nem uma decisão de operador que vivia fora do código.

Os primeiros dez dias devem reduzir a incerteza

Os primeiros dias de trabalho devem produzir provas, não um módulo reescrito. No primeiro dia, pare a limpeza casual e identifique hosts, repositórios, agendadores e pessoas que recebem saídas. Até o terceiro dia, você deve ter pontos de entrada confirmados, impressões digitais do ambiente e uma lista de consumidores desconhecidos. Até o sexto, execuções representativas devem expor dependências carregadas e efeitos nos limites. Até o décimo, a equipe deve conseguir defender cada decisão com registros, não com confiança.

Mantenha a produção segura enquanto reúne essas provas. Leia a configuração antes de mudá-la. Registre comandos e saídas num log controlado. Remova segredos. Só execute scripts copiados depois de bloquear e-mail, escritas no banco, chamadas remotas e caminhos destrutivos do sistema de arquivos. Peça a um operador que revise qualquer sonda que toque um agendador ativo ou uma conta de produção.

A descoberta incômoda pode ser que ninguém saiba reconstruir o interpretador, várias versões do CPAN tenham desaparecido dos caminhos normais de instalação e a única especificação seja uma regex com os arquivos do ano passado. Isso ainda é progresso. Agora você sabe onde está o risco. Preserve o ambiente funcional, reúna entradas representativas, nomeie o responsável de negócio e torne o comportamento executável em testes.

Não premie o primeiro engenheiro que fizer o código antigo parecer moderno. Premie quem provar o que o negócio ainda exige dele. Com essa prova, excluir e reescrever viram decisões de engenharia em vez de folclore.