Resumo executivo: reescrever um sistema legado do zero é a decisão mais cara e mais frequentemente errada em modernização. Existem quatro estratégias, e a escolha entre elas depende de três perguntas objetivas — não do desconforto que o sistema antigo causa.
O que é, de fato, um sistema legado
Definição prática. Legado não é sistema velho. É sistema que a empresa depende para operar e tem dificuldade de mudar com segurança. Um sistema de 12 anos, documentado, testado e com fornecedor ativo não é legado. Um sistema de 4 anos que ninguém entende, é.
Os sinais. Ninguém sabe explicar uma regra sem abrir o código; mudanças simples levam semanas; a equipe tem medo de atualizar; existe uma pessoa (às vezes já aposentada) que é o único ponto de conhecimento; a tecnologia não recebe mais correção de segurança.
Por que virou pauta agora. Três pressões simultâneas: exigências de LGPD que sistemas antigos não atendem, necessidade de integração com serviços em nuvem e IA, e fim de suporte de plataformas — que transforma risco técnico em risco de conformidade.
As três perguntas que definem a estratégia
| Pergunta | Se a resposta for “sim” | Se a resposta for “não” |
|---|---|---|
| O processo que o sistema executa ainda é o certo? | Preserve a lógica; o problema é técnico | Reescrever pode fazer sentido — mas o projeto é de processo, não de software |
| O código é compreensível e alterável? | Refatorar e evoluir é o caminho barato | Encapsular ou substituir por partes |
| A plataforma ainda recebe correção de segurança? | Há tempo para planejar | Vire prioridade: é risco de conformidade, não só técnico |
As quatro estratégias
1. Manter e conter
O que é. Não mexer no sistema, mas reduzir o risco em volta: isolar a rede, tirar da internet, reforçar backup e monitoramento, documentar as regras conhecidas.
Quando faz sentido. Sistema estável, de baixo volume de mudança, com vida útil restante conhecida. É a estratégia mais subestimada — e às vezes a mais racional.
Custo. Baixo. Risco residual: alto se a plataforma estiver sem correção de segurança.
2. Refatorar por dentro
O que é. Manter o sistema, melhorar sua estrutura interna: separar camadas, adicionar testes, atualizar bibliotecas, extrair regras duplicadas — sem mudar o comportamento.
Quando faz sentido. Código compreensível, processo correto, equipe disponível. É a opção com melhor relação custo-benefício quando aplicável.
Cuidado. Refatoração sem teste automatizado é aposta. Antes de mexer, escreva testes que capturem o comportamento atual.
3. Encapsular e substituir por partes (estrangulamento)
O que é. Colocar uma camada de API na frente do sistema antigo e, a cada ciclo, mover uma funcionalidade para um serviço novo. O legado vai perdendo responsabilidades até poder ser desligado.
Quando faz sentido. Sistema crítico que não pode parar, código difícil, necessidade de evoluir rápido em partes específicas.
Por que costuma ser a melhor escolha. Entrega valor desde o primeiro ciclo, permite parar a qualquer momento com o ambiente funcionando e não exige acertar todo o entendimento do sistema antigo de uma vez.
Cuidado. Exige disciplina: sem regra clara sobre quem é dono de cada dado, você fica com dois sistemas discordando.
4. Reescrever do zero
O que é. Construir um sistema novo e migrar quando estiver pronto.
Quando faz sentido. Quando o processo mudou completamente, quando a tecnologia é inviável de manter e o sistema é pequeno, ou quando o custo de sustentar já supera o de reconstruir.
Por que falha tanto. Durante a reescrita, o sistema antigo continua evoluindo — e o novo persegue um alvo móvel. Além disso, regras não documentadas só aparecem quando alguém reclama que o novo sistema “faz diferente”. Esse conhecimento invisível é o verdadeiro escopo do projeto.
Se for reescrever. Congele o legado em manutenção mínima, migre por módulo e nunca faça virada única de tudo no mesmo dia.
Comparação objetiva
| Estratégia | Tempo até o primeiro valor | Risco de parada | Custo total | Quando escolher |
|---|---|---|---|---|
| Manter e conter | Imediato | Baixo | Baixo | Sistema estável com vida útil definida |
| Refatorar | Semanas | Médio | Médio | Código compreensível e processo correto |
| Encapsular por partes | Semanas | Baixo | Médio a alto | Sistema crítico que precisa evoluir |
| Reescrever | Meses a anos | Alto | Alto | Processo mudou ou plataforma inviável |
O passo que não pode ser pulado: arqueologia de regras
O problema. O sistema legado é a documentação do processo — a única que existe. Ali estão anos de exceções acumuladas, e boa parte delas ainda é necessária.
Objetivo → Ação → Resultado → Como validar
Objetivo: recuperar as regras antes de perdê-las.
Ação: combinar três fontes — leitura do código nos pontos críticos, entrevista com quem opera há mais tempo e análise dos dados reais em busca de padrões que só se explicam por regra escondida.
Resultado esperado: catálogo de regras com origem, motivo e status (ainda válida, obsoleta, incerta).
Como validar: submeter as regras marcadas como obsoletas a quem opera. As reações revelam rapidamente o que ainda é usado.
Efeito colateral valioso. Boa parte das regras encontradas está obsoleta. Descobrir isso reduz o escopo do sistema novo — às vezes de forma drástica.
Migração de dados: o item que atrasa projetos
- Decida o que migra. Quase nunca é tudo. Histórico antigo costuma ser melhor atendido por uma consulta de arquivo do que por migração completa.
- Meça a qualidade antes. Duplicidade, campo obrigatório vazio, formato inconsistente. Migrar dado ruim entrega um sistema novo com problema velho.
- Ensaie a migração várias vezes. A primeira execução sempre falha. A carga de produção deve ser a quinta ou sexta, não a primeira.
- Tenha critério de conferência. Totais por período, contagem por status, valores somados. Sem conferência automatizada, ninguém confia no sistema novo.
- Planeje o retorno. O que acontece se, no dia seguinte à virada, algo estiver errado? A resposta precisa existir antes.
Segurança e conformidade: o gatilho que costuma decidir
Plataforma sem correção é risco de conformidade. Sistema operacional, banco de dados ou linguagem fora de suporte significa vulnerabilidade conhecida sem correção disponível — situação difícil de justificar em auditoria e incompatível com a expectativa de medidas de segurança da Lei 13.709/2018.
Legado e LGPD. Sistemas antigos frequentemente não têm controle de acesso granular, não registram quem consultou o quê e não permitem eliminar dados de um titular. Esses três pontos são exigências práticas hoje, e costumam ser o argumento que aprova o projeto de modernização.
Enquanto a modernização não acontece. Contenha: retire da internet, restrinja acesso por VPN, segmente a rede, reforce backup com teste de restauração e monitore tentativas de acesso. Falamos disso em redes, servidores e segurança.
Como priorizar por onde começar
Nem todo módulo merece ser modernizado. Classifique cada parte do sistema em duas dimensões: quanto ela muda e quanto ela dói.
| Perfil do módulo | Estratégia recomendada |
|---|---|
| Muda muito e dói muito | Primeiro alvo do estrangulamento. É onde o retorno aparece rápido. |
| Muda muito e dói pouco | Refatorar e melhorar testes; o custo está na frequência de alteração. |
| Muda pouco e dói muito | Avaliar substituição pontual ou contenção reforçada. |
| Muda pouco e dói pouco | Manter e conter. Investir aqui é desperdício. |
O erro que essa matriz evita. Começar pelo módulo mais fácil tecnicamente, que costuma ser o que menos importa para o negócio. O primeiro ciclo precisa entregar alívio visível — é ele que garante orçamento para o segundo.
Perguntas frequentes
Quanto tempo leva modernizar? Depende da estratégia. Contenção é questão de semanas. Estrangulamento entrega valor em ciclos de semanas e leva meses a anos até desligar o legado. Reescrita completa raramente termina no prazo estimado inicialmente.
Dá para modernizar sem parar a operação? Com encapsulamento e substituição por partes, sim — é justamente para isso que a estratégia existe. Com reescrita e virada única, não: haverá janela de parada e risco concentrado.
E se o fornecedor original não existe mais? É o cenário mais comum em legado. O caminho é arqueologia de regras, contenção imediata do risco de segurança e estrangulamento a partir dos módulos que mais precisam mudar.
Vale a pena migrar para a nuvem primeiro? Migrar sem modernizar (“levantar e mover”) resolve infraestrutura e não resolve o legado — às vezes até encarece. Faz sentido quando o problema imediato é hardware ou continuidade, não quando é a dificuldade de mudar o sistema.
Riscos e pontos de atenção
- Subestimar o conhecimento não documentado. É o principal motivo de reescritas fracassadas.
- Virada única de tudo. Concentra todo o risco em um dia. Prefira virar por módulo ou por unidade de negócio.
- Congelar o legado tarde demais. Se o antigo continua ganhando funcionalidades durante a reescrita, o projeto não termina.
- Migrar dado sem limpar. O sistema novo herda o problema e perde credibilidade na primeira semana.
- Tratar como projeto de TI. Modernização mexe em processo e em rotina de pessoas. Sem patrocínio do negócio, trava.
Próximos passos práticos
- Liste os sistemas críticos e marque, para cada um, se a plataforma ainda recebe correção de segurança.
- Para os que não recebem, aplique contenção esta semana — é risco imediato.
- Meça quanto tempo a equipe gasta por mês contornando limitações de cada sistema. Esse número justifica o projeto.
- Escolha o módulo mais crítico e mais isolável para começar pelo estrangulamento.
Quer avaliar o legado da sua empresa? A Brazuca Informática faz consultoria, modernização e desenvolvimento de sistemas corporativos em MT, GO e em todo o Brasil. Fale com nosso time.
Premissas assumidas: as estratégias descritas são padrões consolidados de modernização de software; a escolha entre elas depende de fatores específicos de cada ambiente — criticidade, disponibilidade de conhecimento e restrição orçamentária; as observações sobre LGPD são gerais e não substituem análise jurídica do caso concreto.
Continue na série
- LGPD by design: segurança no ciclo de desenvolvimento de software
- Sustentação de software: o contrato que ninguém quer e todo mundo precisa
- Software sob medida ou de prateleira: como decidir sem se arrepender
- Desenvolvimento de sistemas corporativos — Brazuca Informática
Deixe um comentário