Existe uma categoria de sistema que quase toda empresa com alguns anos de operação tem: aquele que funciona, ninguém quer tocar, e todo mundo sabe que um dia vai dar problema.

Ele foi feito por alguém que não trabalha mais lá. Roda em uma versão de PHP que parou de receber correções há tempos. Ninguém sabe se atualizar vai quebrar. E, ao mesmo tempo, ele é usado todos os dias — o financeiro depende dele, ou o atendimento, ou o controle de estoque.

A recomendação padrão para essa situação é “atualize”, e ela raramente é aplicável de imediato. Este guia trata do que fazer nesse intervalo: como reduzir o risco enquanto o sistema continua no ar, como atualizar sem parar a operação, e como decidir quando manter deixa de valer a pena.

Por que isso é um risco real

Vale nomear o problema com precisão, porque “sistema antigo” soa mais como incômodo do que como exposição.

Quando uma versão de linguagem sai do ciclo de suporte, ela deixa de receber correções de segurança. Vulnerabilidades descobertas a partir dali permanecem abertas — e continuam sendo descobertas, porque pesquisadores e atacantes seguem examinando código amplamente usado.

Três características tornam isso mais grave do que parece:

• O risco é silencioso. Nada quebra. O sistema continua funcionando exatamente como antes, o que dá a impressão de que está tudo bem.
• O risco cresce com o tempo. Cada vulnerabilidade descoberta se acumula sobre as anteriores, e a lista é pública.
• A exploração é automatizada. Não é preciso que alguém escolha o seu sistema — programas varrem a internet procurando versões vulneráveis, sem saber nem se importar com o que aquele sistema faz.

E há um agravante específico de aplicações internas: elas costumam conter dados sensíveis — cadastros de clientes, informações financeiras, documentos — justamente porque são os sistemas onde a empresa opera de fato.

O ciclo de suporte do PHP e a razão pela qual versões saem de circulação estão detalhados no artigo sobre servidor para PHP.

Os quatro caminhos

Não existe uma resposta única. Existem quatro, com custos e prazos diferentes:

Caminho	Esforço	Reduz risco?	Quando faz sentido
Isolar	Baixo	Parcialmente	Medida imediata, sempre
Atualizar por etapas	Médio a alto	Sim	Quando o código é recuperável
Encapsular	Médio	Parcialmente	Quando não há como tocar no código
Substituir	Alto	Sim	Quando manter custa mais que refazer

A leitura importante: o isolamento não é alternativa aos outros três — é o primeiro passo em todos os cenários. Ele é rápido, barato e reduz a exposição enquanto a decisão de longo prazo é tomada.

Caminho 1: isolar

A medida que deve ser aplicada esta semana, independentemente do que se decida depois.

O objetivo é reduzir quem consegue alcançar o sistema e o que ele consegue alcançar:

1. Restringir o acesso. Se é um sistema interno, ele não precisa estar disponível para toda a internet. Limitar por rede, por endereço ou por acesso remoto controlado elimina a maior parte da exposição automatizada.
2. Separar do restante da infraestrutura. Se o sistema legado divide servidor com o site institucional ou com a loja, um comprometimento nele alcança os vizinhos. Movê-lo para um ambiente separado contém o dano.
3. Limitar o que ele acessa. Um sistema que só precisa ler um banco não deveria poder escrever em outro. Permissões mínimas reduzem o alcance de um eventual comprometimento.
4. Colocar uma camada na frente, que filtre padrões conhecidos de ataque antes que cheguem à aplicação.
5. Reforçar autenticação, com segundo fator e senhas fortes — muitos sistemas antigos têm controles de acesso frágeis.
6. Monitorar acesso e integridade, para saber se algo mudou sem que ninguém tenha publicado nada.

O item 1 costuma resolver mais do que todos os outros juntos. Um sistema interno acessível apenas pela rede da empresa ou por acesso remoto controlado deixa de ser alvo da varredura automatizada — que é a origem da esmagadora maioria dos comprometimentos.

Vale um alerta sobre o item 2: separar exige um ambiente onde você controle a configuração, o que hospedagem compartilhada não permite. É um dos argumentos concretos para um servidor com acesso root nesse cenário.

Caminho 2: atualizar por etapas

A opção que resolve de fato, quando o código permite.

O erro mais comum aqui é tentar saltar várias versões de uma vez. Cada versão principal traz mudanças de comportamento, e acumular todas em uma única migração transforma o projeto em uma investigação sem fim — cada erro pode vir de qualquer uma das versões puladas.

O método que funciona:

1. Monte um ambiente de teste com uma cópia fiel do sistema. Isso é indispensável — não se atualiza um sistema legado em produção.
2. Ative o registro de avisos de descontinuação na versão atual. Eles apontam exatamente o que vai quebrar na próxima.
3. Avance uma versão por vez, corrigindo o que aparecer antes de seguir.
4. Teste o fluxo real a cada etapa, com os casos de uso que a operação realmente executa.
5. Documente cada correção, porque quem fizer a próxima etapa vai precisar do contexto.
6. Só então aplique em produção, com backup e janela definida.

O passo 2 é o mais subestimado: a própria linguagem avisa o que vai deixar de funcionar, e esses avisos costumam estar desativados em produção. Ativá-los em um ambiente de teste transforma a migração de adivinhação em lista de tarefas.

Sobre dependências: aplicações antigas frequentemente usam bibliotecas que também pararam no tempo. Atualizar a linguagem pode exigir substituir bibliotecas que não acompanharam — e às vezes essa é a parte mais trabalhosa.

Caminho 3: encapsular

Uma opção intermediária para casos em que mexer no código não é viável — porque ninguém entende mais como ele funciona, porque o custo de testar é alto demais, ou porque a empresa que o fez não existe mais.

A ideia é congelar o sistema em um ambiente controlado e isolado, mantendo a versão antiga que ele exige, enquanto o resto da infraestrutura evolui normalmente.

O que isso permite:

• Manter o sistema funcionando sem forçar o restante do ambiente a permanecer antigo.
• Reduzir o alcance de um comprometimento, já que o ambiente é fechado.
• Migrar de servidor sem alterar o sistema, porque o ambiente vai junto.
• Ganhar tempo para planejar a substituição com calma.

O que isso não resolve, e precisa ser dito: as vulnerabilidades continuam lá. Encapsular reduz o alcance de um problema, não a probabilidade de ele existir. É uma medida de contenção com prazo, não uma solução permanente.

Existe também suporte estendido comercial para versões já encerradas, oferecido por terceiros, que continua fornecendo correções de segurança. É uma opção legítima para ganhar tempo, com custo próprio — e com a mesma ressalva: adia a decisão, não a elimina.

Caminho 4: substituir

A decisão mais cara e, em alguns casos, a única racional.

Os sinais de que manter deixou de valer a pena:

• O custo de manter supera o de refazer, considerando horas de manutenção, contornos e incidentes.
• Ninguém consegue mais alterar o sistema com segurança.
• Ele impede projetos — integrações que não podem ser feitas, funcionalidades que não podem ser adicionadas.
• As dependências não têm substituto em versões atuais.
• O risco não é mais aceitável para o tipo de dado que ele processa.

Uma observação prática sobre substituição: ela raramente precisa ser total e imediata. É comum substituir por partes, mantendo o sistema antigo funcionando enquanto módulos são migrados um a um — o que reduz o risco do projeto e permite entregar valor antes do fim.

Vale também a pergunta que às vezes encerra a discussão: o sistema ainda é necessário? Sistemas legados sobrevivem por inércia, e não é raro descobrir que uma ferramenta pronta resolve hoje o que ele fazia, ou que o processo que ele automatizava mudou.

O que decidir agora

Um roteiro para sair da paralisia, que é o estado mais comum nesses casos:

1. Faça o inventário: quais sistemas legados existem, em que versão rodam, quem os usa, que dados guardam.
2. Classifique por risco, cruzando exposição à internet com sensibilidade dos dados.
3. Isole todos, começando pelos de maior risco. É rápido e não depende de decisão estratégica.
4. Avalie caso a caso entre atualizar, encapsular e substituir.
5. Defina prazo para cada um, mesmo que longo. Sem prazo, a decisão nunca acontece.
6. Garanta backup com restauração testada de todos eles, porque sistemas antigos costumam ter os backups menos verificados.

O passo 5 é o que separa gestão de adiamento. Um sistema legado sem prazo definido é uma decisão de mantê-lo indefinidamente, tomada por omissão.

O que evitar

• Deixar exposto à internet sem necessidade — é o erro que mais custa.
• Atualizar direto em produção, sem ambiente de teste e sem backup.
• Saltar várias versões de uma vez.
• Manter no mesmo servidor de sistemas críticos e atualizados.
• Adiar sem prazo, que é como a maior parte dos casos evolui.
• Assumir que ninguém vai encontrar, quando a varredura é automatizada e indiscriminada.

Conclusão

Um sistema legado que funciona não é um problema urgente — até o dia em que é. O risco é silencioso e crescente, e a exploração não depende de alguém escolher a sua empresa.

A boa notícia é que a medida de maior impacto é a mais barata: isolar. Restringir o acesso, separar da infraestrutura principal e limitar o que o sistema alcança reduz drasticamente a exposição, e pode ser feito sem tocar em uma linha de código.

Feito isso, a decisão entre atualizar por etapas, encapsular ou substituir pode ser tomada com calma — desde que tenha prazo. Se o seu caso exige separar ambientes e controlar a configuração, conheça o Cloud Server para PHP da TBF Host e avalie o ambiente adequado ao sistema.

Perguntas frequentes

Por que rodar PHP em versão sem suporte é arriscado?

Porque a versão deixa de receber correções de segurança, enquanto vulnerabilidades continuam sendo descobertas e divulgadas publicamente. O risco é silencioso — nada quebra e o sistema segue funcionando — e crescente, já que cada falha descoberta se acumula. A exploração é automatizada e não depende de alguém escolher a sua empresa.

O que fazer com um sistema antigo que não pode ser desligado?

Isolar imediatamente: restringir o acesso à rede necessária, separar da infraestrutura principal, limitar as permissões que ele tem e reforçar a autenticação. Feito isso, avaliar com calma entre atualizar por etapas, encapsular em um ambiente controlado ou substituir — sempre com prazo definido.

Como atualizar a versão do PHP de uma aplicação antiga?

Uma versão por vez, nunca saltando várias. Monte um ambiente de teste com cópia fiel do sistema, ative o registro de avisos de descontinuação — que apontam exatamente o que vai quebrar —, corrija o que aparecer, teste o fluxo real e só então avance para a próxima versão.

O que significa encapsular um sistema legado?

É congelá-lo em um ambiente controlado e isolado, mantendo a versão antiga que ele exige enquanto o restante da infraestrutura evolui. Permite migrar de servidor sem alterar o sistema e reduz o alcance de um comprometimento — mas não elimina as vulnerabilidades, que continuam presentes.

Existe suporte para versões de PHP já encerradas?

Existe suporte estendido comercial oferecido por terceiros, que continua fornecendo correções de segurança para versões fora do ciclo oficial. É uma opção legítima para ganhar tempo, com custo próprio, mas adia a decisão em vez de eliminá-la — a atualização continua sendo o caminho.

Quando vale mais substituir do que manter um sistema legado?

Quando o custo de manter supera o de refazer, quando ninguém consegue mais alterá-lo com segurança, quando ele impede projetos que a empresa precisa fazer, quando as dependências não têm substituto em versões atuais ou quando o risco deixou de ser aceitável para os dados que ele processa.

Preciso substituir tudo de uma vez?

Raramente. É comum substituir por partes, mantendo o sistema antigo funcionando enquanto módulos são migrados um a um. Isso reduz o risco do projeto e permite entregar valor antes do fim. Vale também perguntar se o sistema ainda é necessário — muitos sobrevivem por inércia.

Qual a medida mais urgente para um sistema legado?

Restringir o acesso. Um sistema interno acessível apenas pela rede da empresa ou por acesso remoto controlado deixa de ser alvo das varreduras automatizadas, que são a origem da maioria dos comprometimentos. É rápido, barato e não exige tocar em nenhuma linha de código.