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.

Quero modernizar meu sistema