“O sistema tem 12 anos, ninguém entende direito, e se cair a operação para.” Essa frase aparece em praticamente todo diagnóstico de empresa com mais de uma década de operação. O instinto é sempre o mesmo: “vamos reescrever do zero”. E é quase sempre o caminho errado.
Por Que Reescrever do Zero Falha
O relatório do Standish Group mostra que 75% dos projetos de reescrita total falham ou são abandonados. Os motivos são previsíveis:
- Subestimação de escopo — o sistema legado acumulou milhares de regras de negócio implícitas que ninguém documentou
- Segundo sistema — a tendência de fazer “tudo certo dessa vez” leva a over-engineering
- Dois sistemas para manter — durante a reescrita, o legado continua precisando de manutenção e evolução
- Prazo estourado — o que era “6 meses” vira 2 anos, e o negócio não pode esperar
Joel Spolsky chamou isso de “o pior erro estratégico que uma empresa de software pode cometer”. Décadas depois, o conselho continua válido.
A Alternativa: Strangler Fig Pattern
A abordagem que funciona é incremental. O nome vem de uma figueira que cresce ao redor de uma árvore existente, gradualmente substituindo-a sem derrubá-la.
Na prática:
- Identifique os módulos de maior impacto e risco no sistema legado
- Implemente o novo módulo lado a lado com o antigo
- Redirecione o tráfego gradualmente para o novo
- Monitore performance e comportamento em produção
- Desative o módulo antigo apenas quando o novo estiver validado
- Repita para o próximo módulo
Cada ciclo entrega valor real. Se o projeto for interrompido a qualquer momento, as partes já migradas continuam funcionando.
O Playbook em 4 Fases
Fase 1: Radiografia (2-4 semanas)
Antes de mexer em qualquer coisa, mapeie o que existe:
- Dependências entre módulos — o que quebra se você mudar X
- Hot spots — os 20% do código responsáveis por 80% dos incidentes
- Regras de negócio implícitas — aquele
if misterioso que ninguém sabe por que está ali
- Integrações — sistemas externos que dependem das APIs atuais
O resultado é um mapa de risco que guia a priorização.
Fase 2: Fundação (2-4 semanas)
Antes de migrar funcionalidade, crie a infraestrutura que vai suportar a evolução:
- Pipeline de CI/CD para o novo sistema
- Testes automatizados para o comportamento atual (testes de caracterização)
- Monitoramento e alertas em ambos os sistemas
- Feature flags para controlar o redirecionamento de tráfego
Essa fundação é o investimento que torna cada migração subsequente mais rápida e segura.
Fase 3: Migração Incremental (meses)
Com a fundação pronta, comece pelos módulos de maior valor e menor risco:
- Implemente o módulo no novo stack
- Valide com um percentual pequeno de tráfego (canary deployment)
- Escale gradualmente: 5% → 25% → 50% → 100%
- Compare métricas entre sistemas antigo e novo
- Documente decisões e aprendizados
Cada módulo migrado com sucesso gera confiança para o próximo.
Fase 4: Descomissionamento
Quando todos os módulos críticos foram migrados:
- Redirecione tráfego remanescente
- Mantenha o sistema antigo em modo read-only por 30-90 dias
- Archive dados e documentação
- Desligue servidores
Métricas de Sucesso
Como saber se a modernização está funcionando:
| Métrica |
Antes |
Meta |
| Tempo de deploy |
Dias/semanas |
Horas |
| Incidentes/mês |
Alto |
Redução progressiva |
| Time to market de features |
Semanas |
Dias |
| Cobertura de testes |
Baixa ou zero |
>70% em módulos migrados |
| Custo de infraestrutura |
Crescente |
Otimizado |
Erros Comuns a Evitar
Migrar tudo de uma vez. Mesmo incremental, a tentação de “acelerar” juntando vários módulos é real. Resista. Cada módulo migrado separadamente reduz risco exponencialmente.
Ignorar dados. A migração de dados é geralmente mais complexa que a migração de código. Planeje separadamente.
Não envolver o negócio. Modernização sem contexto de negócio resulta em recriar os mesmos problemas com tecnologia nova. O time de produto precisa participar da priorização.
Subestimar o legado. O sistema antigo funciona há anos por um motivo. Respeite o conhecimento acumulado nele — muitas regras de negócio só existem no código.
Quando o Time Interno Não Basta
Modernização de sistemas críticos exige uma combinação rara de skills:
- Engenheiros que saibam ler e entender código legado
- Arquitetos que consigam desenhar o caminho de migração
- Experiência em zero-downtime deployments
- Capacidade de transferir conhecimento para o time interno
Se o sistema é crítico para operação e o time interno não tem experiência em migração incremental, o risco de fazer sozinho pode ser maior do que o custo de buscar apoio especializado.
A melhor modernização é a que ninguém percebe. O negócio continua operando, os clientes não notam diferença, e um dia o sistema legado simplesmente não está mais lá.
