Muita empresa ainda associa PHP a código procedural sem tipos, espalhado em arquivos que ninguém quer abrir. Essa imagem descreve projetos, não a linguagem. A partir do PHP 8, o sistema de tipos deixou de ser decorativo, e é essa mudança que interessa a quem paga a conta de manutenção.

O que "PHP moderno" significa além da versão

Enums substituem constantes mágicas de status e eliminam comparações com strings soltas. Propriedades readonly tornam DTOs previsíveis. Union types e o tipo never documentam contratos que antes viviam em comentários. match acaba com cadeias de switch que caem no caso errado por falta de break. Atributos carregam metadados sem depender de convenções escondidas, e argumentos nomeados reduzem o ruído em chamadas com muitos parâmetros.

Nada disso é estética. Contratos explícitos são o que permite análise estática (PHPStan, Psalm) encontrar defeitos antes da produção, e o que faz uma regra de negócio sobreviver a mudanças sucessivas sem virar arqueologia. Um sistema corporativo raramente morre por falta de recurso de framework: ele morre porque ninguém consegue alterar a regra de desconto com segurança.

Runtime e operação: onde o custo aparece

O JIT do PHP 8 costuma render pouco em aplicações dominadas por banco de dados e I/O, que é o caso da maioria dos sistemas corporativos. O ganho real vem de OPcache bem configurado, preloading de classes e, principalmente, de menos código executado por requisição. Trocar de versão não substitui índice correto no banco nem consulta bem escrita.

O outro eixo é o modelo de execução. PHP-FPM continua sendo a escolha padrão e previsível. Workers de longa duração (RoadRunner, FrankenPHP, Swoole) reduzem o custo de bootstrap por requisição, mas introduzem um risco novo: estado em memória que sobrevive entre requisições. Container de dependência mal escopado, conexão persistente e cache estático passam a vazar dados de um atendimento para outro. Adotar esse modelo exige disciplina de escopo, não apenas troca de servidor.

Um caso concreto e o que exigir do projeto

Uma distribuidora de médio porte mantinha o portal de pedidos em PHP 7.4, sem tipos declarados e sem análise estática no pipeline. Cada nova regra de bonificação exigia leitura manual de várias classes para descobrir onde o cálculo era alterado. A modernização foi feita em etapas: atualização para versão suportada, enums para status de pedido, readonly nos objetos de entrada, análise estática entrando no CI com nível crescente e falha de build a partir de um patamar. O efeito percebido foi qualitativo e mensurável na rotina: menos tempo gasto em leitura para localizar o ponto de mudança e menos defeitos em cálculo chegando ao fechamento.

Um checklist mínimo para projetos PHP corporativos:

  1. Versão suportada, com janela de atualização planejada e não reativa a incidente de segurança.
  2. Análise estática obrigatória no CI, com nível que só sobe.
  3. Tipos declarados nas fronteiras: entrada de requisição, saída de API e objetos de transferência.
  4. Testes cobrindo regra de negócio, não apenas controllers.
  5. Dependências travadas por lockfile e padrões PSR respeitados.
  6. Observabilidade com logs estruturados e rastreio de requisição, para saber onde o tempo é consumido.

Na prática

Quem mantém PHP em produção deve tratar a versão da linguagem como item de infraestrutura, com dono e prazo, não como detalhe do servidor. Comece medindo o que dói: onde a equipe gasta tempo para entender o código, quais módulos concentram defeitos em regra de negócio e quais dependências impedem a atualização. A partir disso, introduza análise estática em modo tolerante, corrija as fronteiras primeiro e só depois endureça o nível. Se houver intenção de migrar para workers de longa duração, revise escopo de dependências e estado em memória antes, porque o modelo novo amplifica decisões ruins que o PHP-FPM mascarava. Modernizar PHP é, na prática, reduzir o custo de mudança do sistema.