Quando a liberação de pedidos depende de uma aplicação antiga, qualquer instabilidade deixa de ser um problema de TI. Ela vira atraso de faturamento, operação manual, desgaste com clientes e decisões tomadas sem informação confiável. É nesse ponto que um exemplo de modernização de sistema crítico ajuda a separar uma evolução planejada de uma troca tecnológica cara e arriscada.
O objetivo não é reescrever tudo porque a linguagem ficou antiga ou porque uma ferramenta nova parece mais atraente. É recuperar controle sobre um fluxo de negócio que não pode parar, reduzindo dependências e criando espaço para evoluir com previsibilidade.
Um exemplo de modernização de sistema crítico na prática
Considere uma distribuidora B2B com operação nacional. Seu sistema de crédito, estoque e faturamento foi construído ao longo de mais de uma década. Ele funciona, mas concentra regras que ninguém documentou por completo: limite de crédito, exceções comerciais, bloqueios fiscais, políticas de desconto e integrações com transportadoras.
O time percebe o problema quando o volume de pedidos cresce. Para evitar falhas, analistas passam a conferir pedidos manualmente antes da emissão de nota. Correções em uma regra simples levam semanas porque uma alteração no módulo de crédito pode afetar o faturamento. As integrações rodam em lote durante a madrugada, e erros só aparecem na manhã seguinte, quando a fila de pedidos já está represada.
A primeira reação comum seria aprovar a substituição integral do sistema. Nesse cenário, seria um erro. O legado contém regras que sustentam a operação, mesmo quando seu código é difícil de manter. Desligá-lo de uma vez transfere conhecimento implícito para um projeto de alto risco, normalmente com prazo e escopo pouco realistas.
A modernização começou por um diagnóstico do processo de pedido até a expedição. A equipe mapeou quais dados entravam no sistema, quais decisões eram automatizadas, quem intervinha manualmente e quais integrações causavam mais incidentes. O resultado mostrou que o maior gargalo não era o faturamento em si. Era a análise de crédito, centralizada em uma rotina monolítica e acionada por arquivos processados em horários fixos.
Com esse recorte, a empresa definiu um primeiro objetivo operacional: aprovar, bloquear ou encaminhar pedidos para revisão em tempo compatível com a operação comercial, sem alterar de início todo o ERP legado.
O problema real não era a tecnologia antiga
Linguagem, banco de dados e infraestrutura importam, mas são meios. Nesse caso, o risco estava na combinação de regras sem rastreabilidade, processamento em lote e dependência de poucas pessoas que conheciam o comportamento do sistema.
Essa distinção muda a conversa. Em vez de perguntar qual framework substituiria o legado, a liderança passou a perguntar quais decisões precisavam ser confiáveis, auditáveis e rápidas. A arquitetura foi desenhada a partir dessas respostas.
O diagnóstico antes da primeira linha de código
Modernizar um sistema crítico exige entender as fronteiras do problema. Nem todo módulo antigo precisa ser substituído, e nem todo serviço novo deve nascer separado. Criar microsserviços sem necessidade pode multiplicar pontos de falha, custos de observabilidade e complexidade de operação.
No exemplo, o diagnóstico identificou três blocos. O primeiro era o motor de decisão de crédito, que precisava ganhar autonomia. O segundo reunia dados mestres, como cadastro de clientes, condições comerciais e títulos em aberto. O terceiro era a emissão fiscal, fortemente acoplada ao ERP e sujeita a requisitos de conformidade.
A decisão foi preservar a emissão fiscal no ambiente legado no primeiro momento. Ela era estável, tinha dependências externas sensíveis e não era a causa principal dos atrasos. O motor de crédito, por outro lado, tornou-se o candidato natural para extração gradual.
Antes de desenvolver, a equipe registrou regras de negócio com usuários de crédito, financeiro e comercial. Também criou uma base de casos reais: pedidos aprovados, rejeitados e encaminhados para análise manual. Esse conjunto serviu para validar se o novo componente produziria a mesma decisão do sistema anterior antes de assumir a operação.
Critérios que orientaram a decisão
A arquitetura não foi definida por preferência técnica. Ela precisou atender a critérios claros: não interromper pedidos, permitir retorno ao fluxo anterior em caso de falha, registrar o motivo de cada decisão e reduzir o tempo entre o evento comercial e a resposta operacional.
Também foi definido o que não entraria na primeira fase. Uma nova tela comercial, modelos preditivos de risco e revisão completa do cadastro ficaram fora. Eram melhorias possíveis, mas adicionariam variáveis a uma mudança que já era relevante. Prioridade, em sistemas críticos, é uma forma de controle de risco.
A migração gradual protege a operação
Em vez de desligar o motor antigo, a empresa criou um serviço novo para análise de crédito e o colocou em funcionamento paralelo. Durante um período, os dois motores receberam os mesmos pedidos. O sistema novo calculava a decisão, mas o legado continuava sendo a fonte efetiva para aprovação.
Essa comparação revelou exceções não documentadas. Em determinados clientes, por exemplo, o limite de crédito era ajustado por acordos regionais que existiam apenas em uma tabela pouco conhecida. Em outros casos, pedidos com composição específica exigiam revisão humana mesmo dentro do limite aprovado.
Essas descobertas não significavam fracasso do projeto. Eram precisamente o conhecimento que uma reescrita total tenderia a descobrir tarde demais, já em produção. A execução paralela transformou comportamentos ocultos em regras verificáveis.
Quando a taxa de divergência caiu a um patamar aceitável para o negócio, o novo serviço passou a decidir primeiro para uma parcela controlada dos pedidos. O legado permaneceu como contingência. A ampliação ocorreu por região, perfil de cliente e tipo de pedido, com acompanhamento diário de erros, tempo de resposta e casos enviados para análise manual.
Esse padrão é mais lento do que uma troca anunciada para uma data única. Em compensação, preserva faturamento, reduz surpresa e permite corrigir o percurso sem transformar cada ajuste em incidente operacional.
O que mudou depois da primeira entrega
A primeira entrega não eliminou o legado. Ela retirou dele uma decisão crítica e criou uma interface clara entre crédito, comercial e faturamento. Pedidos passaram a ser avaliados próximos do momento em que eram criados, e os analistas receberam uma fila priorizada com o motivo do encaminhamento.
A empresa também ganhou rastreabilidade. Antes, uma aprovação ou bloqueio era difícil de explicar porque a lógica estava espalhada por procedimentos antigos. Depois da modernização, cada decisão passou a registrar dados usados, regra aplicada, horário e responsável quando havia intervenção humana.
Isso criou base para evoluções posteriores. Com dados consistentes, tornou-se possível revisar políticas de crédito, identificar padrões de exceção e avaliar o uso de IA para apoiar a triagem. Mas a IA entrou como hipótese de melhoria sobre um processo já medido, não como atalho para compensar regras confusas.
Onde projetos de modernização costumam falhar
O erro mais recorrente é tratar a modernização como compra de tecnologia. Uma plataforma nova não resolve regras contraditórias, dados duplicados ou um processo que depende de conferências informais. Se o diagnóstico não expõe essas questões, o problema apenas muda de endereço.
Outro erro é confundir velocidade com substituição completa. Há situações em que uma reescrita é necessária, especialmente quando o ambiente não atende requisitos de segurança, disponibilidade ou continuidade. Ainda assim, ela precisa ser sustentada por uma estratégia de transição. Sistemas críticos raramente permitem uma aposta única.
Também há o risco de extrair componentes pequenos demais. Se cada tabela e cada validação virarem um serviço independente, a operação ganha chamadas de rede, contratos difíceis de manter e mais cenários de falha. A divisão precisa respeitar responsabilidades de negócio e capacidade real de operar a arquitetura resultante.
Quando a abordagem deve ser diferente
Nem todo sistema merece modernização incremental. Se a aplicação está comprometida por falhas graves de segurança, depende de infraestrutura sem suporte ou não há como executar partes em paralelo, a empresa pode precisar de uma substituição mais direta. Mesmo nesses casos, o levantamento de regras, dados e integrações continua obrigatório.
O caminho também depende do nível de criticidade. Um sistema interno de apoio pode tolerar uma janela de indisponibilidade maior. Já uma aplicação que processa pagamentos, agenda entregas ou controla produção exige contingência, observabilidade e critérios objetivos para reversão.
A pergunta útil não é se o legado deve sobreviver. É qual parte dele ainda entrega valor, qual parte concentra risco e em que ordem a empresa consegue mudar sem interromper o que sustenta a receita.
Modernização como capacidade contínua
A modernização não termina quando um componente novo entra em produção. O ganho real aparece quando a empresa passa a tratar software como capacidade contínua de operação: medir gargalos, priorizar mudanças, evoluir arquitetura e manter decisões técnicas conectadas ao negócio.
Esse é o ponto do modelo Service as Software da Devio. A engenharia não começa pela encomenda de telas ou pela escolha de ferramentas. Começa pela arquitetura do problema, com uma sequência de entregas que reduz risco e gera efeito operacional mensurável.
Se um sistema crítico impede a empresa de crescer, a melhor primeira decisão não é definir a tecnologia de substituição. É tornar visível o fluxo que ele sustenta, os riscos que ele concentra e a menor mudança capaz de devolver controle à operação.