Resposta direta

Migração incremental é a substituição gradual de um sistema legado, módulo a módulo, enquanto a operação continua rodando. O padrão de referência é o strangler fig, descrito por Martin Fowler: um roteador intercepta as requisições e direciona cada funcionalidade para o sistema novo ou para o legado, até o antigo ser desligado. Reduz o risco da troca de uma vez, mas cobra um preço de governança que a maioria dos projetos descobre tarde demais: manter dois sistemas vivos em paralelo exige coordenação, sincronização de dados e disciplina de roteamento.

Por que o gestor de TI deveria se importar

Trocar um sistema crítico é uma das decisões mais caras que um gestor de TI assina. O legado trava a entrega, acumula dívida técnica e dificulta integração. A reação intuitiva é refazer tudo do zero. O problema: a substituição de uma vez, o chamado big-bang, falha com frequência. Especificar o comportamento exato do sistema antigo é difícil, parte desse comportamento não é nem desejada, e os usuários não param de pedir funcionalidade nova enquanto o time reescreve em silêncio por meses.

A migração incremental existe justamente para diluir esse risco no tempo. Em vez de uma virada arriscada, você entrega valor em pedaços, valida em produção e reverte rápido se algo quebra. É a abordagem que uma consultoria que já passou por essa transição recomenda, com uma ressalva honesta que os artigos genéricos omitem.

O que é o padrão strangler fig?

O nome vem da figueira-mata-pau, que cresce ao redor de uma árvore hospedeira até substituí-la. Em software, o padrão envolve o código antigo com uma camada de roteamento (um proxy ou fachada) que decide, requisição por requisição, o que vai para o sistema novo e o que continua no legado. No começo, quase tudo passa pelo legado. À medida que módulos são reescritos, o roteador manda cada vez mais tráfego para o novo. Quando o último pedaço migra, o legado é desligado.

A documentação de arquitetura da Microsoft descreve esse fluxo em fases: a fachada começa roteando a maior parte para o legado, a decomposição incremental desloca funcionalidade para o sistema novo, e ao final o legado é desativado sem dependências. A AWS recomenda começar por um componente com boa cobertura de testes e baixa dívida técnica, para dar confiança ao time logo nas primeiras migrações.

Por que o big-bang falha com mais frequência?

•     Especificação enganosa: parece fácil descrever o que o sistema antigo faz, até você precisar dos detalhes do comportamento real, que ninguém documentou.

•     Funcionalidade morta: boa parte do que o legado faz não é mais necessária. Reconstruir tudo é desperdício.

•     Janela cega: durante a reescrita, o negócio fica sem features novas por meses, e o usuário não espera.

•     Ponto único de virada: se a troca de uma vez dá errado, não há para onde voltar com facilidade.

Quais riscos a abordagem incremental remove, e quais ela cria?

O ganho é claro: continuidade de operação, reversão rápida por módulo, custo e retorno distribuídos no tempo, e a chance de aprender a cada passo antes de comprometer o orçamento inteiro. Agora o custo que ninguém avisa:

1.   Coexistência: durante a transição, dois sistemas rodam ao mesmo tempo. Ambos precisam acessar os mesmos dados, o que exige sincronização ou um repositório compartilhado bem desenhado.

2.   O roteador vira ponto crítico: a camada de proxy que intercepta tudo pode se tornar gargalo de performance ou ponto único de falha se mal arquitetada.

3.   Migração que nunca termina: sem pressão e sem disciplina, o projeto pode parar no meio, e você mantém legado e sistema novo para sempre, o pior dos dois mundos.

4.   Lógica vazando para a infraestrutura: quando há tradução entre o velho e o novo, ela tende a se acumular no roteador sem disciplina, prejudicando a confiabilidade.

É exatamente aqui que entra a experiência de uma consultoria: o strangler fig não é difícil de desenhar no quadro branco. O difícil é manter a governança de dados e o roteamento sob controle ao longo de meses de coexistência. Esse é o trabalho que separa uma migração que termina de uma que apodrece pela metade.

Como medir o ROI da modernização incremental

O retorno aparece de forma gradual e visível, não em um marco único. Em vez de justificar um orçamento gigante de uma vez, cada módulo migrado entrega valor que serve de evidência para liberar o próximo passo. Para o gestor de TI, três sinais valem o acompanhamento:

•     Redução de incidentes ligados ao legado conforme módulos saem de operação.

•     Tempo de entrega de novas funcionalidades nos módulos já modernizados, comparado ao que era no legado.

•     Custo de manutenção em paralelo, que deve cair à medida que o legado encolhe. Se não cair, a migração travou.

Quando o big-bang ainda é a escolha certa

A abordagem incremental não é universal. Para aplicações pequenas, em que o custo de refatorar tudo é baixo, reescrever de uma vez costuma ser mais eficiente do que montar toda a infraestrutura de roteamento e coexistência. O mesmo vale quando o sistema está em fim de vida iminente e não justifica investimento em uma transição longa, ou quando o domínio ainda não está claro o suficiente para definir as fronteiras dos módulos, situação em que decompor cedo demais pode sair caro.

Perguntas frequentes

O strangler fig serve para qualquer linguagem ou tecnologia?

Sim. O padrão é uma estratégia de migração, não uma tecnologia. Funciona em aplicações web, desktop e mobile, e independe da linguagem do legado. O que muda é a forma de interceptar as requisições, mais simples em sistemas web, mais artesanal em desktop e mainframe.

Migração incremental é o mesmo que microsserviços?

Não, mas costumam andar juntas. O strangler fig é frequentemente usado para migrar uma aplicação monolítica para uma arquitetura de microsserviços, extraindo funcionalidades aos poucos. Mas você pode usar o padrão para migrar de um monolito antigo para um monolito novo melhor estruturado, sem necessariamente fatiar em microsserviços.

Quanto tempo dura uma migração dessas?

Depende do tamanho e da complexidade do legado, e é justamente por isso que o risco de a migração nunca terminar é real. O ponto forte do método é permitir definir o ritmo conforme o orçamento e a prioridade do negócio, sem precisar tirar o sistema do ar.

Por onde começar a migração?

Pela funcionalidade de menor risco e maior valor: um módulo bem coberto por testes, com baixa dívida técnica e que muda com frequência. Começar por aí dá confiança ao time e mostra resultado cedo, antes de atacar as partes mais entrelaçadas do legado.

Próximo passo

A decisão entre modernizar de uma vez ou de forma incremental depende do tamanho do seu legado, da clareza do domínio e da sua tolerância a risco operacional. Receba um diagnóstico de legado com a CSP Tech e mapeie qual abordagem reduz mais risco no seu cenário antes de comprometer orçamento.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google e Anthropic.

Revisão técnica de arquitetura por especialista CSP Tech (Atlassian Gold + Microsoft Gold Partner, 34 anos de mercado).