Pillar page
Modernização de sistemas legacy
Refactor incremental de monólito para microsserviços, migração de tecnologias obsoletas para stacks modernos, migração para cloud — sem downtime de negócio, com plano de rollback e audit trail completo.
Toda a empresa tem algum sistema legacy. Algumas têm vários. Uma aplicação de contabilidade de 2008 que ainda funciona de algum modo. Um CRM escrito por consultores de quem ninguém já se lembra. Um armazém em Access. Cada um deles terá de ser substituído algum dia — a questão não é se, mas quando e como.
A modernização de sistemas legacy é um dos tipos de projeto de TI mais difíceis. Exige equilibrar três forças: manutenção da continuidade de negócio (o sistema tem de continuar a funcionar a tempo inteiro), introdução de tecnologias modernas (microsserviços, cloud, IA) e controlo de risco (cada refactor pode partir algo que funcionou durante anos).
Porque não basta „reescrever do zero"?
Pela nossa experiência, 9 em cada 10 modernizações bem-sucedidas são refactor incremental, não rewrite. Os rewrites são concetualmente tentadores („começamos com uma página em branco"), mas na prática têm três problemas fundamentais:
- Lógica de negócio invisível. O sistema antigo contém anos de regras de negócio — condições especiais para os maiores clientes, isenções fiscais para setores específicos, contornos para regulamentos de 2015. A maior parte não está documentada. Um rewrite tem de a recriar a toda a partir da memória das pessoas ou da análise do código.
- Trabalho duplicado. Enquanto o novo sistema está a ser escrito, o negócio continua a exigir alterações no antigo (regulamentos, novos clientes, pequenos bugs). A equipa ou duplica o trabalho (alterações em dois sítios) ou congela o sistema antigo (risco de negócio).
- Big bang deployment. Após um ano de trabalho, o novo sistema está „quase pronto". Trocar todos os utilizadores numa única noite gera um risco monumental. Qualquer problema inesperado significa voltar ao sistema antigo, perder moral da equipa e erodir a confiança do negócio.
O refactor incremental (geralmente seguindo o padrão Strangler Fig) resolve as três questões: a lógica de negócio é descoberta gradualmente, uma única fonte de verdade para cada entidade, deployment em etapas com feature flags.
Seis padrões de modernização
Cada um deles aborda um risco específico. Na maioria dos projetos combinamos vários, escolhendo o padrão por módulo.
Strangler Fig
„Envolver" gradualmente o sistema antigo com novos componentes. O código antigo continua a correr, mas cada nova funcionalidade vai para um novo microsserviço e os módulos existentes são substituídos um a um. Após 12-24 meses, o monólito antigo é desligado.
Anti-corruption layer
Um adaptador que protege o código novo das esquisitices do sistema antigo (nomes de campos ilegíveis, formatos de data estranhos, tipos inconsistentes). Toda a lógica „feia" fica isolada num único sítio — o código novo opera sobre um modelo de domínio limpo.
Database refactoring
Padrões do livro Refactoring Databases (Ambler/Sadalage): expand-and-contract para migrações de esquema, validação de dados antes de eliminar colunas antigas, manutenção dos dois esquemas em paralelo durante a migração da aplicação.
Branch by abstraction
Introdução de uma camada de abstração à volta do componente antigo, implementação do novo em paralelo, troca gradual de 0% para 100% do tráfego (feature flag). Sem deploy „big bang".
Shadow mode
O código novo corre em paralelo com o antigo — ambos processam os mesmos pedidos, mas só os resultados do antigo chegam ao utilizador. Os resultados são comparados offline. Após confirmação de compatibilidade (tipicamente 2-4 semanas) trocamos o tráfego para o código novo.
Event sourcing para migração
Registamos o fluxo de eventos de negócio do sistema antigo e reproduzimo-lo no novo. Permite validação preliminar da nova arquitetura sem risco produtivo, bem como o regresso a qualquer estado histórico.
Roadmap típico de modernização
Para um sistema de média dimensão (monólito com ~200 mil linhas de código, 5-10 módulos de negócio):
- Mês 1: Discovery e documentação. Reverse engineering da arquitetura, mapeamento de dependências, identificação dos fluxos de dados, documentação dos processos de negócio com a ajuda dos stakeholders de negócio.
- Mês 2: Arquitetura alvo e piloto. Desenho da nova arquitetura, escolha de tecnologias, piloto no módulo mais simples (proof of concept). Primeira validação da abordagem.
- Meses 3-4: Extração do primeiro módulo produtivo. Padrão Strangler Fig, shadow mode durante 2-3 semanas, cutover de tráfego, hypercare. Primeiro valor real de negócio.
- Meses 5-12: Extração iterativa dos módulos seguintes. Cada um em ciclos de 4-6 semanas: refactor → testes → shadow → produção → hypercare. Melhoria contínua do processo, redução do tempo por módulo.
- Meses 12-18: Migração de dados e desativação do monólito. Quando todos os módulos críticos estão extraídos, finalizamos a migração de dados históricos, desligamos o sistema antigo, arquivamos. Celebrar.
Sistema antigo vs. modernizado
| Aspeto | Sistema legacy (típico) | Após modernização |
|---|---|---|
| Tempo de implementação de uma nova funcionalidade | 4-8 semanas (alto risco de regressão) | 3-7 dias (testes automatizados minimizam o risco) |
| Cobertura de testes | 5-15% (ou nenhuma) | >80%, no pipeline CI/CD |
| Disponibilidade de programadores | Baixa (tecnologia obsoleta) | Alta (stacks populares e modernos) |
| Segurança | Bibliotecas antigas com CVEs por corrigir | Análises OWASP, gitleaks, atualizações automatizadas |
| Escala | Vertical (mais recursos para o monólito) | Horizontal (escalar microsserviços específicos) |
| Observabilidade | Logs em ficheiros, sem métricas | Prometheus + Grafana + Sentry + SIEM |
| Conformidade (RGPD, EU AI Act, ISO 27001) | Exigente, cara de demonstrar | Incorporada na arquitetura, pronta para auditoria |
Seis riscos típicos — e como os endereçamos
Risco: ausência de testes no sistema legacy
Mitigação: Primeiro construímos testes de caracterização (capture tests) — registando o comportamento atual do sistema com base em logs de produção e capturas de tráfego. Só depois iniciamos o refactor, com os testes como rede de segurança.
Risco: conhecimento concentrado numa só pessoa („truck factor 1")
Mitigação: A transferência de conhecimento começa na primeira semana do projeto. Todas as reuniões com a pessoa que conhece o sistema são gravadas e transcritas, processos-chave documentados, decisões arquitetónicas fundamentadas. No fim do projeto, toda a equipa entende o sistema.
Risco: abrandamento temporário da equipa
Mitigação: Nos primeiros 2-3 meses a equipa mantém o sistema antigo + constrói o novo. Um abrandamento natural da velocidade de alterações. Mitigamos: prioridade para alterações que vão apenas para o sistema novo, freeze para alterações de baixa prioridade no código antigo.
Risco: migração de dados
Mitigação: Cada migração de dados tem três fases: dry-run (sobre uma cópia de produção), staging (em ambiente de teste com dados à escala real), produção (em janela de serviço ou de forma incremental). Plano de rollback pronto antes do arranque.
Risco: resistência organizacional
Mitigação: Comunicação com o negócio desde o primeiro dia: porquê modernizar, o que muda para o utilizador, qual o calendário, como medimos o sucesso. A primeira iteração é escolhida para mostrar rapidamente valor tangível (ex. um novo UI ou um relatório mais rápido).
Risco: subestimação de custo
Mitigação: Discovery (1-2 semanas) antes do orçamento do projeto. Iterações de 2-3 semanas com entregáveis concretos — mais fácil corrigir o rumo do que num projeto longo do tipo „tudo ao mesmo tempo". Orçamento com buffer de 20-30% para imprevistos.
Perguntas frequentes
O que é um sistema legacy?
Porquê modernizar se o sistema funciona?
Não é mais fácil reescrever tudo do zero?
A modernização exige downtime de negócio?
Quanto tempo demora uma modernização típica?
De que tecnologias migramos com mais frequência?
E as integrações existentes com outros sistemas?
Como reduzem o risco de negócio?
E a documentação do sistema, que não existe?
Quais são os custos de modernização em comparação com a manutenção do sistema antigo?
Comecemos por uma auditoria
Auditoria técnica de uma semana: mapeamento do estado atual, identificação das áreas de modernização mais urgentes, plano em fases com resultados de negócio concretos na primeira iteração.