A figueira estranguladora cresce a partir de uma semente deixada no alto de outra árvore. Ela desce raízes, envolve o tronco hospedeiro e, quando a árvore original morre, permanece de pé sozinha, com o mesmo formato. Martin Fowler tomou emprestada essa imagem para batizar um padrão de modernização de sistema legado. Jean Pierre Lessa e Santos Ferreira, CTO, comenta que a metáfora resume o essencial: o sistema novo nasce em volta do antigo, não no lugar dele.
Do outro lado está a reescrita completa, aquela em que a equipe constrói a versão nova em paralelo e vira a chave num fim de semana. As duas abordagens atacam o mesmo problema, custam caro e falham por motivos diferentes. A escolha entre elas costuma ser tratada como preferência técnica, quando, na prática, é uma decisão sobre quanto risco a operação aguenta concentrar em uma única data.
Onde a reescrita total costuma travar?
Um desconto especial concedido a três clientes antigos, uma exceção fiscal criada para um estado específico, um arredondamento que só aparece no fechamento do mês. Regras assim ficam espalhadas por um código que roda há dez ou quinze anos, sem documentação e sem ninguém que lembre por que foram escritas. A reescrita total descobre o que ficou de fora depois da virada, com a operação já dependendo do sistema novo.
Depois vem o problema do tempo sem entrega. Enquanto a versão nova é construída, o sistema antigo fica congelado: correções entram a conta-gotas, pedidos do negócio ficam na espera e falhas conhecidas seguem abertas porque a substituição está a caminho. Projetos longos sem resultado intermediário também são os primeiros a serem cortados quando o orçamento aperta.
Como a substituição por partes funciona na prática?
O mecanismo é uma camada de fachada colocada na frente do sistema antigo. Toda requisição passa por ela, que decide, função por função, se a resposta vem do legado ou do módulo já migrado. Justamente por isso, Jean Pierre Lessa e Santos Ferreira avalia a fachada como a peça central do desenho: sem ela, não existe convivência controlada entre as duas versões.
Nem sempre a ordem da migração segue a facilidade técnica. Os módulos entram na fila por valor de negócio e por risco, o que costuma significar começar pelo que mais trava a operação, e não pelo que dá menos trabalho. Cada módulo migrado recebe uma fração do tráfego real antes de assumir o total, o que transforma a virada em uma série de testes pequenos.
O ganho mais concreto é o prazo do primeiro resultado. Em vez de esperar anos pela versão completa, a empresa vê a primeira função rodando no ambiente novo em semanas, com o comportamento comparado ao do antigo enquanto os dois convivem. O legado só é desligado quando o tráfego naquele trecho chega a zero, nunca quando a migração parece pronta.
O preço de manter dois sistemas ligados ao mesmo tempo
Nada disso sai de graça. Durante a transição, a equipe mantém dois ambientes, duas rotinas de implantação e dois conjuntos de erro possível, além da própria fachada, que vira um ponto crítico de infraestrutura. Uma regra de roteamento mal configurada produz falhas intermitentes que parecem indisponibilidade do sistema novo e são apenas endereço errado.
Os dados são a parte mais delicada. Enquanto os dois sistemas operam, alguma estratégia precisa manter a informação consistente entre eles, seja gravando dos dois lados, seja replicando as mudanças a partir do banco antigo, cada opção com sua falha típica. Para o executivo, a comparação honesta entre as abordagens inclui esse custo, e não apenas o risco evitado na virada.
Quando reescrever do zero é a decisão certa?
Há casos em que a substituição incremental não compensa. Sistemas pequenos, com poucas regras e uso interno restrito, são reescritos em semanas, e montar fachada, sincronização de dados e monitoramento paralelo custaria mais do que o próprio projeto. O critério é o tamanho do estrago caso a virada dê errado.
Sistemas instalados na máquina do usuário e núcleos em ambiente de grande porte também complicam o modelo, porque a fachada depende de interceptar requisições. Nesses casos, o padrão continua aplicável, mas exige camadas adaptadoras construídas antes de qualquer migração de função. O que muda não é o princípio, e sim o preço de entrada.
Modernizar é escolher o que não será refeito
Entender o que o sistema atual faz é a parte difícil, e nenhuma das duas abordagens elimina esse trabalho. A diferença está em quando o entendimento aparece: na reescrita total, ele chega depois da virada, sob pressão; na substituição por partes, chega módulo a módulo, com o antigo ainda disponível para comparação.
Muito do que se chama legado, aliás, não precisa ser refeito. Trechos estáveis, que raramente mudam e cumprem bem a função, seguem onde estão por anos sem prejuízo algum. Modernizar um ambiente corporativo é, antes de tudo, separar o que dá trabalho de verdade daquilo que apenas parece velho, destaca Jean Pierre Lessa e Santos Ferreira.
