Como migro para o novo sistema sem parar o trabalho?

Você troca de sistema sem parar o trabalho se não desligar o antigo antes que o novo prove seu valor: rode os dois com as mesmas transações reais e compare os resultados, teste os casos raros que os responsáveis pelos processos apontam, exija aprovação humana de cada módulo antes de entrar em produção e mantenha o sistema antigo pronto para voltar a ele. No seu guia de execução da migração, a Microsoft recomenda monitorar o novo sistema nas primeiras 24 a 48 horas após a virada e manter o ambiente de origem como alternativa durante a estabilização.

Na parte 5 você escolheu um caminho para cada sistema. Esta parte não repete o método geral de virada que explicamos em Modernizar sistemas legados sem interrupção. Ela foca no que é novo: o que testar quando a IA escreveu ou converteu o novo código.

Por que o código convertido por IA precisa de testes diferentes

O código produzido por ferramentas de conversão parece organizado e funciona na primeira tentativa, e é exatamente isso que torna seus erros difíceis de ver. O erro não aparece nos casos do dia a dia; aparece no caso que acontece uma vez por mês ou uma vez por ano. A Amazon explica em seu guia de transformação de aplicações mainframe que a conversão inicial de COBOL para Java preserva o mesmo comportamento e que, depois, uma etapa chamada Reforge usa grandes modelos de linguagem para reestruturar o código no estilo moderno do Java. COBOL é uma linguagem de programação antiga que ainda roda muitos sistemas bancários e de mainframe; mainframe é o grande servidor central onde rodam os sistemas principais das grandes organizações.

Cada etapa que reescreve o código pode mudar algum detalhe. Por isso não basta um desenvolvedor ler o novo código e dizer que parece certo. A diretoria tem uma única pergunta: o novo sistema dá o mesmo resultado que o antigo com os mesmos dados? A resposta vem da comparação dos resultados, não da leitura do código.

Compare os resultados nas mesmas transações reais

Pegue um período fechado do seu negócio, como um mês com a contabilidade já encerrada, passe as transações dele pelo novo sistema e compare o que sai com o que o antigo produziu. O que comparar:

• Números finais: totais faturados, saldos e estoque no fim do período.
• Relatórios: os relatórios mensais em que a diretoria se apoia, linha por linha.
• O que vai para outros sistemas: os arquivos e mensagens enviados ao banco, à contabilidade ou aos portais do governo.
• Rejeições e erros: uma transação que o sistema antigo rejeita deve ser rejeitada pelo novo, pelo mesmo motivo.

Algumas ferramentas ajudam a preparar, não a julgar. O AWS Transform para mainframe, por exemplo, monta um plano de testes a partir dos atributos do código, da complexidade dos jobs e dos caminhos do agendador em 3 fases (configuração, definição de escopo e revisão), e depois gera scripts para coletar dados de teste do mainframe em 4 fases. Mas a Amazon avisa no mesmo guia que esses scripts precisam ser executados no seu próprio mainframe, com as permissões da sua equipe. A ferramenta prepara; sua equipe executa e decide. Para verificar os próprios dados, a Microsoft sugere comparar a contagem de linhas como verificação rápida e depois somas de verificação como checagem mais profunda: uma soma de verificação é um número calculado a partir dos dados que muda se um único caractere mudar.

Os casos raros: pergunte a quem os conhece

Um mês de transações reais não contém tudo. Os casos que quebram sistemas são conhecidos pelos responsáveis pelos processos, não pelos desenvolvedores: o fechamento do fim do exercício, uma devolução parcial de uma nota antiga, um cliente com preço especial, uma nota cancelada depois de lançada, o salário de alguém que entrou no meio do mês. Peça a cada responsável de processo a lista dos casos que o preocupam e transforme cada um em um teste com o resultado esperado escrito antes da execução.

Aqui voltam as regras que você confirmou na parte 4: cada regra confirmada vira pelo menos um caso de teste. Uma regra sem teste é uma regra que você não pode dizer que sobreviveu à conversão. Sobre os tipos de teste em si, veja nosso guia de testes de software e garantia de qualidade.

Aprovação humana para cada módulo

O exemplo publicado mais claro desse princípio é o fluxo de migração bancária que a Thought Machine anunciou com a Amazon em 29 de setembro de 2026. Ele tem 4 etapas: extrair a lógica de negócio das aplicações legadas com o AWS Transform, consolidar as variações redundantes em especificações unificadas, gerar os novos produtos financeiros e seus conjuntos de testes com agentes de IA, e uma etapa de validação que dá às equipes de engenharia e de risco do banco autoridade explícita de aprovação antes de aceitar qualquer coisa. Mesmo depois da aprovação, o resultado vai para um ambiente isolado de testes para avaliação adicional, não direto para produção.

A lição para sua empresa não exige nem banco nem Amazon: cada módulo do sistema, como faturamento, folha de pagamento ou estoque, recebe duas assinaturas antes de entrar em produção. Uma técnica, que confirma que todos os testes foram executados, e outra do responsável pelo processo, que confirma que os resultados estão certos em termos de negócio. A Microsoft pede o mesmo depois da virada: que os responsáveis pela aplicação confirmem que todas as funções principais funcionam corretamente.

Operação em paralelo e plano de reversão

Operar em paralelo significa que os dois sistemas funcionam lado a lado por um período definido, com o antigo ainda como referência oficial. Decida antes de começar quando esse período termina e que condição permite encerrá-lo, como os resultados baterem durante um ciclo completo do seu negócio. Depois organize a virada assim:

Um plano de reversão não é admissão de fracasso; é um seguro. Escreva antes o que faria você voltar atrás, como um erro nas notas ou a parada de um processo principal, quem decide e como os usuários retornam ao sistema antigo. Não desligue o sistema antigo de vez antes do fim do período de estabilização. O que costuma falhar nas primeiras semanas após uma troca está em Os primeiros trinta dias após a migração.

A visão da Origami

Tratamos a virada como uma decisão da diretoria, não como um evento técnico. Por isso construímos a comparação entre os dois sistemas antes de construir o novo sistema, e combinamos cedo com os responsáveis pelos processos os casos raros e os resultados esperados, para que a definição de sucesso esteja escrita antes que alguém veja os resultados.

Usamos IA para acelerar a conversão e gerar testes, mas a aprovação de cada módulo fica com pessoas nomeadas da sua equipe. Para ver como trabalhamos, conheça nossos serviços.

O exercício desta semana: uma ficha de virada por módulo

Para cada sistema que você decidiu converter ou reconstruir na parte 5, preencha esta ficha com os responsáveis pelos processos antes de marcar qualquer data de virada:

São exemplos ilustrativos; sua ficha será diferente. O importante é não marcar data de virada até que cada módulo tenha dois signatários nomeados e um gatilho de reversão por escrito.

O que vem a seguir

Resta uma pergunta que todo gestor faz antes de enviar código e dados a uma ferramenta de IA: para onde vão meus dados durante a modernização? A parte 7, a última, responde a ela e reúne os exercícios de toda a série em um plano de 90 dias.

Fontes

• Microsoft: Executar a migração, Cloud Adoption Framework — reunião sobre critérios de reversão, congelamento de mudanças, validação de dados, 24 a 48 horas de monitoramento e manutenção do ambiente de origem como alternativa.
• Amazon: Transformação de aplicações mainframe no AWS Transform — planos de teste, scripts de coleta de dados de teste e a etapa Reforge.
• Amazon: anúncio da Thought Machine e da AWS sobre migrações bancárias legadas — as quatro etapas e a aprovação das equipes de engenharia e de risco.
• AWS Transform: página oficial.