Refazer Site Legado em PHP sem Parar a Operação

Refazer site legado em PHP sem parar a operação é possível, e quase sempre é o jeito certo de fazer. O erro clássico é desligar o sistema velho numa sexta-feira e torcer para o novo funcionar na segunda. Neste guia eu mostro como trocar o motor com o carro andando: por onde começar, quando vale a pena, quando não vale e quanto custa errar.

TL;DR

• Refazer site legado em PHP de uma vez só ("big bang") é a forma mais cara de modernizar. A troca por partes, no padrão strangler fig, mantém a operação de pé.
• O PHP 8.1 perdeu o suporte de segurança em 31/12/2025, e o 8.2 perde em 31/12/2026. Pelos dados da W3Techs, 27,5% dos sites em PHP ainda rodam PHP 7 e 7,8% rodam PHP 5.
• Antes de reescrever, meça: inventário de rotas, banco, integrações e o que realmente é usado. Metade do sistema velho costuma não fazer falta.
• Nem todo legado precisa ser refeito. Às vezes atualizar a versão do PHP e blindar o servidor resolve por anos.
• URLs mudaram? Redirecionamento 301 por pelo menos 1 ano, como recomenda o próprio Google.

Por que refazer site legado virou urgência em 2026

Sistema legado é aquele que ainda paga as contas, mas que ninguém mais tem coragem de mexer. Normalmente é um PHP escrito há 8, 10, 15 anos, com regras de negócio enterradas em arquivos de duas mil linhas, consultas SQL montadas na mão e um único desenvolvedor que "sabia como funcionava" e já saiu da empresa.

O problema em 2026 não é estético. É de suporte. Pela tabela oficial de fim de vida do PHP, o PHP 8.1 deixou de receber correções de segurança em 31 de dezembro de 2025. O PHP 8.0 parou em novembro de 2023, o 7.4 em novembro de 2022 e o 5.6 em dezembro de 2018. Na página de versões suportadas, o PHP 8.2 entra na reta final: o suporte de segurança termina em 31 de dezembro de 2026. Quem está no 8.2 hoje tem pouco mais de dois meses.

E não é um problema de nicho. A W3Techs mede o PHP em 69,7% dos sites cujo backend é conhecido. Dentro desse grupo, 27,5% ainda rodam PHP 7 e 7,8% rodam PHP 5. Na prática, um em cada três sites PHP roda numa versão que não recebe mais patch de segurança.

O que isso significa para quem opera

• Hospedagem empurrando a mudança. Provedores removem versões antigas do PHP do painel, e o sistema simplesmente para de subir.
• Dependências travadas. Bibliotecas de pagamento, nota fiscal e e-mail exigem PHP 8.x. Ficar no 7 significa não conseguir atualizar a biblioteca que fala com o gateway.
• Risco jurídico. Se um incidente expuser dados pessoais, a Resolução CD/ANPD nº 15/2024 dá três dias úteis para comunicar a ANPD. Explicar que o servidor rodava uma versão sem suporte há anos não ajuda.

Os sinais de que é hora de refazer site legado

Nem todo sistema velho está doente. O critério não é idade, é custo de mudança. Estes são os sinais que eu uso para decidir com clientes:

1. Toda mudança pequena quebra outra coisa. Alterar o cálculo de frete derruba o relatório de vendas. Isso é acoplamento, e ele só cresce.
2. Ninguém consegue subir o sistema numa máquina nova. Se o ambiente não é reprodutível, cada servidor é uma peça de museu.
3. A versão do PHP ou do framework está fora de suporte e a atualização exige reescrever trechos inteiros (funções mysql_* removidas no PHP 7, por exemplo).
4. O sistema não conversa com o resto. Precisa integrar com WhatsApp, ERP, gateway ou app, e não há API, só telas.
5. O custo de manutenção mensal já se aproxima do custo de uma reescrita parcial distribuída em um ano.
6. A operação contorna o sistema. Planilhas paralelas, "não use aquele botão", processos manuais para tapar buraco.

Se três ou mais itens dessa lista batem, refazer site legado deixa de ser projeto de melhoria e vira gestão de risco.

Quando NÃO refazer site legado (e o que fazer no lugar)

Aqui está a parte que pouca agência fala, porque reescrita vende mais. Eu já recusei reescrever sistemas que só precisavam de cuidado.

Não reescreva quando:

• O sistema é estável e a regra de negócio não muda há anos. Atualizar para PHP 8.3 ou 8.4, corrigir os deprecations e colocar um servidor bem configurado pode dar mais cinco anos de vida.
• O problema real é infraestrutura. Lentidão muitas vezes é falta de índice no banco, OPcache desligado ou servidor compartilhado sobrecarregado. Resolve-se com hospedagem gerenciada, não com código novo.
• Ninguém sabe dizer o que o sistema faz. Reescrever sem entender reproduz os bugs com tecnologia nova. Primeiro documente.
• Existe um SaaS que já faz 90% do trabalho. Para processos genéricos (CRM, financeiro básico), pode ser mais barato migrar. Eu detalho essa decisão no guia sobre sistema próprio ou SaaS.

A alternativa intermediária: atualizar sem reescrever

Entre "deixar como está" e "refazer tudo" existe a modernização no lugar: subir a versão do PHP em etapas, adicionar Composer, isolar a conexão com o banco, cobrir as rotas críticas com testes e colocar o código em versionamento. Ferramentas como o Rector automatizam boa parte das mudanças de sintaxe. É menos glamoroso que um sistema novo, mas para muitos clientes é a decisão financeira certa.

Big bang vs. troca gradual: as quatro estratégias

Para refazer site legado existem basicamente quatro caminhos. A tabela resume o que cada um custa em risco e em tempo de operação parada.

Estratégia	Como funciona	Risco de parada	Quando faz sentido
Atualização no lugar	Sobe versão do PHP e corrige o código existente	Baixo	Sistema estável, código razoável
Big bang	Reescreve tudo e troca num único dia	Alto	Sistemas pequenos, poucas regras
Strangler fig (gradual)	Novo sistema cresce ao redor do velho, rota por rota	Baixo	Sistemas médios e grandes em produção
Substituição por SaaS	Migra dados e processos para um produto pronto	Médio	Processos genéricos, sem diferencial

Por que o big bang falha tanto

Martin Fowler, que batizou o padrão strangler fig em seu artigo de referência, resume o problema: substituir um sistema de TI sério leva muito tempo, e os usuários não podem esperar por funcionalidades novas. Enquanto a equipe reescreve, o negócio continua pedindo mudanças no sistema velho. Você passa a manter dois sistemas, e o novo nunca alcança o antigo.

Outro ponto do texto que eu repito para clientes: boa parte do comportamento legado nem é desejada. Reescrever tudo "igual" é desperdício.

Como funciona a troca gradual na prática

A ideia vem da figueira estranguladora, que cresce em volta de uma árvore até substituí-la. No software, colocamos uma camada na frente do sistema antigo (um proxy reverso como o Nginx) que decide, rota a rota, quem responde: o PHP velho ou o código novo. Começamos pelo que dá mais retorno ou mais dor, e o legado vai encolhendo até poder ser desligado.

Passo a passo para refazer site legado sem parar a operação

Este é o roteiro que seguimos aqui na Agathas Web, adaptado a cada caso.

1. Inventário antes de qualquer linha de código

Ninguém deveria refazer site legado sem saber o que ele faz hoje. Levante tudo: rotas e páginas acessadas (os logs do servidor dizem quais são usadas de verdade), tabelas do banco, tarefas agendadas (cron), integrações externas, e-mails disparados, arquivos enviados por usuários. É comum descobrir um cron que gera boleto às 3h da manhã que ninguém lembrava que existia.

2. Congele o comportamento com testes de caracterização

Antes de mudar, registre o que o sistema faz hoje: entradas e saídas das rotas críticas, cálculos de preço, geração de documentos. Esses testes não julgam se o comportamento está certo, só garantem que o novo faz igual onde precisa fazer igual.

3. Monte o ambiente reprodutível

Containers com a versão exata do PHP, do banco e das extensões. Aqui a gente usa DDEV e Docker no dia a dia, o que permite rodar o legado e o novo lado a lado na mesma máquina e no mesmo servidor de homologação.

4. Coloque o proxy na frente e escolha a primeira fatia

A primeira fatia deve ser pequena e visível: uma área do cliente, um relatório, um formulário. Ela prova o caminho, valida o deploy e dá confiança para a equipe.

5. Resolva o banco de dados com cuidado

O banco é o ponto mais delicado. Nas primeiras fases, o sistema novo costuma ler e escrever no mesmo banco do antigo. Depois, migra-se tabela por tabela, com scripts versionados e sincronização quando necessário. Mudança de esquema sempre compatível com as duas versões ao mesmo tempo.

6. Corte com plano de volta

Cada fatia entra com feature flag ou regra no proxy que permite voltar em minutos. Deploy em horário de baixo uso, monitoramento ativo e rollback ensaiado antes, não improvisado depois.

7. Desligue o legado de verdade

O último passo é o mais esquecido. Rota que não recebe tráfego há 60 dias sai do código. Senão você termina com dois sistemas para sempre.

SEO, URLs e integrações: as armadilhas que derrubam a operação

Quando o projeto de refazer site legado envolve um site público, a parada mais cara nem sempre é o servidor fora do ar. É o tráfego orgânico sumindo semanas depois.

URLs e redirecionamentos

Se as URLs mudam (por exemplo, de produto.php?id=42 para /produtos/cadeira-gamer), cada endereço antigo precisa de um redirecionamento 301 para o novo. A documentação do Google sobre mudança de site recomenda manter os redirecionamentos "pelo maior tempo possível, geralmente pelo menos 1 ano", e avisa que pode levar algumas semanas ou mais para o Google passar a exibir as URLs novas. Planeje a troca fora da sua temporada de vendas.

Integrações que ninguém documentou

• Webhooks de pagamento apontando para um arquivo .php específico.
• Integrações com WhatsApp via soluções não oficiais, que costumam quebrar na migração. É a hora certa de migrar para a API oficial da Meta. Já fizemos isso em projetos que conectam sistema e WhatsApp, e o ganho de estabilidade compensa.
• Apps móveis consumindo endpoints antigos. Mantenha a rota antiga respondendo até a versão nova do app ser adotada.
• Senhas de usuários com hash MD5 ou SHA1. Não dá para converter direto: o padrão é revalidar no próximo login e regravar com password_hash.

Dados pessoais e LGPD

Migração é o momento em que dumps de banco circulam por e-mail, pendrive e máquinas pessoais. Defina quem acessa os dados, use bases anonimizadas em homologação e apague cópias ao final. Um vazamento durante a migração tem o mesmo prazo de comunicação de qualquer outro.

Quanto custa refazer site legado (e o custo de não fazer)

Não existe tabela fixa, e desconfie de quem dá preço sem ver o código. O custo depende de quatro variáveis: número de telas e rotas realmente usadas, complexidade das regras de negócio, quantidade de integrações e estado do banco de dados.

O que posso dizer com segurança é como o custo se distribui num projeto gradual:

• Diagnóstico e inventário: fase curta, mas a que mais economiza depois.
• Infraestrutura e ambiente: containers, proxy, pipeline de deploy. Paga uma vez e serve para o resto da vida do sistema.
• Fatias de migração: o grosso do investimento, diluído em meses, com entrega de valor a cada fatia.
• Desligamento do legado: pequeno, mas obrigatório.

Para ter referências de valor de sistema sob medida em 2026, inclusive onde a IA reduz horas de desenvolvimento, veja o guia sobre quanto custa um sistema sob medida.

O custo de ficar parado

Adiar a decisão de refazer site legado também tem preço. Do outro lado da conta: horas de manutenção corretiva, oportunidades que o sistema não suporta, risco de incidente de segurança e a dependência de uma única pessoa que conhece o código. Projetos de modernização em PHP que acompanho raramente se justificam pela tecnologia nova. Se justificam pelo custo que o legado já gera todo mês.

Como a Agathas Web resolve isso

Trabalho com PHP desde antes de a Agathas Web nascer, em 2008. Hoje mantemos ambientes Moodle de instituições de ensino, servidores Linux de clientes, sistemas em Laravel e Next.js e integrações com a API oficial do WhatsApp. Refazer site legado é parte do nosso dia a dia, quase sempre com o cliente operando normalmente durante todo o processo.

No serviço de desenvolvimento de sistemas sob medida, um projeto de modernização inclui:

• Diagnóstico técnico do código, banco, servidor e integrações, com a recomendação honesta: atualizar no lugar, migrar por partes ou substituir.
• Plano de fatias com prioridade definida junto com você, cronograma e critério de pronto para cada etapa.
• Ambiente reprodutível e deploy automatizado, com rollback ensaiado.
• Mapa de redirecionamentos e acompanhamento no Google Search Console quando há site público envolvido.
• Integrações refeitas pelo caminho oficial, como gateways de pagamento e API do WhatsApp.
• Hospedagem e monitoramento depois da entrega, se você não quiser ter sysadmin próprio.

O processo é simples: você fala com a gente pela página de desenvolvimento sob medida, fazemos uma conversa técnica e, quando necessário, um diagnóstico pago e curto que vira um plano com escopo e valor fechados por fase. Você decide fase a fase se continua.

Conclusão: modernizar sem apagar a luz

Refazer site legado não precisa ser uma aposta de tudo ou nada. Com inventário, testes de caracterização, um proxy na frente e fatias pequenas, o sistema novo cresce enquanto o antigo continua atendendo seus clientes. E, em parte dos casos, a melhor decisão nem é reescrever: é atualizar o PHP e cuidar bem do servidor.

O relógio, porém, está correndo. O PHP 8.2 perde suporte de segurança no fim de 2026, e quem ainda está no 7 ou no 5 já opera sem rede há anos. Se você quer saber qual caminho faz sentido para o seu sistema, fale com a equipe de desenvolvimento da Agathas Web e peça um diagnóstico. A gente olha o código antes de falar em preço.