Quanto custa migrar PHP 5 para 8.4 sem parar a operação?

Por que corrigir uma falha no PHP 5 significa migrar?

O PHP 5.6 deixou de receber correções de segurança em 31 de dezembro de 2018. O 7.4 parou em 28 de novembro de 2022. O 8.0, em 26 de novembro de 2023. Quando o projeto PHP corrige uma falha, a correção sai só para as versões com suporte, hoje as da linha 8.x.

Foi o que aconteceu em outubro de 2026, quando falhas em PHP, Node.js e Java foram corrigidas em sequência nas versões mantidas. Quem roda uma versão antiga não tem um "patch" para aplicar: o código da correção não existe para a versão dele. Um firewall de aplicação na frente ganha tempo, mas é contenção, não correção.

Por isso, para um sistema em PHP 5, corrigir uma falha e migrar de versão são a mesma tarefa. A pergunta deixa de ser "se" e passa a ser "quanto custa e como fazer sem parar a operação".

O que muda entre o PHP 5 e o 8.4 que quebra o código?

São quase dez anos de versões. A lista completa tem centenas de itens. Estes são os que mais aparecem em sistemas brasileiros escritos entre 2008 e 2016.

• A extensão mysql foi removida no PHP 7.0. Cada mysql_connect, mysql_query e mysql_fetch_assoc precisa virar PDO ou mysqli. Em sistemas da época, são centenas de chamadas.
• ereg, split e mcrypt saíram (7.0, 7.0 e 7.2). As expressões regulares viram preg_*; a criptografia vira OpenSSL ou Sodium, e o dado já gravado precisa continuar legível.
• Construtor com o nome da classe virou aviso no 7.0 e erro no 8.0. Classes antigas simplesmente deixam de inicializar.
• Comparação entre texto e número mudou no 8.0. "abc" == 0 era verdadeiro e passou a ser falso. Nenhum erro é lançado: o if só passa a tomar outro caminho. É o tipo de quebra mais difícil de achar.
• Funções internas lançam TypeError onde antes devolviam um aviso: count(null), strlen(null), array no lugar de texto. No PHP 5 a página carregava com um aviso no log. No 8, a requisição cai.
• each(), create_function() e a sintaxe $texto{0} foram removidos no 8.0. A precedência entre . e + também mudou.
• Propriedade dinâmica ($pedido->desconto = 10 sem declarar $desconto na classe) gera aviso de depreciação desde o 8.2. Em código antigo isso está em todo lugar, e o log cresce aos milhares de linhas por hora.
• No 8.4, o parâmetro Cliente $c = null sem o ? passou a ser depreciado, e a constante E_STRICT também.

// PHP 5: funcionava. PHP 8: TypeError e a requisição cai.
$itens = count($pedido['itens']);   // 'itens' pode não existir
// Depois da migração: o mesmo comportamento, declarado.
$itens = count($pedido['itens'] ?? []);

Fora do código próprio, pesam tanto quanto ele as bibliotecas sem versão para o PHP 8 (frameworks e pacotes PEAR da época), os arquivos codificados por ionCube ou Zend Guard e o banco de dados, quase sempre num MySQL 5.5 com charset utf8 de 3 bytes, que precisa ir junto.

Como migrar sem parar a operação?

Migrar "no susto", trocando a versão do servidor num fim de semana, funciona para um site institucional. Para um sistema que fatura, emite nota ou atende cliente, nós usamos quatro mecanismos, nesta ordem.

• Ambiente paralelo. Um segundo servidor com PHP 8.4 roda ao lado do antigo, apontando para o mesmo banco e a mesma pasta de arquivos. As sessões saem do disco e vão para o banco ou para o Redis, para o usuário não perder o login quando a rota muda de servidor.
• Testes de contrato. Gravamos requisições reais do log do proxy, com dados pessoais mascarados, e reproduzimos as mesmas nas duas versões. Comparamos status, corpo, cabeçalhos e o que foi escrito no banco. Cada diferença vira um item da lista de trabalho. É assim que um sistema sem teste automatizado ganha cobertura sem mil testes escritos à mão.
• Corte por rota. O proxy (nginx) manda uma rota de cada vez para a versão nova. Começa pelas de leitura e baixo risco, como consulta e relatório, e termina em login, pagamento e nota fiscal. Cada rota fica de 24 h a 72 h com o log comparado antes da próxima.
• Volta rápida. Se uma rota apresenta diferença em produção, ela volta ao servidor antigo com uma linha no proxy, em segundos. Para isso valer, o banco não muda de formato durante a migração e os dados gravados por serialize() continuam legíveis nas duas versões. Regra: nunca duas mudanças no mesmo corte.

Ferramentas como PHPCompatibility, Rector e PHPStan encontram o que é mecânico: função removida, sintaxe antiga, tipo errado. A mudança de comportamento, como a comparação que passou a dar falso, só os testes de contrato pegam. E há os esquecidos: cron, scripts de linha de comando, webhooks, e-mail e as integrações que chamam o sistema, não só as que ele chama.

O que determina o preço?

Quatro fatores explicam quase toda a diferença entre uma migração barata e uma cara. Dois deles você mede sozinho, antes de falar com qualquer fornecedor.

Quanto custa, então?

Nós não publicamos preço de migração sem olhar o código: os quatro fatores acima mudam o número por um fator de dez, e um valor médio enganaria metade dos leitores para cada lado. O que publicamos é o primeiro degrau, com preço, prazo e garantia, e como os seguintes são precificados.

Antes de pagar qualquer coisa, três medidas são gratuitas e levam uma tarde: contar as linhas com o cloc, rodar o PHPCompatibility e listar as dependências com a versão de cada uma. Com esses três números, a conversa técnica já sai com uma faixa de esforço, não com uma promessa.