Onde o COBOL em produção ainda faz o trabalho real

O COBOL continua em produção onde uma organização passou décadas incorporando dinheiro, direitos e tratamento de exceções a um caminho operacional confiável. A linguagem aparece na biblioteca de fontes, mas o sistema também inclui JCL, agendadores, arquivos, bancos de dados, monitores de transações, procedimentos operacionais, relatórios de conciliação e acordos com todos os sistemas ao redor. Substituir apenas os programas significa substituir a parte menos difícil.

A frase conhecida «os bancos ainda usam COBOL» é correta e quase inútil. Ela esconde quais cargas ainda dependem dele e por que seus proprietários continuam pagando para mantê-las. O COBOL se concentra na liquidação em lote, na administração de apólices, nos livros contábeis centrais dos bancos e no cálculo de benefícios públicos. Esses sistemas permaneceram ativos porque continuaram produzindo resultados corretos sob condições ruins. Eles mudam quando o custo da mudança fica menor que o risco combinado da perda de pessoal, das limitações da plataforma, da lentidão para alterar produtos e de uma fronteira de interface que ninguém consegue ampliar com segurança.

O mapa da produção segue o dinheiro e os direitos

O COBOL ainda é usado onde um registro grande e duradouro precisa sobreviver a muitas transações e onde alguém terá de explicar o resultado depois. Quatro classes de carga respondem por grande parte dos ambientes de produção importantes.

A liquidação em lote pega a atividade aceita no dia, aplica tarifas e ajustes, equilibra totais de controle, contabiliza resultados e emite arquivos para as partes posteriores. A interface online pode usar uma linguagem mais nova enquanto o estado financeiro definitivo ainda vem de jobs COBOL agendados depois de um horário de corte.

A administração de apólices mantém o histórico contratual dos produtos de seguro. Ela calcula prêmios, aplica endossos, renova apólices, produz cobranças e documentos e registra qual cobertura existia em determinada data. Um portal web pode ficar na frente desse sistema sem substituí-lo.

Os livros contábeis centrais dos bancos lançam débitos e créditos, mantêm saldos, acumulam juros, aplicam regras de lançamento e fecham períodos contábeis. Aplicativos móveis e APIs de pagamento são canais. O livro contábil decide o que o banco considera que aconteceu.

O cálculo de benefícios públicos aplica leis e regras de programas a pedidos, históricos de rendimentos, dados familiares, datas de vigência, pagamentos indevidos e recursos. O material orçamentário da Social Security Administration, por exemplo, descreve o processamento de pedidos em sistemas COBOL legados e isolados. Isso é uma dependência operacional concreta, não nostalgia por uma linguagem antiga.

Essas categorias se sobrepõem. Uma plataforma de benefícios tem livros contábeis. Uma seguradora executa lotes de liquidação. Um banco administra produtos com datas de vigência parecidas com as de uma apólice. A distinção útil é a invariante de negócio: a liquidação precisa fechar, uma apólice precisa reproduzir a cobertura em uma data, um livro precisa preservar a verdade contábil e um sistema de benefícios precisa explicar uma decisão de direito.

A liquidação em lote é uma cadeia controlada

Um ambiente de liquidação é um grafo de dependências cronometrado cuja saída tem consequências financeiras. Uma noite típica só começa depois que os canais fecham suas janelas de entrada. Os jobs validam a contagem de arquivos, ordenam registros, enriquecem transações, calculam encargos, lançam resumos, comparam totais, criam arquivos de saída e encaminham exceções para a operação. Uma nova execução pode começar em um ponto de controle seguro, em vez de voltar ao início.

A documentação do z/OS da IBM chama o processamento em lote de função fundamental do z/OS e explica como o JES recebe jobs, agenda sua execução e controla a saída. Essa descrição corrige um erro comum de modernização: o executável COBOL não controla todo o fluxo. O JCL nomeia entradas e saídas, os procedimentos catalogados fornecem etapas compartilhadas, o agendador fornece calendários e dependências, e os operadores interpretam códigos de retorno e a saída de spool.

Um pequeno trecho de job mostra quanto comportamento fica fora do código-fonte da aplicação:

//SETTLE   JOB CLASS=A,MSGCLASS=X
//POST     EXEC PGM=POSTDAY,PARM='RESTART=CHK7'
//INTRANS  DD DSN=BANK.CLEARING.ACCEPTED,DISP=SHR
//OUTPOST  DD DSN=BANK.LEDGER.POSTED(+1),
//            DISP=(NEW,CATLG,DELETE)
//EXCEPT   DD DSN=BANK.SETTLE.EXCEPT(+1),
//            DISP=(NEW,CATLG,DELETE)
//SYSOUT   DD SYSOUT=*

A substituição precisa responder às perguntas expostas pelo trecho. O que cria a geração (+1)? Uma etapa com falha apaga a saída parcial? Quais códigos de retorno permitem executar o próximo job? O que CHK7 significa depois de um lançamento parcial? Quem decide se um arquivo de exceções está completo? Converter POSTDAY para outra linguagem sem recriar esses controles pode produzir código válido e um processo de liquidação inválido.

Os sistemas de liquidação permanecem porque foram ajustados para cumprir horários de corte, reiniciar e processar grandes volumes de entrada e saída. Eles finalmente mudam quando novos canais exigem lançamentos mais frequentes, contrapartes pedem outras fronteiras de arquivo ou API, as janelas em lote colidem com horários globais ou restam poucas pessoas que sabem recuperar uma cadeia com falha.

A administração de apólices preserva o tempo como dado

Um sistema de administração de apólices precisa responder «o que era verdade naquela época?» e «o que é verdade agora?». Datas de vigência e transação, endossos retroativos, cancelamentos, restabelecimentos, renovações, regras de jurisdição e versões do produto afetam a resposta. Esse modelo temporal explica por que uma simples migração de banco de dados raramente substitui o sistema.

Considere um endosso inserido hoje, mas vigente antes da última fatura. Talvez o sistema precise recalcular o prêmio de parte do prazo, preservar documentos já emitidos, gerar uma nova conta a receber e deixar uma trilha de auditoria que explique a diferença. Um serviço ingênuo que guarda apenas o estado mais recente da apólice destrói evidências. Uma substituição fiel trata eventos, períodos de vigência, valores derivados e documentos emitidos como assuntos separados.

O COBOL combina com esse trabalho porque registros empresariais fixos, aritmética decimal, processamento sequencial e desvios explícitos combinam com o domínio. O ambiente ao redor costuma adicionar copybooks compartilhados por muitos programas, tabelas mantidas fora do código, modelos de documentos, módulos de tarifação e jobs noturnos de faturamento. Algumas regras aparecem duas vezes porque a cotação online e o faturamento da renovação evoluíram separadamente. As duas lógicas podem divergir apenas em uma versão rara do produto, exatamente quando uma reescrita limpa pode mudar um resultado válido para o cliente.

Os proprietários não desligaram esses sistemas só porque navegadores e servidores de aplicações mudaram. Eles acrescentaram portais, ferramentas de fluxo de trabalho e APIs ao redor. Isso era racional enquanto os produtos permaneciam estáveis e o núcleo produzia resultados defensáveis. A decisão muda quando lançar ou alterar um produto exige edições em programas antigos, cada versão depende de um grupo de revisores cada vez menor ou um componente de documentos ou integração sem suporte bloqueia todo o caminho.

A substituição deve provar o comportamento temporal com casos datados. Teste uma apólice nova, um endosso no meio do prazo, uma correção retroativa, um cancelamento seguido de restabelecimento e uma renovação que atravesse a fronteira de uma versão do produto. Compare dinheiro, estado, períodos de cobertura, documentos, lançamentos e explicações. Fazer a linha atual de uma tabela de apólices coincidir não basta.

Os livros centrais sobrevivem porque erros se acumulam

Um livro contábil central ainda roda em COBOL porque alterar o mecanismo de lançamentos pode mudar as contas da instituição. O trabalho inclui muito mais que somar e subtrair saldos. Ordem dos lançamentos, datas de valor, bloqueios, estornos, apropriação de juros, cobrança de tarifas, precisão cambial, contas transitórias e controles de fechamento interagem.

O setor costuma confundir um livro contábil com um serviço de saldo. Um serviço de saldo responde rapidamente a uma consulta. Um livro registra lançamentos ordenados e duradouros e permite reconstruí-los. Se uma migração copiar os saldos atuais, mas perder o histórico de lançamentos ou as relações de estorno, os números podem coincidir na manhã da troca e se tornar impossíveis de explicar depois da primeira contestação.

O processamento de transações online costuma rodar por CICS. A documentação do Enterprise COBOL da IBM explica que programas que usam serviços CICS compilam instruções CICS incorporadas pela interface de comandos CICS. Esse detalhe aponta outra fronteira que a reescrita deve descobrir: o escopo da transação pode depender de recursos CICS, trabalho no Db2, arquivos, filas e tratamento de erros, e não apenas de instruções COBOL.

A substituição de um livro contábil falha de maneiras reconhecíveis. Uma equipe mapeia linhas de contas para novas tabelas, reimplementa lançamentos do caminho feliz e comprova um conjunto de testes unitários. Durante a execução paralela, chega um estorno antigo depois que a transação relacionada atravessou uma fronteira de data contábil. O sistema novo aplica a regra atual e o antigo aplica a versão associada ao lançamento original. As duas execuções parecem razoáveis. Apenas uma coincide com os livros reconhecidos pela instituição.

A resposta não é manter todos os defeitos históricos da implementação. A equipe precisa classificar o comportamento. Invariantes contábeis e resultados contratuais exigem paridade. Uma formatação de tela acidental talvez não. Uma regra suspeita precisa de uma decisão empresarial explícita, registrada antes que alguém a «corrija». Caso contrário, engenheiros tomam decisões de política durante a revisão de código, onde ninguém enxerga a consequência financeira.

O cálculo de benefícios combina lei e histórico operacional

Os sistemas públicos de benefícios mantêm COBOL porque as regras executáveis ficam sobre longos históricos de requerentes e procedimentos administrativos. Um cálculo pode depender de períodos de rendimento, composição familiar, condição de deficiência, decisões anteriores, interações entre programas, datas de vigência, regras de arredondamento, limites, compensações e correções posteriores. Um recurso pode obrigar o órgão a reproduzir uma decisão usando os fatos e regras aplicáveis na época.

A lei não é a especificação executável. Regulamentos, manuais de políticas, atualizações de tabelas, calendários de lotes, regras de limpeza de dados e procedimentos de exceção fecham a distância entre o texto legal e um pagamento. Dois registros que parecem equivalentes para um serviço novo podem seguir caminhos diferentes porque um indicador antigo registra como o órgão resolveu uma divergência anterior.

Programas de modernização enfrentam problemas quando tratam campos estranhos como obsoletos antes de rastrear seu uso. Um código de um caractere pode escolher uma ramificação de cálculo, suprimir um aviso, enviar um caso para revisão manual ou preservar uma decisão anterior. Removê-lo pode alterar o pagamento de uma pessoa sem causar erro de software. O programa roda, a API retorna sucesso e o defeito só aparece quando um requerente ou servidor contesta o resultado.

Uma substituição de benefícios precisa, portanto, de evidências no nível da decisão. Para cada caso registrado, capture entradas normalizadas, versão da regra, cálculos intermediários, valor final, período de vigência, avisos, códigos de motivo e encaminhamento para revisão manual. Oculte ou tokenize dados pessoais antes que saiam de sua fronteira permitida. Em um ambiente regulado, a infraestrutura de testes e os modelos talvez precisem rodar dentro do mesmo perímetro dos dados de origem.

A pressão pela substituição cresce quando mudanças legais demoram demais, interfaces antigas impedem órgãos de unir registros com segurança, funcionários não conseguem mais explicar certos caminhos ou as opções de aquisição da plataforma diminuem. O escrutínio público torna uma reescrita apressada especialmente perigosa. Mudar mais rápido importa, mas reproduzir decisões importa mais.

Esses sistemas ficaram porque o risco era assimétrico

Manter um ambiente COBOL funcional foi muitas vezes a escolha financeiramente sensata. A desvantagem de esperar se acumulava lentamente em manutenção, entregas mais lentas e exposição de pessoal. A desvantagem de uma substituição defeituosa chegava de uma vez como saldos incorretos, liquidações com falha, cobertura errada ou pagamentos mal calculados.

Várias condições reforçaram essa assimetria. Os recursos de transação e lote do mainframe já cuidavam de agendamento, controle de acesso, recuperação e grande volume de entrada e saída. Atualizações de hardware e compilador estendiam a vida da plataforma sem forçar a reescrita da aplicação. Formatos de arquivo estáveis permitiam integrar canais mais novos na borda. Acima de tudo, a empresa tinha evidências de produção de que o caminho antigo funcionava, incluindo décadas de exceções que nenhum documento de requisitos capturava.

A alegação popular de que o COBOL persistiu porque a direção tinha medo de mudanças é superficial demais. Gestores financiaram muitas mudanças ao redor desses núcleos. Substituíram terminais por interfaces web, introduziram intermediários de mensagens, expuseram serviços e moveram relatórios. Evitaram substituir o centro com estado porque o caso de negócio não compensava o risco.

Outra recomendação popular é traduzir cada parágrafo COBOL em código equivalente de uma linguagem mais nova. Ela parece atraente porque produz uma taxa de conversão mensurável e mantém o comportamento perto da origem. Como estado final, está errada. Uma tradução de parágrafo para função preserva estado global, fronteiras em forma de arquivo, suposições de lote e décadas de compromissos estruturais. A organização passa a ter um projeto de mainframe em uma sintaxe pouco conhecida, muitas vezes com ferramentas operacionais piores.

Uma decisão sensata separa três perguntas. A plataforma atual é confiável o bastante para o próximo horizonte de planejamento? A organização consegue mudar regras de negócio na velocidade necessária? Ela ainda consegue recuperar e explicar falhas sem depender de uma ou duas pessoas? Um «sim» à primeira não cancela um «não» a qualquer uma das outras.

A longevidade também cria uma falsa confiança na documentação. Os manuais operacionais costumam descrever o cronograma normal e o último procedimento de recuperação que alguém se deu ao trabalho de escrever. Eles não registram necessariamente por que um total de controle exclui uma fonte, por que um arquivo deve chegar antes de outro ou por que um operador aceita um código de retorno diferente de zero, mas para no seguinte. Essas decisões sobrevivem como hábito. Uma migração as descobre quando a execução paralela diverge, o que ocorre tarde e custa caro.

Trate o conhecimento operacional como lógica de produção. Observe um ciclo completo, incluindo corte, reinício, conciliação, entrada atrasada e reparo manual. Peça aos operadores que expliquem as evidências em que confiam e conecte essas evidências aos jobs e dados que as produziram. Se uma pessoa mantém uma planilha privada ou lista de comandos para fechar o dia, inclua isso no escopo mesmo que os diagramas de arquitetura não mostrem. A substituição precisa de um controle com suporte ou de uma decisão explícita de abandonar a prática.

Não confunda um sistema silencioso com um sistema simples. Núcleos maduros muitas vezes parecem tranquilos porque os operadores absorvem as irregularidades antes que elas cheguem à gestão de incidentes. Conte intervenções manuais, novas execuções, substituições, conciliações e chamadas para ex-integrantes da equipe. Esses sinais mostram se a estabilidade vem do software ou das pessoas que compensam suas falhas.

O evento que força a mudança costuma estar fora do compilador

O próprio COBOL raramente define o prazo. A decisão se torna inevitável quando uma restrição externa elimina a possibilidade de esperar. Um fornecedor encerra o suporte a um banco, camada de tela, agendador ou produto de integração. Uma fusão exige unir dois livros incompatíveis. Um produto novo precisa de comportamento intradiário de um núcleo noturno. Uma mudança regulatória exige rastreabilidade que o fluxo atual não consegue produzir com custo aceitável. Um mantenedor essencial sai e leva consigo o conhecimento de recuperação.

O custo da plataforma pode contribuir, mas uma comparação isolada de licenças sustenta mal uma migração. Substituições distribuídas têm seus próprios custos de computação, observabilidade, armazenamento, rede, segurança e pessoal. Se a proposta depender de uma infraestrutura implausivelmente barata, falhará quando chegarem o volume e a retenção da produção.

O risco de pessoal também exige precisão. «Programadores COBOL estão se aposentando» não diz a um CTO o que aprovar. Meça a responsabilidade no nível da função de negócio. Identifique quem explica o reinício do fim do mês, quem altera uma regra de prêmio, quem sabe por que um código de lançamento ignora uma fila e quem concilia uma execução de benefícios. O perigo é o conhecimento concentrado, não a idade média da comunidade de uma linguagem.

A pressão arquitetural se torna decisiva quando toda capacidade nova precisa passar por poucas fronteiras rígidas de arquivo ou transação. Equipes adicionam adaptadores, duplicam dados de referência e esperam a confirmação do lote. Com o tempo, o custo aparece como atraso no produto e ambiguidade operacional, em vez de aparecer na fatura do mainframe. Nesse ponto, a substituição ganha um responsável fora da infraestrutura: o executivo encarregado de lançar produtos, combinar operações ou cumprir uma data legal.

Use um memorando sobre o evento que força a mudança antes de aprovar o trabalho. Nomeie a restrição, a data ou condição que a torna obrigatória, os resultados empresariais afetados, o período aceitável de convivência e as evidências exigidas para a mudança. Se o memorando disser apenas «dívida técnica», o escopo vai se perder porque ninguém definiu a decisão que o projeto deve permitir.

O risco da migração vive entre os componentes

Uma reescrita confiável começa descobrindo o comportamento observável em todo o ambiente. A análise do código importa, mas o código sozinho não revela substituições do agendador, ações de operadores, formas reais dos dados, consumidores não documentados ou regras embutidas em tabelas. O inventário precisa ligar programas a jobs, conjuntos de dados, objetos de banco, filas, telas, relatórios e confirmações posteriores.

Comece pelos caminhos de produção, não pelas pastas do repositório. Para um resultado de negócio, siga o evento inicial até o lançamento ou aviso final. Registre cada componente, entrada, saída, efeito colateral, ponto de controle e ação de recuperação. Depois repita para as exceções: entrada duplicada, dados de referência ausentes, falha parcial do banco, chegada atrasada, reinício após criar a saída e correção manual.

Um registro de comportamento pode usar esta forma simples:

{
  "case_id": "settlement-late-file-restart",
  "inputs": ["accepted-transactions", "fee-table-v17"],
  "pre_state": "checkpoint-6-complete",
  "action": "restart-from-checkpoint-7",
  "outputs": ["posted-generation", "exception-generation"],
  "invariants": ["debits-equal-credits", "no-duplicate-posting"],
  "evidence": ["job-log", "control-report", "ledger-query"]
}

O registro é deliberadamente independente da implementação. Ele diz o que precisa continuar verdadeiro e de onde vem a prova. Crie registros a partir de variações reais de produção e acrescente casos de borda construídos para limites que o tráfego talvez não tenha exercitado durante a observação.

Execute os caminhos antigo e novo com a mesma entrada aceita e compare resultados normalizados. A normalização deve remover valores que podem diferir legitimamente, como identificadores gerados ou marcas de tempo, e preservar dinheiro, datas, estado, ordem quando relevante, códigos de motivo e efeitos colaterais. Guarde divergências como artefatos revisáveis. Um contador verde sem o diff real incentiva as equipes a dispensar diferenças sem explicação.

O tráfego gravado fornece evidências fortes, mas não é uma especificação completa. Ele comprova apenas os casos observados. Combine-o com ramificações derivadas do código, valores de copybooks, domínios de tabelas, entrevistas com operadores e procedimentos de conciliação. A distinção importa: testes de repetição medem compatibilidade com o uso observado, enquanto testes de regras cobrem comportamento válido que não ocorreu durante a captura.

Segurança e privacidade moldam o método. Registros de produção podem conter dados de conta, apólice, saúde ou identidade. Mantenha captura, tokenização, execução dos modelos e comparação dentro do ambiente permitido quando os dados não puderem sair. Preserve relações referenciais nos casos tokenizados, ou muitas regras entre registros não poderão ser testadas.

A representação dos dados merece uma superfície de testes própria. Copybooks podem descrever decimais compactados, campos com sinal, sobreposições, grupos repetidos e valores cujo significado depende de outro campo. Arquivos podem usar EBCDIC, tamanhos fixos de registro ou convenções locais para valores ausentes. Um analisador que remove espaços ou normaliza uma data inválida silenciosamente pode juntar estados que o sistema antigo mantinha separados. Gere casos de fronteira para cada forma declarada e compare valores lidos e registros rejeitados antes de testar as regras empresariais.

Copybooks compartilhados não garantem significado compartilhado. Um programa pode tratar um código como estado da conta e outro tratar os mesmos bytes como decisão de roteamento. Siga leituras e gravações, não apenas nomes. Quando os formatos mudaram ao longo do tempo, identifique quais produtores ainda podem enviar cada versão e como os consumidores as distinguem. Esse trabalho evita que um novo modelo canônico apague informações ainda necessárias a um arquivo atrasado ou a uma repetição histórica.

Conversão de dados e substituição da aplicação criam riscos diferentes. Converter um histórico prova que os registros chegam ao formato de destino. Não prova que o processamento de amanhã criará registros novos corretos. Teste saldos iniciais e conversão histórica separadamente do comportamento transacional e junte tudo em um ensaio que atravesse uma fronteira real de contabilidade ou faturamento. Concilie contagens, totais de controle, saldos, referências sem correspondência e cada rejeição. Um total correto pode esconder dois erros iguais e opostos, então examine também lançamentos e clientes.

Testes de desempenho precisam reproduzir a forma do trabalho, não apenas seu volume médio. Uma liquidação tem picos de chegada e um horário rígido de conclusão. Um livro online tem requisitos de latência e disputa em contas populares. Um recálculo de benefícios pode ler um histórico longo e gerar vários efeitos. Preserve ordem e conflitos de bloqueio nos dados de teste, meça o tempo de reinício após falha e inclua o consumo posterior. Um produtor rápido que sobrecarrega o próximo sistema não melhora o caminho de negócio.

Trate códigos de retorno e mensagens para operadores como interfaces até provar o contrário. Agendadores se desviam com base neles, equipes de suporte os pesquisam e procedimentos os usam para decidir se uma saída está completa. Mapeie cada condição antiga para um erro tipado, uma regra de nova tentativa, um alerta e uma ação de recuperação no destino. Torne explícita a idempotência: repetir após um timeout não pode lançar dinheiro, emitir documentos ou tratar exceções duas vezes.

O grupo de revisão deve incluir as pessoas que conciliam resultados, não apenas quem mantém o código. Operações financeiras explicam quais totais certificam a liquidação. Especialistas em apólices sabem quais documentos datados precisam continuar reproduzíveis. Servidores sabem quais códigos levam à revisão manual. Suas evidências transformam um diff técnico em decisão de mudança. Sem elas, uma equipe pode fechar milhares de diferenças e perder a única que altera uma obrigação.

Por fim, estabeleça uma política para comportamento desconhecido. Quando o caminho antigo produzir um resultado sem explicação, não o copie automaticamente nem o corrija em silêncio. Isole o caso, preserve entradas e evidências, atribua um responsável empresarial e registre o comportamento escolhido para o destino. Essa fila conterá defeitos, regras obsoletas e exceções legítimas. A velocidade com que ela se fecha mede a preparação melhor que a porcentagem de arquivos convertidos.

Substitua a fronteira e prove a mudança

O destino deve modernizar responsabilidade e interfaces, preservando os resultados exigidos. Defina serviços delimitados em torno de capacidades empresariais, escolha um modelo de dados duradouro e torne explícitas as responsabilidades em lote e online. Não deixe a estrutura antiga dos programas ditar cada módulo. Deixe o comportamento dela limitar todo resultado externo relevante até que a empresa aprove uma mudança.

Uma sequência prática tem cinco partes:

1. Congele um inventário de entradas de produção, jobs agendados, repositórios e consumidores para a parte empresarial escolhida.
2. Construa o mecanismo de paridade antes da substituição para que toda decisão de implementação receba as mesmas evidências.
3. Implemente a nova arquitetura atrás de adaptadores estáveis, incluindo reinício, conciliação e controles operacionais.
4. Execute casos históricos e tráfego de produção gravado pelos dois caminhos, classificando cada diferença.
5. Faça a mudança com critérios explícitos de reversão e mantenha a conciliação ativa até o fim da janela de risco acordada.

Escolha partes que terminem em um resultado empresarial verificável. «Converter 200 programas» não é uma parte. «Processar uma fonte de liquidação até o lançamento e a conciliação» é. A segunda expõe dependências e oferece aos executivos evidências que podem avaliar.

A CodeHero aplica essa abordagem lendo COBOL, JCL e o restante da árvore juntos, reescrevendo a arquitetura em Go, Rust, TypeScript e Postgres e conferindo o comportamento com um mecanismo de paridade diante do tráfego de produção gravado. Seus projetos são entregues em menos de 30 dias, incluindo execução isolada dentro do perímetro do cliente quando o ambiente exige.

A velocidade não elimina as responsabilidades do proprietário durante a mudança. A organização ainda decide quais comportamentos são contratuais, quais anomalias devem ser corrigidas, quais evidências satisfazem as equipes de risco e auditoria e quem pode autorizar a reversão. Não é seguro deduzir essas decisões do código-fonte.

Um sistema COBOL não deve mudar porque sua sintaxe parece antiga. Ele deve mudar quando a fronteira atual bloqueia o negócio e quando a substituição consegue mostrar, caso a caso, que dinheiro, direitos, histórico, recuperação e explicação continuam funcionando. Aprove a reescrita quando as duas condições forem verdadeiras.