Blog · Sistemas legados
Como modernizar um sistema legado sem parar a operação
A pergunta que mais escutamos de quem tem um sistema antigo crítico não é "dá para modernizar?" — é "dá para modernizar sem parar a empresa?". Dá. Mas exige um jeito específico de conduzir o projeto, e este artigo é o playbook.
A regra de ouro: o sistema antigo continua no comando até prova em contrário
Modernização que respeita a operação parte de um princípio: o legado não é o inimigo — é quem está pagando as contas. Ele continua rodando, intocado no que funciona, enquanto o novo é construído ao lado. A troca acontece módulo a módulo, e cada troca só se confirma quando o novo provou que aguenta o dia a dia.
O playbook em 6 passos
1 · Congele o risco antes de mudar qualquer coisa
Antes da primeira linha nova: backup testado (restaurar de verdade, não só gerar o arquivo), ambiente de build reproduzível e o código-fonte versionado. Parece óbvio; na prática, é o passo que falta na maioria dos legados que assumimos.
2 · Estabeleça uma única fonte de verdade para os dados
A decisão mais importante do projeto inteiro. O caminho de menor risco: o banco de dados atual continua sendo o banco — o sistema novo lê e escreve nele (direto ou via API). Sincronizar dois bancos "por um tempo" parece flexível e é onde moram os piores bugs de migração: registros duplicados, atualizações perdidas, relatórios que não batem.
3 · Exponha o legado via API — sem mexer nele
Uma camada de API sobre o banco atual destrava tudo: o módulo novo, o app, as automações. O legado nem fica sabendo que ela existe. É a etapa que entrega valor primeiro — semanas, não meses.
4 · Migre pelo módulo que dói mais (estrangulamento)
Escolha o módulo pelo critério de dor × risco: o que mais trava o negócio, com o menor acoplamento possível. Reconstrua-o no sistema novo, sobre os mesmos dados. Os usuários daquele fluxo passam a usar a tela nova; todo o resto continua no antigo. Repita até o legado "encolher" e poder ser aposentado.
5 · Planeje a volta antes de cada ida
Toda troca de módulo precisa de plano de rollback: se o novo apresentar problema na segunda-feira de pico, como a operação volta para o antigo em minutos? Quando a resposta existe por escrito, a equipe troca sem medo — e paradoxalmente quase nunca precisa usar.
6 · Leve as pessoas junto
Quem opera o sistema há dez anos conhece exceções que nenhum levantamento captura. Envolva essas pessoas cedo: elas validam o módulo novo antes da virada e viram aliadas em vez de resistência. Treinamento por módulo (não um treinão no fim) mantém a rotina intacta.
Os erros que param operações
- Big bang — meses desenvolvendo às escuras para virar tudo num fim de semana. Concentra o risco inteiro num único evento. É o erro nº 1, e já escrevemos por que quase nunca é a resposta.
- Banco duplicado "temporário" — a sincronização vira projeto dentro do projeto e os dados divergem em silêncio.
- Congelar o legado — proibir correções no antigo durante a migração. A operação não espera; o legado precisa continuar recebendo manutenção até o fim.
- Ignorar relatórios e impressos — metade do valor de um sistema antigo está nos relatórios. Levante todos no início.
Quanto tempo a operação sente?
Bem conduzida, a resposta é: quase nada. As trocas acontecem por módulo, fora de pico, com rollback pronto. O que a equipe percebe é o lado bom — a tela lenta que ficou rápida, o retrabalho que sumiu — não a migração em si.
Resumo honesto
Modernizar sem parar a operação é método, não sorte: legado no comando até prova em contrário, uma única fonte de dados, API antes de telas, migração pelo módulo que dói mais, rollback por escrito e gente envolvida desde cedo. É exatamente assim que conduzimos modernização de sistemas legados na Decidi — inclusive em VB6, Windows Forms e ASP.NET.
Seu sistema é crítico demais para parar?
É o nosso cenário favorito. Conte a tecnologia e o que trava — devolvemos um plano de modernização por etapas, com a operação rodando.