Definição em um parágrafo
Modernização de sistemas legados é o conjunto de mudanças que mantém um sistema antigo útil, seguro e sustentável sem perder as regras de negócio que ele carrega: atualizar a plataforma, levar para um ambiente atual, reorganizar o código ou substituir módulos, na menor dose que resolve o risco. "Legado" não é insulto. É o sistema de que a empresa depende e em que ninguém quer mexer.
A parte da definição que mais importa é a última: na menor dose que resolve o risco. Modernizar é uma decisão sobre risco e custo, não sobre moda tecnológica. O objetivo é continuidade — o faturamento sair, o estoque bater, a nota ser aceita — e não a arquitetura mais recente.
O que é "legado" numa empresa brasileira
O inventário típico de uma PME brasileira: um ERP ou intranet em PHP 5 ou 7, um sistema em ASP clássico ou Visual Basic 6 que só roda num Windows específico, um faturamento de balcão em Delphi, uma aplicação Java antiga num servidor dedicado, um sistema .NET Framework preso a uma versão de Windows Server e, em bancos e seguradoras, rotinas COBOL. Todos funcionam. É exatamente por isso que ninguém mexeu.
O que torna um sistema legado não é a idade, é o suporte e o conhecimento. O PHP 8.2 chega ao fim da vida em 31 de dezembro de 2026, e a partir daí não recebe correção de segurança; o mesmo calendário existe para cada versão de Java e de .NET. E um sistema cuja documentação mora na cabeça de uma pessoa é legado no dia em que essa pessoa sai de férias. O caso Legate ilustra os dois lados: um faturamento em Delphi que funcionava bem, mas que a mudança para a NFS-e nacional obrigou a mexer — e que foi migrado sem um dia de emissão parada.
Os cinco caminhos, em uma linha cada
Manter no lugar: atualizar versão, corrigir, documentar, garantir backup e monitoramento, sem trocar a plataforma. Rehost: levar o sistema como está para a nuvem, ganhando backup automático e fim do risco de hardware. Replatform: trocar o servidor de aplicação, o banco de dados ou o runtime com ajustes pontuais no código. Refactor por partes: módulos novos convivem com o legado até substituí-lo, no padrão que Martin Fowler batizou de Strangler Fig. Reescrever em fases: só quando a plataforma inviabiliza a continuidade, e mesmo assim módulo a módulo.
A ordem é de custo e de risco, e a maioria dos casos de PME cai nos dois primeiros. O artigo sobre manter ou modernizar traz as faixas de custo de cada caminho e os cinco sinais de que é hora de agir; o artigo sobre estratégias de migração para a nuvem detalha o rehost e o replatform. Aqui basta saber que a escolha não é binária entre "deixar como está" e "reescrever".
O que modernização não é
Não é trocar o sistema por um ERP de mercado. Isso é um projeto de substituição, com migração de dados, treinamento e adaptação de processo, e as regras implícitas do sistema antigo não vêm junto. Pode ser a decisão certa, mas é outra decisão. Não é "reescrever com um botão": a tradução automática de código produz programas que compilam e se comportam diferente, e a diferença aparece no fechamento do mês. O artigo sobre IA em sistemas legados explica o que a IA faz bem nesse terreno — documentar, extrair regras, gerar testes — e o que ainda não faz.
Não é redesenhar as telas. Uma interface nova sobre um back-end em PHP 5 sem suporte é cosmética: o risco continua o mesmo, agora mais bonito. E não é, necessariamente, um projeto de nuvem. Rehost é um dos caminhos, não a definição; um servidor dedicado com backup testado e versão atualizada não é um problema a resolver.
Como saber se o seu precisa
Os cinco sinais clássicos estão no artigo sobre manter ou modernizar: versão sem suporte, dependência de uma pessoa, backup que ninguém restaurou, integração que começou a quebrar e custo de servidor fora da curva. Dois sinais merecem destaque próprio. O primeiro é o fornecedor ou a hospedagem anunciar uma data: o provedor que vai desligar o PHP 7, o Windows Server que sai de suporte. O segundo é uma mudança legal que o sistema não consegue absorver: a NFS-e nacional, a reforma tributária com IBS e CBS na nota.
E há o sinal que chega sem aviso. Em 21 de outubro de 2026, a falha PHP2Shell deixou sem correção oficial todo sistema em PHP 8.1 ou anterior. Quem tinha um plano de atualização agendado antecipou; quem não tinha descobriu, numa tarde, que a decisão de modernizar já havia sido tomada por terceiros. O artigo sobre a falha conta o que aconteceu e o que fazer.
Como a JBKR conduz: entender antes de mexer
O primeiro produto é sempre o diagnóstico de duas semanas: inventário do código, do banco e do ambiente; riscos classificados por urgência; documentação essencial gerada com apoio de IA e revisada por quem entende o sistema; e um roadmap por escrito com opções e estimativas. O relatório é do cliente, mesmo que a etapa seguinte seja feita por outra equipe.
Depois, qualquer mudança segue a mesma disciplina: ambiente de testes que replica a produção, equivalência funcional validada antes de cada virada e caminho de retorno pronto. A operação não para — no caso Legate, zero dias de faturamento parado. Na JBKR o diagnóstico inicial de 30 minutos é gratuito, e a pergunta que fazemos primeiro não é "qual tecnologia", mas "qual risco você quer tirar da mesa este ano".
