Risco 1: perder as regras que ninguém escreveu
Todo sistema antigo faz coisas que ninguém pediu e das quais o negócio passou a depender: o arredondamento específico da nota, a exceção para um tipo de cliente, o job que roda no último dia do mês e corrige um saldo. Nada disso está em documento. Está no código, e às vezes só está no comportamento. O artigo sobre IA em sistemas legados mostra que é exatamente aqui que modelos de linguagem erram ao "traduzir" um sistema: eles reproduzem o que está escrito, não o que o negócio espera.
Mitigação: antes de tocar em qualquer coisa, extrair as regras do código para uma lista legível, com apoio de IA e revisão humana, e validar essa lista com quem opera o sistema. O sistema antigo é a especificação viva da versão nova. Quem pula essa etapa descobre as regras uma por uma, em produção, pelo telefone do cliente.
Risco 2: dados e equivalência funcional
Codificação de caracteres, datas gravadas como texto, decimais em centavos numa tabela e em reais em outra, registros órfãos, uma coluna reaproveitada há dez anos para outra finalidade. O módulo novo lê os mesmos dados e calcula um total diferente — e os dois lados têm certeza de que estão certos.
Mitigação: equivalência funcional antes de cada virada. Os mesmos dados de entrada passam pelo módulo antigo e pelo novo, e os resultados são comparados automaticamente, não a olho. A migração de dados é ensaiada em cópia, quantas vezes for preciso, e o financeiro recebe um relatório de conciliação antes de qualquer desligamento. Se os totais não batem, a virada não acontece.
Risco 3: integrações que ninguém documentou
NF-e e NFS-e, arquivo de remessa do banco, gateway de pagamento, feed do marketplace, aquela troca de arquivos por FTP com um fornecedor que acontece de madrugada. A integração que quebra é sempre a que não constava do levantamento. No caso Legate, o faturamento não podia parar um dia, e a camada de comunicação com a NFS-e nacional foi reconstruída com logs detalhados e tratamento de erros justamente porque a integração anterior não tinha nenhum dos dois.
Mitigação: inventariar conexões de entrada e saída a partir de logs, firewall e agendamentos, e não a partir da memória de alguém. E tratar o calendário regulatório como prazo fixo: a NT 2025.002, o IBS e a CBS na nota, a NFS-e nacional têm datas, e uma modernização que ignora esse calendário cria uma emergência no meio do projeto.
Risco 4: parar a operação e não ter volta
A virada em um fim de semana, tudo de uma vez, sem caminho de retorno. O deploy na sexta-feira. O certificado digital que vence no meio da janela de mudança. São os riscos mais visíveis e, curiosamente, os mais fáceis de evitar — porque dependem de método, não de sorte.
Mitigação: fases, convivência módulo a módulo e caminho de retorno pronto antes de cada virada, como descrito no artigo sobre manter ou modernizar. A migração do servidor Java dedicado para a nuvem seguiu esse roteiro: ambiente de testes, equivalência validada e virada controlada, sem reescrita. O antigo só é desligado depois de um ciclo completo — um fechamento de mês, uma competência fiscal — rodando no novo.
Risco 5: dependência de uma pessoa ou de um fornecedor, e estouro de escopo
Há um risco silencioso: trocar um ponto único de falha por outro. O sistema antigo dependia do desenvolvedor que saiu; o novo passa a depender do fornecedor que o construiu com um framework proprietário e não entregou documentação. E há o estouro de escopo clássico: "já que vamos mexer", o projeto de modernizar um módulo vira a reescrita do sistema inteiro, com prazo e custo de reescrita.
Mitigação: diagnóstico e roadmap por escrito, de propriedade do cliente; código e acessos com a empresa desde o primeiro dia; módulos contratados com escopo fechado; e a regra de ouro da JBKR, publicada na página do serviço: o relatório é seu mesmo que a próxima etapa seja feita por outra equipe. Fornecedor que resiste a isso está vendendo dependência.
A outra coluna: os riscos de não modernizar
Em 21 de outubro de 2026, a falha PHP2Shell deixou sem correção oficial todo sistema em PHP 8.1 ou anterior, e a CISA, agência de segurança do governo americano, orientou que esses sistemas fossem tirados do ar até serem corrigidos. Esse é o risco de esperar, materializado numa tarde: a decisão de modernizar deixou de ser da empresa. O artigo sobre a falha detalha o episódio; aqui ele serve de exemplo de que a coluna "deixar como está" também tem riscos, só que não agendáveis.
Os outros são conhecidos: a hospedagem que força a atualização na pior hora, a integração que acaba (a NFS-e municipal deu lugar à nacional), a única pessoa que conhece o sistema indo embora, o backup que nunca foi restaurado e falha no dia em que é preciso. As duas colunas têm risco. A diferença é que só uma delas pode ser planejada, faseada e testada.
Como reduzir o risco a um tamanho administrável e próximo passo
A regra é fazer o menor movimento que resolve o risco atual, e fazê-lo com método. Quase sempre isso significa começar pelo diagnóstico, não pela migração: duas semanas que produzem inventário, riscos por urgência, documentação e um roadmap com opções. O artigo sobre o que é modernização define os cinco caminhos; o artigo sobre estratégias de migração para a nuvem trata das escolhas específicas de nuvem; o artigo sobre manter ou modernizar traz as faixas de custo.
Na JBKR o diagnóstico inicial de 30 minutos é gratuito, e o relatório de duas semanas é, ele próprio, a principal mitigação de todos os riscos deste artigo: o que está escrito e testado não surpreende.
