Migrando Sites PHP Legados Sem Interromper as Operações de Negócios

Na DigiForge, vimos muitos projetos de migração de PHP legado darem errado — não porque a tecnologia era difícil, mas porque o negócio continuava rodando durante a mudança. A palavra "migração" vem do latim para mover-se de um lugar para outro, e na computação significa especificamente "começar a usar um novo sistema de computador, ou mover informações de um tipo de sistema para outro" [1]. Isso parece simples, mas quando você está migrando um monólito PHP que lida com pedidos, sessões de usuário e integrações de pagamento, o verdadeiro desafio é garantir que seus clientes nunca percebam nada.

Avalie Antes de Tocar uma Linha de Código

Antes mesmo de pensar em escrever novos roteadores ou instalar um framework moderno, auditamos a aplicação existente — não apenas seu código, mas seu comportamento em tempo de execução. Comece com um inventário completo de todos os pontos de entrada: cada rota, cada cron job, cada tarefa na fila. Aplicações PHP legadas geralmente têm endpoints ocultos — talvez um cron.php que executa a folha de pagamento todo domingo, ou um endpoint de API personalizado usado por um serviço de envio de terceiros. Se você perder um, a migração quebrará algo.

Durante a auditoria, documente também o fluxo de dados: como a aplicação antiga se conecta ao banco de dados? Existem procedimentos armazenados? Há um sistema de arquivos compartilhado para imagens enviadas ou arquivos de sessão? Muitas aplicações PHP legadas dependem de sessões baseadas em arquivo, que não escalam horizontalmente. Essa é uma bandeira vermelha que tratamos cedo, geralmente migrando as sessões para Redis ou um banco de dados.

Escolha uma Estratégia de Migração Compatível com Sua Tolerância a Risco

Na DigiForge, geralmente recomendamos uma de três estratégias, dependendo do nível de risco que a empresa pode suportar.

A Reescreva do Tipo Big Bang

Esta é a mais drástica: você constrói o novo sistema do zero e faz a migração de uma só vez. Também é a mais arriscada. Já vimos funcionar apenas quando o aplicativo legado é pequeno (pense em algumas dezenas de páginas) ou quando a empresa pode tolerar uma janela de manutenção planejada. Para qualquer coisa com transações em tempo real ou clientes 24/7, evite essa abordagem.

O Padrão Figueira Estranguladora

Batizada em homenagem à planta tropical que lentamente envolve seu hospedeiro, esse padrão permite substituir partes do aplicativo legado de forma incremental. Você roteia URLs específicas ou endpoints de API para o novo código enquanto o restante ainda roda no PHP antigo. Um balanceador de carga ou proxy reverso (como Nginx ou HAProxy) pode direcionar o tráfego com base no caminho da requisição. Cada peça substituída reduz o risco, pois você está alterando apenas uma pequena superfície por vez. Usamos esse padrão em quase todas as migrações de grande porte.

Feature Flags em Toda Parte

Mesmo com um strangler fig, as feature flags fornecem um interruptor de segurança. Se o novo endpoint de checkout lançar erros, você aciona uma flag e o tráfego volta para o código antigo — tudo sem precisar fazer deploy. Ferramentas como LaunchDarkly ou um simples toggle baseado em banco de dados funcionam bem. Nós codificamos tudo por trás de uma flag, até mesmo a conexão com o banco de dados. Dessa forma, podemos testar uma nova consulta em produção com apenas alguns usuários antes de liberá-la para todos.

Execute a Migração com Zero Downtime

Zero downtime não significa risco zero — significa que o usuário nunca vê uma página de erro. O segredo é a escrita dupla: ao migrar para um novo esquema de banco de dados ou um backend de armazenamento diferente, escreva dados nos sistemas antigo e novo simultaneamente. Comece escrevendo em ambos, lendo do antigo. Quando o novo sistema estiver sincronizado e você tiver verificado a integridade dos dados, mude as leituras para o novo sistema. Por fim, pare de escrever no sistema antigo. Isso funciona para bancos de dados, filas, armazenamento de arquivos e até integrações de API.

<?php
// Example: dual-write to old and new databases
$legacyDb = getLegacyConnection();
$newDb = getNewConnection();

function saveOrder($orderData) {
    global $legacyDb, $newDb;
    // Write to both
    $legacyDb->insert('orders', $orderData);
    $newDb->insert('orders', $orderData);
}

// Read from legacy until we verify new data
function getOrder($orderId) {
    global $legacyDb;
    return $legacyDb->fetchOne('SELECT * FROM orders WHERE id = ?', [$orderId]);
}

Durante a fase de escrita dupla, execute scripts de reconciliação a cada poucos minutos para comparar os dois armazenamentos. Qualquer divergência é detectada rapidamente. Assim que o novo sistema corresponder por um ciclo completo de negócios (geralmente 48 horas), você inverte as leituras. Monitore os logs de erro de perto na próxima hora — se algo parecer errado, reverta.

Gerenciamento de Estado de Sessão

O PHP legado geralmente usa $_SESSION armazenada em arquivos. Um novo aplicativo Laravel ou Symfony provavelmente espera sessões em banco de dados ou Redis. Para manter os usuários logados durante a migração, implementamos uma ponte de sessão: o aplicativo antigo escreve sessões tanto em arquivos quanto em um Redis compartilhado; o novo aplicativo lê do Redis. Após a conclusão da migração, você desativa o gravador de arquivos e remove o manipulador de sessão antigo.

Validação Pós-Migração e Planejamento de Rollback

Mesmo com um planejamento cuidadoso, algo vai dar errado. Isso não é pessimismo — é realismo de engenharia. Antes de acionar o interruptor final, escreva um plano de reversão que inclua restaurar registros DNS, reverter alterações no esquema do banco de dados e reativar o aplicativo antigo a partir de um snapshot. Pratique a reversão no ambiente de staging pelo menos uma vez.

Na DigiForge, sempre mantemos o ambiente de produção antigo em execução por pelo menos duas semanas após uma migração importante. O custo de alguns servidores extras é insignificante comparado ao custo de uma reversão malsucedida que leva horas.

A validação vai além de verificar se as páginas carregam. Executamos testes automatizados de transações de negócios: fazer um pedido, atualizar um perfil, processar um reembolso. Compare a saída de endpoints críticos da API entre o sistema antigo e o novo. Se você usa uma ferramenta de monitoramento como New Relic ou Sentry, configure alertas personalizados para qualquer erro 5xx ou consultas lentas. Por fim, envolva a equipe de negócios — peça que eles executem seus fluxos de trabalho diários no novo sistema em um ambiente de staging antes de entrar em produção.

Armadilhas Comuns e Como as Evitamos

• Presumir que o código antigo está correto. O PHP legado frequentemente tem bugs silenciosos que se tornaram 'funcionalidades.' Repetir cada comportamento? Às vezes é mais seguro corrigir o bug na nova versão se o negócio concordar.
• Esquecer cron jobs e tarefas agendadas. Aquelas chamadas curl antigas para um script personalizado? Elas precisam de um lar no novo sistema. Migramos tarefas cron para um agendador de tarefas como o scheduler do Laravel ou um worker dedicado.
• Negligenciar integrações de terceiros. Gateways de pagamento, APIs de envio e webhooks de parceiros enviam dados em formatos específicos. Teste os endpoints de integração cedo — você não quer descobrir uma incompatibilidade de formato na Black Friday.

Outra lição que aprendemos: não confie na documentação antiga. O código é a fonte da verdade. Sempre fazemos uma análise aprofundada do código com o desenvolvedor original (se disponível) ou com um membro da equipe que o manteve por anos. O modelo mental deles sobre as peculiaridades do aplicativo é inestimável.

Conclusão

Migrar um site PHP legado é como realizar uma cirurgia de coração aberto em um paciente que está correndo uma maratona. O risco é real, mas a recompensa — desempenho moderno, segurança e produtividade do desenvolvedor — é enorme. Na DigiForge, orientamos dezenas de empresas nesse processo. O segredo é avançar em etapas pequenas e reversíveis, manter sempre o sistema antigo em funcionamento e nunca parar de monitorar até ter certeza de que o novo sistema está estável.

Lembre-se: a migração não é apenas sobre tecnologia — é sobre manter seu negócio operacional enquanto você troca o motor em pleno voo. Planeje cuidadosamente, teste incansavelmente e sempre tenha um plano de reversão pronto. Seus usuários nunca saberão que algo mudou.