Migração de Sistema Legado sem Parar a Operação: Passo a Passo Completo

Todo gestor de TI conhece a cena: o sistema que roda a empresa há 10 ou 15 anos, que ninguém mais quer mexer, mas que também ninguém tem coragem de desligar. O medo é legítimo — parar a operação para trocar a base tecnológica parece um risco grande demais para justificar. A boa notícia é que a migração de sistema legado não precisa (e, na maioria dos casos, não deve) acontecer em um único evento.

Este guia explica o padrão mais usado do mundo para migrar sistemas críticos sem downtime, o passo a passo prático e os riscos que mais derrubam projetos de migração.

Por que a virada "big bang" costuma dar errado

A tentação é refazer o sistema inteiro em paralelo e, num fim de semana, desligar o antigo e ligar o novo. Parece limpo — na prática, é a estratégia com maior taxa de fracasso em migração de sistemas, por três motivos recorrentes:

1. Regras de negócio escondidas. Sistemas legados acumulam anos de exceções e ajustes não documentados — aquele desconto especial, aquela exceção fiscal — que uma reescrita do zero só descobre depois da virada, com a operação já rodando no novo sistema.
2. Meses (ou anos) sem entregar valor. Um projeto de reescrita total fica muito tempo sem gerar nenhum resultado visível, e projetos longos sem entrega intermediária costumam ser os primeiros cortados quando o orçamento aperta.
3. Rollback traumático. Se a virada falha, voltar atrás significa dados divergentes entre os dois sistemas, equipe em pânico e cliente esperando — o pior cenário possível para um sistema de missão crítica.

O padrão Strangler Fig: a alternativa que evita o big bang

O nome vem da figueira-estranguladora, planta que cresce ao redor de uma árvore existente até substituí-la por completo. Aplicado a sistemas, descrito originalmente por Martin Fowler, o padrão consiste em criar uma camada de fachada (um proxy) que intercepta as chamadas destinadas ao sistema legado e as redireciona — parte para o sistema antigo, parte para os novos serviços — permitindo migrar funcionalidades aos poucos, sem nunca desligar tudo de uma vez.

Passo a passo

1. Observe o monólito e identifique uma funcionalidade isolável. Escolha um recurso de negócio que possa ser migrado de forma independente, sem quebrar o resto do sistema.
2. Construa o equivalente no novo sistema. A nova versão é desenvolvida em paralelo, usando arquitetura e tecnologia atuais.
3. Redirecione o tráfego gradualmente. A camada de fachada passa a enviar uma fração do tráfego real para o novo serviço (canary release), permitindo validar cada mudança antes de expandir — mantendo o sistema legado como fallback.
4. Desative o módulo correspondente no legado. Quando a nova funcionalidade estiver estável e validada, o equivalente antigo é desligado com segurança.

Repita esse ciclo módulo a módulo até que o sistema legado possa ser desligado por completo. Para um monólito grande, a estrangulação completa costuma levar de 2 a 5 anos — mas, diferente da reescrita total, cada módulo migrado já entrega valor de negócio no caminho, não só no final.

Como sincronizar dados durante a transição

Enquanto sistema antigo e novo convivem, os dados precisam estar consistentes nos dois lados. Duas abordagens dominam o mercado:

• Dual-write: a aplicação escreve simultaneamente no banco antigo e no novo. Oferece consistência imediata, mas cria risco de falha parcial se uma das duas escritas falhar.
• CDC (Change Data Capture): captura as mudanças do banco legado e replica para o novo sistema sem alterar o código antigo. Evita mexer no legado, mas introduz um atraso de replicação que precisa ser monitorado.

Para sistemas de missão crítica, combinar CDC com verificadores de consistência automatizados costuma ser a opção mais robusta.

Quando o strangler fig completo não é viável: API wrapping

Nem todo projeto tem fôlego para uma migração de anos. Quando a substituição completa não é opção no curto prazo, encapsular o sistema legado com uma camada de APIs modernas (API wrapping) permite que aplicativos móveis, integrações e outros sistemas se conectem a ele de forma padronizada — sem tocar no núcleo antigo. É uma solução intermediária: não moderniza o sistema por dentro, mas destrava integrações que antes eram impossíveis.

Os 3 riscos que mais derrubam uma migração — e como mitigar

Perda de comportamento implícito. Monólitos acumulam anos de correções de bugs e tratamentos de exceção não documentados. Mitigação: discovery técnico completo antes de migrar qualquer módulo, com testes end-to-end que validem o comportamento atual — inclusive o que não está documentado.

Corrupção ou perda de dados na transição. Dados acumulados por anos costumam ter inconsistências e formatos heterogêneos. Mitigação: profiling completo dos dados antes da migração, com validação lote a lote, não só no final.

Resistência dos usuários finais. Quem usa o sistema há anos desenvolve dependência do jeito antigo de trabalhar. Mitigação: envolver as equipes que usam o sistema desde a fase de discovery — não só no treinamento final, quando já é tarde para incorporar o feedback delas.

Um exemplo real de migração sem parar a operação

Em um caso documentado publicamente pela consultoria Framework Digital, o sistema legado de uma operadora de saúde (Unimed-BH) não tinha documentação nem cobertura de testes — o cenário mais desafiador possível para qualquer migração. A abordagem usada foi validar o comportamento do sistema com testes end-to-end completos antes de qualquer corte de tráfego, mantendo operação paralela e um plano de rollback definido durante toda a transição — a mesma lógica de coexistência controlada descrita no padrão strangler fig.

Checklist antes de começar

• Mapeamento completo das funcionalidades do sistema legado, incluindo comportamento não documentado.
• Definição clara de qual módulo será migrado primeiro (o de menor risco, não o mais urgente).
• Estratégia de sincronização de dados definida (dual-write ou CDC) e testada em ambiente controlado.
• Plano de rollback documentado para cada etapa da migração.
• Envolvimento das equipes usuárias desde o início, não apenas no treinamento final.