Modernização de sistema legado: o caminho híbrido que 80% das empresas deveriam escolher

Existe um momento previsível na vida de todo sistema bem-sucedido: ele fica velho. O código que sustentou anos de crescimento agora é frágil, mal documentado e caro de evoluir. Alguém propõe a solução heroica — "vamos reescrever do zero, direito dessa vez" — e é aí que a maioria dos projetos de modernização começa a falhar.

Por que a reescrita big-bang quase sempre dá errado

A reescrita total parece limpa no papel: time novo, stack moderna, sem dívida técnica. Na prática, ela ignora três verdades incômodas.

Primeira: o sistema antigo contém anos de regras de negócio que ninguém documentou. Aquele if estranho no meio do código de faturamento existe porque um cliente grande exigiu algo em 2019. A reescrita descobre essas regras tarde — em produção, quando algo quebra.

Segunda: enquanto a equipe reescreve, o negócio para de evoluir. Por meses, nenhuma feature nova, porque os recursos estão no projeto paralelo. Os concorrentes não esperam.

Terceira: o cutover é um momento de risco máximo. Trocar o sistema inteiro de uma vez significa que, se algo der errado, tudo dá errado ao mesmo tempo. O rollback de uma reescrita total é, na prática, voltar meses no tempo.

O caminho híbrido: strangler fig

O padrão strangler fig — o nome vem da figueira que cresce ao redor de uma árvore hospedeira até substituí-la — propõe o oposto: modernizar incrementalmente, com o sistema antigo ainda rodando.

A mecânica é direta. Você coloca uma camada de roteamento na frente do sistema legado. No início, ela só repassa tudo para o antigo. Então você reescreve um pedaço — um módulo, um conjunto de endpoints — no sistema novo, e configura a camada para rotear apenas esse pedaço para o novo código. O resto continua atendido pelo legado, intocado.

A cada ciclo, você estrangula mais um pedaço do sistema antigo, validando em produção antes de avançar. Com o tempo, o legado encolhe até desaparecer. Em nenhum momento o negócio parou.

O que ganha quem faz assim

Valor a cada etapa, não só no fim. O primeiro módulo modernizado já entrega benefício — melhor performance, novas features, menos bugs — enquanto o resto segue funcionando. Risco controlado: se uma etapa der problema, você reverte só aquele pedaço, não o sistema inteiro. E as regras de negócio escondidas aparecem no diagnóstico de cada módulo, uma de cada vez, em vez de explodirem todas juntas no cutover.

Foi assim que modernizamos a autenticação multi-tenant de um varejo europeu com cerca de 2 mil unidades: migramos para Keycloak por etapas, com observabilidade ligada e rollback preparado em cada uma, sem nunca derrubar a operação.

Quando a reescrita total é justificável

Há exceções legítimas. Se a stack está obsoleta a ponto de não ter mais suporte de segurança, se o sistema é pequeno o suficiente para reescrever em semanas, ou se a arquitetura é tão acoplada que não dá para isolar módulos — aí o big-bang pode ser o caminho. Mas esses casos são minoria, e mesmo neles vale fazer o inventário de risco antes.

Por onde começar

Modernização honesta começa com um inventário de risco, não com escolha de stack. O que o sistema faz, de que depende, onde estão os pontos frágeis, quais regras estão escondidas. Em seguida, observabilidade para entender o comportamento real em produção. Só então se desenha a ordem de estrangulamento — qual módulo primeiro, qual depois, com critérios de validação a cada passo.

A pergunta certa não é "qual linguagem nova usar". É "qual é o menor pedaço que posso modernizar com segurança primeiro". Responda a essa, repita, e o sistema se moderniza sem que o negócio sinta o salto.