Como uma migração de AS/400 move mais que um ERP

Chamar o AS/400 de ERP é um erro de categoria que leva as equipes a definir o projeto errado. Um ERP é um aplicativo. O IBM i é um ambiente operacional que pode hospedar pacotes comprados, aplicativos RPG personalizados, banco de dados, telas, filas, relatórios, regras de segurança e as rotinas que conectam tudo isso. Uma empresa pode substituir o pacote que reconhece e continuar presa à máquina.

Uma migração de AS/400 só funciona quando o substituto reproduz os resultados de negócio produzidos pelo ambiente atual, inclusive os caminhos estranhos que ninguém documentou. Mover tabelas e reescrever os programas visíveis cobre apenas uma parte do trabalho. A tarefa difícil é descobrir onde o comportamento reside, decidir qual comportamento deve sobreviver e provar que o novo sistema concorda com a produção antes que o antigo seja desligado.

A unidade de análise útil não é o nome de um aplicativo nem um membro de código-fonte. É uma transação de negócio e cada objeto tocado por ela. Acompanhe a liberação de um pedido, um bloqueio de crédito, um ajuste de estoque ou um lançamento de fechamento mensal por telas, programas, arquivos, filas, saídas impressas e intervenção de operadores. Esse caminho revela o que precisa migrar.

O nome AS/400 esconde um ambiente operacional

A máquina geralmente abriga uma rede de aplicativos e convenções operacionais, não um único bloco no formato de ERP. A IBM mudou o nome da plataforma várias vezes, e hoje o IBM i roda em hardware Power, mas muitas empresas ainda usam AS/400 como nome prático para tudo que existe atrás de uma tela verde. Esse atalho não causa problema até virar a fronteira da migração.

Comece pelo modelo de objetos. Programas, arquivos de banco de dados, arquivos de tela, arquivos de impressora, comandos, áreas de dados, filas de dados, filas de trabalhos, filas de saída, perfis de usuário e listas de autorização são objetos do sistema com tipos e permissões. As bibliotecas agrupam objetos, enquanto a lista de bibliotecas de um trabalho influencia qual objeto um nome não qualificado resolve em tempo de execução. Dois trabalhos podem chamar o mesmo nome de programa e chegar a objetos diferentes porque suas listas de bibliotecas são diferentes. Uma busca no repositório não mostra isso sozinha.

O software comprado complica o quadro. Um pacote de fornecedor pode controlar o núcleo contábil, enquanto código RPG personalizado executa precificação, alocação, verificações regulatórias, operações de depósito ou troca de arquivos. Programas CL podem preparar o ambiente, substituir arquivos, enviar trabalhos e chamar programas do fornecedor e programas próprios. Operadores podem executar comandos em menus numa ordem exata porque um caminho antigo de exceção nunca ganhou uma interface adequada. Nada disso passa a fazer parte do ERP só porque os usuários entram pelo mesmo menu.

A primeira fronteira deve separar plataforma, pacote, personalização e integração. Registre quem é responsável por cada componente, como ele é acionado e quais dados ou efeitos controla. Essa distinção muda as opções. É possível substituir um pacote, manter um banco temporariamente, reescrever fluxos personalizados e desativar um protocolo de transferência em cronogramas separados. Tratar todo o ambiente como um produto obriga uma decisão arriscada de uma só vez ou deixa dependências ocultas para o momento da virada.

Diagramas de arquitetura muitas vezes omitem objetos operacionais porque eles não parecem código-fonte. Isso é um erro. Uma descrição de trabalho pode escolher a lista de bibliotecas, a fila de saída, o nível de registro e a identidade do usuário para o trabalho enviado. Uma área de dados pode conter a data de processamento ou um valor sequencial. Uma fila de mensagens pode ser o único lugar em que um operador descobre que um lote parou. Se um processo de negócio precisa de um objeto, esse objeto faz parte do mapa do aplicativo.

O Db2 for i faz parte do comportamento do aplicativo

Uma exportação de banco de dados não captura a semântica do Db2 for i, pois os programas dependem de mais do que linhas e colunas. O Db2 for i é integrado ao IBM i. Aplicativos tradicionais costumam usar arquivos físicos e lógicos criados com DDS por meio de acesso nativo a registros, enquanto código mais novo ou revisado pode usar tabelas, visões, índices, procedimentos e gatilhos SQL. Os dois estilos podem coexistir na mesma transação.

A documentação Database files da IBM faz uma distinção precisa: um arquivo físico armazena dados do aplicativo, enquanto um arquivo lógico representa um ou mais arquivos físicos sem armazenar outra cópia dos registros. Do ponto de vista de SQL, um arquivo físico equivale a uma tabela. Um arquivo lógico pode equivaler a uma visão, a um índice ou aos dois. Esse último ponto importa. Um arquivo lógico pode definir um caminho de acesso por chave, selecionar ou omitir registros, reordenar campos, combinar arquivos físicos ou apresentar um formato de registro esperado pelo programa. Converter todo arquivo lógico em uma visão PostgreSQL pode remover uma propriedade de ordenação ou busca da qual o RPG nativo dependia. Converter todos em índices pode eliminar regras de seleção e projeção.

Os membros criam outra diferença. Um arquivo físico pode conter vários membros, cada um com um conjunto separado de registros no mesmo formato. Muitos sistemas usam apenas o membro padrão, mas alguns usam membros para períodos, filiais, importações ou conjuntos de trabalho. Uma exportação simples que lê apenas um membro perde dados sem avisar. O desenho de destino precisa decidir se um membro vira uma partição, uma coluna de inquilino ou período, uma tabela de preparação ou uma convenção obsoleta. Essa decisão exige evidência de uso, não um mapeamento genérico.

Os formatos de registro também carregam suposições sobre os dados. Decimais compactados, decimais zonados, campos de caracteres de tamanho fixo, espaços em branco, datas zero, sinalizadores codificados e campos descritos externamente se comportam de forma diferente de tipos SQL escolhidos casualmente. Um número de dez dígitos pode ser um identificador que nunca deve entrar em cálculos. Um espaço em branco pode significar desconhecido, enquanto zero significa explicitamente nenhum. Alguns arquivos não têm restrição no banco porque todos os programas RPG que escreviam neles aplicavam historicamente a regra. A migração precisa recuperar essa regra antes de adicionar uma restrição no destino, ou registros antigos válidos falharão durante a carga.

O uso de diários e o controle de compromisso precisam de inspeção separada. A documentação Commitment control da IBM diz que um grupo de alterações no banco pode ser confirmado ou desfeito como uma unidade e que os arquivos usados sob esse controle precisam ser registrados em diário. Alguns caminhos do aplicativo usam esses limites; outros fazem gravações nativas independentes e dependem de uma lógica de reinício. Colocar toda uma solicitação do substituto numa transação pode mudar a duração dos bloqueios e a recuperação de falhas. Não criar uma transação onde o trabalho antigo tinha uma pode expor atualizações parciais. Primeiro reproduza a unidade de trabalho observada, depois melhore-a de forma intencional.

Portanto, a descoberta do banco precisa incluir definições de arquivos, membros, caminhos de acesso, restrições, gatilhos, diários, contagens de registros, permissões e rastros reais de acesso. O esquema é apenas o começo.

O código RPG é só parte do grafo executável

Programas RPG revelam cálculos, mas o grafo executável também inclui descrições compiladas, convenções de chamada, preparação em CL, procedimentos vinculados, substituições e resolução de objetos durante a execução. Até um inventário limpo de código-fonte pode deixar de fora o código que a produção realmente executa.

A documentação de RPG da IBM distingue arquivos descritos pelo programa de arquivos descritos externamente. Num arquivo descrito externamente, o compilador busca as definições de campos e registros nas definições DDS ou SQL durante a compilação. Isso cria uma dependência fácil de ignorar: alterar o formato de um arquivo pode exigir recompilar programas dependentes mesmo quando seu código não mudou. As verificações de nível podem identificar um formato incompatível, mas desativá-las não torna os layouts compatíveis. Só remove um mecanismo de alerta.

RPG antigo pode usar o ciclo, indicadores, estruturas de dados, sub-rotinas, indicadores de exceção e operações nativas como CHAIN, SETLL, READE, WRITE, UPDATE e DELETE. RPG moderno pode usar sintaxe livre, procedimentos, programas de serviço e SQL incorporado. Nenhuma sintaxe revela a importância de negócio de um programa. Um invólucro CL de trinta linhas que configura uma lista de bibliotecas e substitui um arquivo de banco pode mudar o significado de um programa RPG de dez mil linhas.

A vinculação em tempo de execução merece um mapa próprio. Registre cada ligação de chamada observável, inclusive nomes dinâmicos de programas montados com dados, comandos de menu, programas de saída, gatilhos e chamadas remotas. Registre parâmetros por posição, tipo, tamanho e comportamento de alteração. Programas IBM i costumam passar parâmetros por referência, de modo que o programa chamado pode devolver um estado alterando um campo de entrada. Uma API substituta que modele apenas o valor de retorno visível pode descartar detalhes de erro ou o estado de continuação.

Substituições de arquivos causam defeitos de migração com frequência. Um comando OVRDBF pode redirecionar o nome de arquivo de um programa para outro arquivo ou membro sem editar o código RPG. Esse mecanismo atende dados de teste, empresas alternativas, membros de arquivo histórico e trabalho temporário. Se a descoberta ler apenas especificações F e instruções SQL, registrará o destino declarado em vez do objeto aberto durante a execução. Capture substituições no CL e nos trabalhos ativos e depois ligue-as às transações que as usam.

Faça o mesmo com listas de bibliotecas e permissões. Um programa pode rodar sob o perfil de quem o chamou, adotar a autoridade de seu proprietário ou depender de uma lista de autorização. O serviço de destino precisa de um modelo explícito de identidade e permissões. Copiar privilégios amplos do IBM i para uma única conta de banco pode fazer o primeiro teste passar, mas elimina a separação da qual a produção dependia silenciosamente.

Uma reescrita é segura quando cada ponto de entrada de produção tem um caminho rastreado por esse grafo. Traduzir o código sem o grafo produz código convincente que chama o objeto errado.

Arquivos de tela contêm decisões de negócio

Um arquivo de tela é comportamento executável de interface, não uma definição apenas visual. Arquivos de tela DDS definem formatos de registro, campos, constantes, teclas de função, subarquivos, atributos, palavras de validação e indicadores que controlam o que um usuário pode ver ou inserir. O RPG e o arquivo de tela dividem a responsabilidade pela interação. Migrar apenas a metade RPG muda o fluxo.

Considere uma tela de aprovação de pedidos. O RPG pode carregar o pedido e ativar o indicador 31 quando o cliente ultrapassa um limite de crédito. O arquivo de tela pode usar esse indicador para mostrar um aviso, proteger um campo de valor, colorir um status ou habilitar uma tecla de função. Outro indicador pode marcar uma entrada inválida e posicionar o cursor no campo com erro. O código RPG mostra o indicador mudando; o DDS explica o que essa mudança significa para o operador. Sem os dois, uma nova tela web pode permitir uma alteração que a antiga bloqueava.

Subarquivos acrescentam comportamento com estado. Um programa pode carregar uma página, manter um número relativo de registro, marcar linhas alteradas e processar apenas registros cujo campo de seleção mudou. Teclas de função podem ter significados diferentes conforme o formato do registro. Mensagens de erro podem vir de arquivos de mensagens em vez de textos literais. Arquivos de referência de campos podem fornecer tamanhos e regras de validação compartilhados por muitas telas. Uma captura de tela registra a aparência de um estado, não as regras que conectam estados.

As regras de DDS da IBM dizem que um indicador de opção ou nome de condição pode condicionar uma palavra-chave, um campo ou a posição de um campo. Essa pequena frase explica por que a conversão automática de telas costuma decepcionar. A lógica da interface está distribuída entre o estado do RPG e as condições DDS. Um analisador de telas precisa produzir um modelo de estados, não um formulário estático.

Percorra o caminho de falha, não apenas o caminho feliz. Informe um cliente encerrado, um depósito inválido, uma quantidade acima da disponível e uma tecla de função durante uma atualização parcialmente concluída. Registre a mensagem exibida, a posição do cursor, os campos protegidos, as leituras, gravações e bloqueios no banco e a tela seguinte. Depois repita com duas sessões alterando o mesmo registro. Os operadores muitas vezes dependem do comportamento exato de recuperação mesmo quando ninguém o chama de requisito.

O substituto não precisa imitar a tela verde pixel por pixel. Ele deve preservar decisões e controles e então expressá-los num desenho de cliente claro. Separe a validação de campos das regras de domínio. Mantenha os caminhos de teclado quando o rendimento depender deles. Troque indicadores enigmáticos por estados nomeados. Um formulário mais bonito que enfraquece o limite de aprovação é uma regressão.

Trabalhos em lote e saídas impressas são interfaces de produção

Telas interativas mostram apenas a parte diurna de muitos sistemas IBM i. Trabalhos em lote, filas, agendadores, arquivos de spool, transferências e mensagens de operador frequentemente executam liquidação, reposição, faturamento, relatórios e troca com parceiros depois que os usuários saem. Essas interfaces precisam da mesma disciplina de migração aplicada a uma API.

A documentação da IBM sobre gerenciamento de trabalho descreve como trabalhos enviados aguardam em filas e rodam em subsistemas com recursos e instruções de processamento atribuídos. Uma descrição de trabalho pode controlar o roteamento e a saída. Isso significa que o comportamento de um programa em lote depende do contexto de lançamento. Executar a mesma chamada de forma interativa num teste pode usar outra lista de bibliotecas, outro perfil de usuário, outra regra de mensagens, outra data ou outra fila de saída. O teste pode passar enquanto o trabalho agendado continua falhando.

Faça o inventário de cada agendador, trabalho enviado, subsistema, fila de trabalhos, descrição de trabalho, entrada de roteamento, fila de saída e fila de mensagens monitorada dentro do escopo de negócio. Inclua agendadores externos e scripts que se conectam por FTP, SFTP, protocolos de banco de dados ou interfaces de comando. Registre calendários, dependências, regras de repetição, limites de concorrência, intervalos esperados de duração e a pessoa ou sistema que reage a falhas. Não deduza um agendamento dos comentários no código. Observe-o.

Saídas de spool merecem atenção especial. Um arquivo de impressora pode codificar cabeçalhos, totais, comportamento de estouro, quebras de página, cópias e roteamento. A impressora física pode ter desaparecido enquanto outro processo ainda consome o spool como fonte de documentos ou arquivo. Pergunte quem recebe cada saída, o que faz com ela e o que comprova a entrega. Trocar um relatório por uma página web não é equivalente se um depósito espera um fluxo de etiquetas ou um banco espera um arquivo com registros fixos.

O comportamento de reinício dos lotes é outro contrato oculto. Um trabalho pode limpar um arquivo temporário, processar registros em ordem de chave, guardar um ponto de controle numa área de dados e enviar a si mesmo novamente após uma mensagem recuperável. Outro pode ser seguro para repetição porque verifica um indicador de contabilização. Se o substituto usa uma fila com entrega pelo menos uma vez, você precisa saber quais operações são idempotentes e quais exigem uma chave de negócio estável. Uma fatura duplicada não é detalhe de infraestrutura.

Trate o tempo como entrada. Datas de processamento, períodos fiscais, mudanças de horário, calendários de feriados e viradas de fim de dia podem vir de áreas de dados ou arquivos de controle, não do relógio do sistema. Um agendador em nuvem com a hora correta ainda pode produzir a data de negócio errada.

A descoberta precisa produzir um mapa de comportamento

Uma fase de descoberta útil produz um mapa consultável que conecta pontos de entrada, objetos, dados, efeitos e operadores. Uma planilha com nomes de programas e contagens de linhas não consegue responder se uma liberação de crédito aciona uma impressão, uma mensagem em fila e uma segunda atualização num programa chamado.

Comece com inventários do sistema e depois compare-os com o código e as evidências de execução. Os comandos IBM i abaixo criam dados em arquivos de saída que podem ser consultados em vez de copiados de telas do terminal:

DSPOBJD OBJ(APP/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/OBJECTS)
DSPPGMREF PGM(APP/*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/PGMREF)
DSPFD FILE(APP/*ALL) TYPE(*ATR) OUTPUT(*OUTFILE) FILEATR(*PF *LF) OUTFILE(AUDIT/FILEATTR)
DSPFFD FILE(APP/*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/FIELDS)

Esses comandos são um artefato inicial, não um scanner completo. Execute inventários equivalentes em todas as bibliotecas relevantes, preserve nomes qualificados de objetos e registre onde os comandos exigem seleções separadas. Adicione listas de membros de código, dados do catálogo SQL, agendas de trabalhos, configuração de filas, permissões, gatilhos, restrições, diários e caminhos do Integrated File System. Um arquivo de referências de programa informa referências estáticas conhecidas pelo objeto programa, mas chamadas dinâmicas e substituições em tempo de execução ainda precisam de rastros e análise de CL.

Para cada transação de negócio, armazene pelo menos o ponto de entrada, a identidade chamadora, a lista de bibliotecas, os programas e programas de serviço alcançados, os arquivos e membros abertos, os formatos de registro usados, as mensagens enviadas, os trabalhos submetidos, os arquivos de spool criados, os destinos externos chamados e o resultado final de negócio. Anexe confiança e evidência a cada ligação. Uma referência no código, uma descrição de objeto e um rastro de produção não têm o mesmo peso. Conflitos entre eles são descobertas, não ruído.

A análise de código morto precisa seguir evidências de execução. Datas de última alteração são sinais fracos em sistemas estáveis, e dados de última utilização podem estar ausentes ou ter sido reiniciados. Um programa sem alterações há quinze anos pode rodar toda noite. Por outro lado, um objeto compilado recentemente pode nunca receber uma chamada de produção. Coloque caminhos aparentemente mortos em quarentena, observe um ciclo de negócio representativo e peça a um responsável que aceite a desativação.

A pergunta incômoda é quanto de descoberta basta. Há o suficiente quando a equipe consegue escolher uma transação e prever suas leituras, gravações, saídas, sinais de falha, identidade e caminho de recuperação, e depois confirmar a previsão com evidências de produção. Ligações dinâmicas desconhecidas devem ficar explícitas e ser testadas. Um inventário grande com pontos de entrada sem explicação não está completo.

Paridade significa resultados e efeitos iguais

Os testes de paridade precisam comparar o comportamento de negócio observável, não apenas se funções traduzidas devolvem valores semelhantes. O contrato do sistema antigo inclui alterações no banco, ordem, mensagens, documentos, envio de trabalhos, chamadas externas, bloqueios e recuperação de falhas. Um teste que verifica apenas a linha final pode aprovar um substituto que enviou duas faturas.

Construa uma estrutura de testes em torno de transações de produção gravadas e saneadas. Capture o contexto de entrada necessário para repetir cada caso: usuário ou função, contexto de biblioteca ou empresa, data de negócio, registros iniciais relevantes, campos de tela ou solicitação e respostas dependentes. Execute os caminhos antigo e novo com dados isolados, normalize diferenças irrelevantes e compare o resultado completo. Mantenha o rastro original imutável para que uma massa de teste variável não faça os dois sistemas concordarem pelo motivo errado.

Um registro de comparação pode continuar simples:

{"case_id":"credit-release-017","result":"held","writes":[{"entity":"order","key":"48152","fields":{"status":"H"}}],"messages":["CREDIT LIMIT EXCEEDED"],"jobs_submitted":[],"documents":[]}

Os identificadores são ilustrativos, mas o formato obriga a equipe a comparar mais que um código de status. Acrescente leituras ordenadas quando a ordem de acesso afetar o resultado, datas e horas com tolerâncias declaradas e hashes para documentos grandes. Em relatórios gerados, compare campos interpretados e totais antes de se preocupar com igualdade de bytes. Em extratos financeiros ou formatos fixos de parceiros, a igualdade de bytes pode ser o contrato.

Inclua casos de limite e concorrência tirados de regras reais: espaços em branco contra zero, valores compactados máximos, envios duplicados, bloqueios de registro, falhas parciais, telas canceladas, reinício após o término de um trabalho e dois usuários editando a mesma entidade. Repita casos em que operadores escolheram uma tecla de função incomum ou corrigiram um campo após um erro. Esses caminhos revelam regras que as amostras do caminho feliz não capturam.

Não permita que a nova implementação defina o oráculo. Responsáveis pelo produto podem aprovar mudanças intencionais, mas cada diferença precisa de uma decisão identificada e um resultado esperado. Caso contrário, a modernização vira desculpa para um desvio semântico silencioso. O conjunto de paridade deve sobreviver à virada como conjunto de regressão para versões futuras.

O destino deve expor as regras sem copiar a máquina

Uma arquitetura de destino sensata preserva o comportamento enquanto transfere as regras para componentes que as pessoas conseguem entender e operar. Ela não recria bibliotecas, indicadores e substituições de arquivo com novos nomes. A transliteração mantém as dependências que dificultavam mudar o sistema antigo.

Organize o destino em torno de capacidades de negócio e limites de transação descobertos nas evidências. Serviços Go podem ser responsáveis por fluxos transacionais e APIs externas. Clientes TypeScript podem representar o estado da tela sem indicadores numéricos. O PostgreSQL pode impor restrições relacionais e oferecer esquemas, visões e índices explícitos. Rust faz sentido para núcleos numéricos quando medições ou requisitos do domínio justificam, não como substituto padrão para todo cálculo. Essas são decisões de projeto, não uma tabela mecânica de linguagens.

Mapeie cada elemento do IBM i pelo significado. Um arquivo físico pode virar tabela, mas o uso de vários membros precisa de um modelo intencional. Um arquivo lógico pode virar um índice junto com uma visão ou uma consulta dentro de um serviço. Uma fila de dados pode virar um tópico de mensagens, uma caixa de saída no banco ou uma chamada direta conforme seu contrato de entrega. Uma área de dados pode virar configuração, estado durável ou sequência. Uma condição de arquivo de tela pode virar uma regra no cliente ou uma verificação de autorização no servidor. Coloque decisões de segurança no servidor mesmo quando a tela antiga ajudava a aplicá-las.

Faça cortes em fronteiras que o mapa de comportamento possa verificar. Uma sequência comum move primeiro consultas somente de leitura, depois atualizações delimitadas e depois lotes e interfaces externas, enquanto uma camada de roteamento decide qual implementação atende a transação. A ordem correta depende do acoplamento e do risco operacional. Evite gravação dupla a menos que possa provar ordem, eliminação de duplicatas e recuperação. Captura de dados alterados ou um único gravador autorizado costuma ser mais fácil de explicar.

CodeHero lê toda a árvore de RPG e CL em conjunto, reescreve o sistema em Go, Rust, TypeScript e PostgreSQL e verifica o comportamento com uma estrutura de paridade baseada no tráfego de produção gravado. Essa abordagem só ajuda se o escopo de entrada incluir os arquivos, definições de tela e caminhos operacionais descritos aqui. Um agente não consegue preservar um objeto que ninguém coletou.

Mantenha as decisões de modernização separadas das decisões de paridade. Primeiro descreva o comportamento antigo com evidências. Depois aprove uma regra, um modelo de dados ou um fluxo de usuário modificado e codifique a nova expectativa. Essa separação permite que a engenharia explique cada diferença durante a revisão e a reverta sem adivinhar quais desvios foram acidentais.

O teste de saída pertence às operações

A migração termina quando a empresa consegue operar, recuperar, auditar e mudar o substituto sem depender do IBM i. Passar nos testes funcionais é necessário, mas os operadores são responsáveis pelo teste de saída porque lidam com as condições que as demonstrações evitam.

Prepare a virada como uma transição controlada de estado. Defina a última gravação autorizada no IBM i, a captura ou carga final, as consultas de conciliação, as regras para esvaziar filas, o tratamento de documentos, as mudanças de credenciais, as mudanças de rota e um ponto de decisão para retorno. Indique a pessoa que pode interromper a virada e as evidências que ela usará. Se o retorno exigir combinar gravações de dois sistemas, resolva esse desenho antes do evento em vez de escrever um procedimento otimista.

Concilie invariantes de negócio, não apenas contagens de tabelas. Pedidos por status, saldos em aberto, estoque por local, lotes não contabilizados, continuidade de sequências, mensagens pendentes e totais de documentos revelam falhas diferentes. Preserve os identificadores de origem para que a equipe possa rastrear um registro de destino até sua procedência. Arquive definições de código, inventários de objetos, listagens de compilação disponíveis, diários ou extratos exigidos pelas políticas e a evidência de paridade que apoia a aceitação.

Exercite a recuperação antes do desligamento. Mate um processo durante uma atualização com vários registros. Retenha uma resposta externa. Duplique uma mensagem. Encha uma fila. Restaure um backup do banco e repita o trabalho que falta. Confirme que os alertas chegam a uma pessoa com contexto suficiente para agir. O IBM i pode ter tornado alguns comportamentos de recuperação rotineiros por meio de diários, logs de trabalhos e filas. O substituto precisa deixar cada responsabilidade explícita.

A segurança precisa da mesma prova. Compare o acesso efetivo por função de negócio, incluindo autoridade adotada e identidades de trabalhos agendados. Remova credenciais temporárias de migração, permissões amplas de banco, contas de transferência e exceções de firewall. Em ambientes regulados, documente onde dados e modelos são executados, quem pode administrá-los e quais registros existem. Oferecer suporte a um ambiente controlado não cria uma certificação.

Por fim, deixe o sistema antigo disponível num estado definido somente de leitura ou recuperação apenas enquanto existir uma necessidade aprovada. Atribua um responsável, um custo, uma política de acesso e uma condição de destruição ou arquivamento. Um plano de retorno indefinido vira um segundo sistema de produção que ninguém testa. A linha de chegada honesta é o primeiro dia operacional comum em que um trabalho com falha, um total contestado e uma nova regra podem ser resolvidos sem chamar a última pessoa que se lembra do indicador 31.