Por que a versão do runtime é decisão de negócio

PHP e Laravel têm ciclos de lançamento previsíveis. O PHP mantém correções por um período limitado e depois encerra o suporte daquela linha. O Laravel publica uma versão maior por ano e descontinua o suporte às anteriores. Isso significa que a pergunta relevante não é "quando vamos atualizar", mas "quanto tempo conseguimos ficar sem atualizar sem aumentar o risco".

Quando o time fica duas ou três versões atrás, o custo muda de natureza. Deixa de ser uma tarefa de atualização e passa a ser um projeto de reescrita parcial: cada versão intermediária carrega mudanças de comportamento, deprecações e alterações em pacotes de terceiros que ninguém acompanhou. Pular várias versões de uma vez obriga a depurar todas essas mudanças em conjunto, com o sistema em produção e clientes usando.

Há também o efeito na segurança. Correções de vulnerabilidade deixam de ser publicadas para versões fora de suporte, e o sistema passa a depender de sorte. Não é exagero: uma falha conhecida em componente sem manutenção é um problema de continuidade de negócio, não de estilo de código.

O que apodrece quando a atualização é sempre adiada

  • Dependências: pacotes do Composer param de receber correções para versões antigas do PHP, e o composer update vira uma bomba de comportamento imprevisível.
  • Infraestrutura: imagens base de container, extensões nativas e drivers de banco deixam de evoluir junto, e o ambiente de produção passa a ser um artefato único e difícil de reproduzir.
  • Testes: sem cobertura nos fluxos críticos, ninguém autoriza a subida de versão, e a decisão fica travada por insegurança, não por análise.
  • Conhecimento: quem montou o ambiente original muda de time ou sai da empresa, e o detalhe de configuração vira arqueologia.
  • Contratação: profissionais experientes evitam stacks defasadas, e o time passa a gastar energia defendendo decisões antigas em vez de entregar.

Um caso concreto: distribuidora com integração fiscal

Uma distribuidora de médio porte mantinha o ERP em Laravel, rodando em uma versão de PHP que já não recebia correções. A operação dependia de duas integrações: emissão de documentos fiscais e catálogo de fornecedores. Em determinado momento, a biblioteca de emissão fiscal passou a exigir uma versão mais recente do PHP, e o fornecedor do serviço do outro lado mudou o formato de resposta da API.

O time descobriu que a atualização não era isolada: subir o PHP exigia subir o Laravel, que exigia substituir dois pacotes internos sem testes automatizados. O resultado foi uma janela de manutenção em fim de semana, com risco de bloquear o faturamento, e um esforço concentrado que teria sido bem menor se cada versão tivesse sido absorvida em passos anuais. O problema não foi técnico, foi de sequenciamento: a dívida foi acumulada até virar parada de operação.

Na prática

Para quem mantém Laravel e PHP em produção, a atualização precisa entrar no roadmap com orçamento e data, não como sobra de sprint:

  1. Mantenha um inventário de versões (PHP, Laravel, extensões, banco) com a data de fim de suporte de cada uma e revise a cada trimestre.
  2. Reserve uma janela recorrente no ano para subir uma versão maior, mesmo quando não há pressão externa. Passos pequenos custam menos que saltos grandes.
  3. Cubra com testes automatizados os fluxos de dinheiro e de integração antes de mexer em versão, para que a subida seja verificável e não heroica.
  4. Trate pacotes de terceiros como dependência de negócio: verifique se estão mantidos e qual versão do framework suportam antes de assumir o compromisso.
  5. Faça a subida em ambiente reproduzível, com a mesma imagem e as mesmas extensões da produção, e valide a aplicação com dados reais anonimizados.

Adiar atualização não é economizar. É transferir custo para o futuro com juros, e normalmente no pior momento possível: quando a integração externa quebra ou quando a falha de segurança aparece.