Seu sistema legado funciona. Esse é o problema. Funciona bem o suficiente para ninguém querer mexer nele, mas mal o suficiente para cada funcionalidade nova levar três vezes mais tempo do que deveria. O código é um museu de decisões tomadas sob pressão por pessoas que já saíram da empresa há muito tempo. A documentação, se existe, descreve um sistema que não corresponde mais à realidade.
Você sabe que precisa modernizar. A questão é como — sem destruir o negócio no processo.
Nosso CTO passou anos na Avenue Code modernizando sistemas enterprise para grandes empresas brasileiras, incluindo o Banco Itaú e outras grandes instituições financeiras. Quando os sistemas centrais de um banco processam milhões de transações diariamente, você não pode se dar ao luxo de uma reescrita "big bang". Você precisa de abordagens cirúrgicas e incrementais que entregam valor continuamente enquanto reduzem o risco a cada passo.
Aqui estão cinco padrões de migração comprovados, quando usar cada um e as lições difíceis que aprendemos ao aplicá-los.
Por Que Reescritas Big Bang Falham
Antes de mergulhar nos padrões, vamos abordar o elefante na sala. A reescrita big bang — onde você congela o sistema antigo, reconstrói do zero e faz o cutover em uma única data — falha aproximadamente 70% das vezes (dados do Standish Group). As razões são previsíveis:
- O sistema antigo sabe mais do que você imagina. Anos de casos extremos, regras de negócio e integrações estão codificados naquele código legado. Sua reescrita vai perder muitos deles.
- O negócio não para. Enquanto você gasta 18 meses reescrevendo, o sistema antigo acumula novos requisitos que sua reescrita não inclui.
- O cutover é um precipício. Um único ponto de falha onde tudo precisa funcionar perfeitamente. Na prática, nunca funciona.
A alternativa é a migração incremental — substituir pedaços do sistema legado um de cada vez enquanto os sistemas antigo e novo coexistem. Todo padrão abaixo segue esse princípio.
Padrão 1: Strangler Fig (Figueira Estranguladora)
Nomeado em homenagem à trepadeira tropical que gradualmente envolve e substitui uma árvore hospedeira, o padrão Strangler Fig é a estratégia de migração mais amplamente aplicável.
Como funciona:
- Coloque uma camada de roteamento (API gateway, proxy reverso ou balanceador de carga) na frente do sistema legado.
- Para cada nova funcionalidade ou módulo, construa-a no sistema moderno.
- Roteie o tráfego dessa funcionalidade para o novo sistema. Todo o resto continua atingindo o sistema legado.
- Com o tempo, mais e mais tráfego é roteado para o novo sistema até que o sistema legado não processe mais nada e possa ser descomissionado.
Quando usar:
- O sistema legado expõe endpoints HTTP ou pode ter um proxy na frente
- Você consegue identificar limites funcionais claros (gestão de usuários, faturamento, relatórios)
- Você precisa entregar valor incrementalmente em vez de esperar por uma reescrita completa
Aplicação real: Na Avenue Code, nosso CTO aplicou esse padrão para modernizar uma aplicação bancária monolítica. A equipe colocou um API gateway na frente do sistema legado e reconstruiu módulos um de cada vez — começando pelos componentes de menor risco e maior valor. Relatórios voltados ao cliente foram migrados primeiro porque tinham os limites mais claros e a maior dor do usuário. Cada migração foi invisível para os usuários finais.
O padrão Strangler Fig é nossa recomendação padrão na Meld para a maioria dos projetos de modernização SaaS. É de baixo risco, entrega valor contínuo e a camada de roteamento oferece capacidade de rollback instantâneo.
Padrão 2: Branch by Abstraction
Quando o código legado está profundamente emaranhado — quando você não consegue rotear tráfego facilmente no nível HTTP porque o código antigo e o novo compartilham um processo — o Branch by Abstraction funciona onde o Strangler Fig não consegue.
Como funciona:
- Identifique o componente que deseja substituir.
- Crie uma camada de abstração (interface, adapter ou facade) ao redor da implementação existente.
- Atualize todos os chamadores para usar a abstração em vez da implementação concreta.
- Construa a nova implementação por trás da mesma abstração.
- Mude a abstração para apontar para a nova implementação.
- Remova a implementação antiga.
Quando usar:
- O código legado é um monolito onde componentes compartilham memória, bancos de dados ou espaço de processo
- Você não pode introduzir uma camada de roteamento entre componentes
- Você precisa migrar bibliotecas internas, camadas de acesso a dados ou módulos de lógica de negócio
O insight chave: A camada de abstração é o caminho de migração. Ela permite que implementações antiga e nova coexistam no mesmo codebase, rodem simultaneamente durante testes e troquem com zero downtime.
Esse padrão é particularmente poderoso ao modernizar arquiteturas orientadas a domínio onde contextos delimitados compartilham infraestrutura mas não deveriam compartilhar implementação.
Padrão 3: Execução Paralela (Parallel Run)
O padrão de Execução Paralela é para migrações de alto risco onde a correção é inegociável. Cálculos financeiros, compliance regulatório, sistemas médicos — qualquer coisa onde uma discrepância entre antigo e novo seria catastrófica.
Como funciona:
- Construa o novo sistema ao lado do antigo.
- Roteie todo o tráfego de produção para ambos os sistemas simultaneamente.
- O sistema antigo permanece como o sistema de registro — seus resultados são o que os usuários veem e o que é persistido.
- Compare as saídas de ambos os sistemas para cada requisição.
- Investigue e corrija cada discrepância.
- Uma vez que o novo sistema corresponda ao antigo com confiança suficiente (tipicamente 99,99%+ de concordância ao longo de semanas), faça o cutover.
Quando usar:
- Correção é mais importante que velocidade
- O custo de um bug no novo sistema é catastrófico (financeiro, segurança, regulatório)
- Você tem orçamento de infraestrutura para rodar dois sistemas simultaneamente
- Stakeholders precisam de prova matemática de que o novo sistema funciona
Aplicação real: Ao modernizar sistemas de processamento de transações bancárias na Avenue Code, execuções paralelas eram obrigatórias. Cada novo motor de cálculo rodava ao lado do motor legado por semanas, processando entradas idênticas. Relatórios de discrepância eram revisados diariamente. Somente após concordância sustentada — verificada por ferramentas de comparação automatizadas e auditorias manuais — a equipe fazia o cutover.
Esse é o padrão mais caro em termos de infraestrutura e tempo de engenharia. Mas para sistemas de missão crítica, é a única abordagem que fornece confiança suficiente. Já vimos aplicações com IA usarem esse padrão ao substituir sistemas baseados em regras por modelos de ML — rode ambos, compare saídas, construa confiança.
Padrão 4: Interceptação de Eventos
A Interceptação de Eventos funciona quando o sistema legado emite eventos (triggers de banco de dados, publicações em filas de mensagens, entradas de log, chamadas de webhook) que você pode interceptar e usar para alimentar o novo sistema.
Como funciona:
- Identifique os eventos que o sistema legado produz (mudanças no banco, mensagens, chamadas de API).
- Intercepte esses eventos usando Change Data Capture (CDC), taps em filas de mensagens ou triggers de banco de dados.
- Alimente os eventos no novo sistema, que constrói seu próprio estado a partir do fluxo de eventos.
- Gradualmente mude os consumidores do sistema legado para o novo sistema.
- Eventualmente, mude os produtores também — o novo sistema gera eventos diretamente em vez de interceptá-los.
Quando usar:
- O sistema legado escreve em um banco de dados ou fila de mensagens que você pode acessar
- Você quer construir uma arquitetura orientada a eventos como parte da modernização
- O código-fonte do sistema legado é difícil ou impossível de modificar
- Você precisa introduzir padrões CQRS ou event sourcing
O poder do CDC: Ferramentas como Debezium, Airbyte e replicação lógica do PostgreSQL tornam o Change Data Capture acessível. Você pode transmitir cada INSERT, UPDATE e DELETE do banco legado para um tópico Kafka ou barramento de eventos sem modificar uma única linha de código legado.
Esse padrão é especialmente eficaz quando o sistema legado é uma caixa-preta — software de fornecedor, sistemas COBOL antigos ou aplicações onde os desenvolvedores originais são inalcançáveis e o código não tem documentação.
Padrão 5: Migração Database-First
Às vezes o banco de dados é o gargalo, não o código da aplicação. O padrão Database-First moderniza a camada de dados antes de tocar na aplicação.
Como funciona:
- Analise o schema do banco legado — identifique problemas de normalização, índices faltantes, tabelas mortas e relacionamentos implícitos.
- Projete o schema alvo no novo banco de dados.
- Configure sincronização contínua de dados do antigo para o novo (usando CDC, ETL ou jobs de sincronização customizados).
- Gradualmente migre os componentes da aplicação para ler e escrever no novo banco de dados.
- Uma vez que todos os componentes usem o novo banco, descomissione o antigo.
Quando usar:
- O schema do banco é a principal fonte de dívida técnica
- Múltiplas aplicações compartilham o mesmo banco legado
- Você está migrando entre tecnologias de banco de dados (ex.: Oracle para PostgreSQL, MongoDB para PostgreSQL)
- A camada de aplicação está relativamente limpa, mas a camada de dados não
Considerações práticas:
- Sincronização bidirecional é difícil. Se possível, faça a migração unidirecional — o novo banco é o alvo de escrita, o banco legado recebe dados replicados para componentes ainda não migrados.
- O mapeamento de schema é onde o trabalho real acontece. Documente cada transformação. Teste com volumes de dados de produção, não com dados de amostra.
- Planeje o período de transição onde alguns componentes leem do antigo e outros do novo. É aqui que os bugs se escondem.
Quando aconselhamos startups sobre seleção de banco de dados, sempre discutimos o caminho de migração. Escolher um banco de dados não é só sobre hoje — é sobre como você vai evoluir a camada de dados ao longo dos próximos três a cinco anos.
Escolhendo o Padrão Certo
A maioria das migrações reais combina múltiplos padrões. Aqui está um guia de decisão:
| Situação | Padrão Principal | Padrão de Apoio |
|---|---|---|
| Aplicação web com limites claros de módulo | Strangler Fig | Branch by Abstraction |
| Monolito com código emaranhado | Branch by Abstraction | Strangler Fig |
| Sistema financeiro ou crítico para segurança | Execução Paralela | Interceptação de Eventos |
| Sistema legado caixa-preta que não pode ser modificado | Interceptação de Eventos | Database-First |
| Banco de dados é o principal gargalo | Database-First | Strangler Fig |
O Lado Humano da Migração
Padrões técnicos são a parte fácil. A parte difícil é organizacional.
Obtenha patrocínio executivo. Migrações que não têm apoio visível da liderança morrem quando a primeira pressão de prazo aparece e "só adiciona no sistema antigo" vira o caminho de menor resistência.
Comunique o progresso visualmente. Crie um dashboard mostrando qual porcentagem do tráfego ou módulos foram migrados. Nada motiva uma equipe como ver uma barra de progresso se movendo.
Celebre marcos. Quando o primeiro módulo migrar com sucesso, faça barulho sobre isso. Migração é um jogo longo e o moral importa.
Dimensione a equipe para manutenção dupla. Durante a transição, você está mantendo dois sistemas. Preveja orçamento para isso. O modo de falha mais comum é subestimar o custo de rodar antigo e novo em paralelo.
Como a IA Acelera Migração de Legado em 2026
Ferramentas de IA — combinadas com frameworks de migração maduros como os documentados pelo AWS Cloud Migration — transformaram o que é possível em projetos de migração. Ferramentas de análise de código conseguem mapear codebases legados em horas em vez de semanas. Geração de testes assistida por IA consegue criar suítes de regressão para sistemas sem documentação. E abordagens de desenvolvimento AI-native significam que o novo sistema pode ser construído em uma fração do tempo que o sistema legado levou.
Na Meld, usamos IA durante todo o processo de migração — analisando código legado, gerando scripts de migração, criando casos de teste e construindo a substituição moderna. A mesma metodologia AI-native que nos permitiu construir o sistema de 173 tabelas do AeroCopilot em 3,5 meses se aplica diretamente ao trabalho de migração. O novo sistema não é apenas moderno — é construído mais rápido do que qualquer um esperava.
Migração de sistemas legados nunca é glamourosa. Mas é um dos investimentos de maior ROI que uma empresa pode fazer. Os padrões acima dão um caminho a seguir que não exige apostar o negócio em uma única data de cutover.