Upgrade de PHP e Laravel é manutenção, não projeto de inovação
Muita empresa trata a versão do PHP como detalhe de infraestrutura até o dia em que uma biblioteca de emissão fiscal ou um gateway de pagamento deixa de operar no runtime antigo. A partir daí, o upgrade vira urgência, e urgência em software corporativo custa caro: janela de parada negociada às pressas, validação manual no que deveria ser automatizado e risco concentrado em uma única madrugada.
O ponto de partida é entender que PHP e Laravel têm ciclos de suporte distintos. O PHP recebe correções de segurança por um período limitado e, depois disso, vulnerabilidades conhecidas deixam de ser corrigidas. O framework acompanha essas versões e passa a exigir um mínimo de runtime. Ficar para trás em uma camada empurra a outra: manter Laravel novo exige PHP novo, e PHP novo exige dependências atualizadas.
O que realmente trava um upgrade
Na maioria dos sistemas Laravel que já rodam em produção há anos, o obstáculo não está no framework, e sim no que foi construído em volta dele:
- Pacotes de terceiros sem manutenção ativa, que nunca publicaram versão compatível com o PHP atual.
- Código que depende de comportamentos tolerantes do PHP antigo, como propriedades dinâmicas e conversões implícitas de tipo.
- Ausência de testes automatizados nas rotas críticas, o que transforma cada ajuste em validação manual.
- Bibliotecas internas copiadas entre projetos, sem versionamento nem changelog.
- Jobs em fila e integrações que assumem formatos e horários fixos de execução.
Esse conjunto é o que costuma definir o prazo real do projeto, não a troca de versão no gerenciador de dependências.
Exemplo prático: distribuidora de autopeças com pedidos e faturamento
Uma distribuidora de autopeças com operação em vários estados mantinha o sistema de pedidos e faturamento em Laravel rodando sobre uma versão de PHP já fora do período de correções de segurança. A integração com o ERP da matriz e a emissão de documentos fiscais eram os pontos mais sensíveis: qualquer indisponibilidade em horário comercial parava a expedição.
O upgrade não foi feito de uma vez. A equipe congelou novas funcionalidades por algumas semanas, escreveu testes de caracterização nas rotas de pedido, faturamento e consulta de estoque, e subiu a aplicação em etapas: primeiro homologação com carga real de dados, depois um subconjunto de lojas, por fim toda a operação. O ganho não foi apenas técnico. A migração ocorreu sem interrupção perceptível para as filiais e deixou a base de código pronta para receber as versões seguintes sem repetir o mesmo esforço.
Na prática
Para quem mantém Laravel em produção, algumas decisões reduzem o custo desse tipo de manutenção:
- Trate a versão do PHP como dependência do produto, com data de revisão no calendário, e não como assunto exclusivo da infraestrutura.
- Verifique dependências desatualizadas com frequência e avalie pacotes sem release recente antes que eles bloqueiem o próximo upgrade.
- Invista em testes de caracterização nos fluxos que geram receita: pedido, faturamento, autenticação e integrações externas.
- Habilite o registro de avisos de depreciação nos ambientes de teste e corrija aos poucos, enquanto o sistema ainda funciona.
- Faça releases graduais, com subconjunto de usuários e rollback preparado, em vez de uma janela única para toda a operação.
- Mantenha homologação com o mesmo runtime e as mesmas extensões da produção, incluindo filas e agendador de tarefas.
Upgrade de PHP e Laravel em sistema corporativo não é evento heroico: é rotina de manutenção. Quem transforma isso em processo previsível gasta menos em cada ciclo e mantém o sistema apto a evoluir quando o negócio pedir.