Migração de RPG em formato fixo e a fronteira do livre

RPG em formato fixo e RPG em formato livre podem ser compilados na mesma partição IBM i, acessar os mesmos arquivos físicos e carregar o mesmo vocabulário de negócio. Ainda assim, são trabalhos de migração diferentes. Tratar a distinção como detalhe de formatação produz uma estimativa que parece organizada e falha assim que a equipe encontra indicadores, especificações de entrada ou um programa cujo fluxo de controle vive em parte no ciclo gerado pelo compilador.

Uma estimativa confiável começa perguntando onde o comportamento está codificado. Em um programa procedural de formato livre, boa parte dele aparece em instruções que um engenheiro moderno consegue acompanhar. No código antigo de formato fixo, colunas, ordem das especificações, indicadores de identificação de registro, quebras de nível e condições de saída podem carregar significado. A migração precisa recuperar esse significado antes que alguém possa precificar a reescrita de modo sensato.

As colunas fazem parte do programa

No RPG em formato fixo, a posição horizontal é sintaxe. Uma ferramenta de migração não pode normalizar espaços antes de entender o código-fonte. A referência ILE RPG da IBM diz que o tipo de especificação fica na posição 6 em fonte limitada por colunas: H para controle, F para arquivos, D para definições, I para entrada, C para cálculos, O para saída e P para procedimentos. Outros campos também ocupam posições prescritas. Um caractere deslocado para a coluna errada pode mudar uma operação, uma condição de indicador ou até se o compilador lê a linha.

Esse fato muda a ingestão. Um analisador precisa preservar a largura original do registro, os campos de sequência, as tabulações, o CCSID do membro-fonte e os limites dos membros copiados. Exportar um membro por um caminho que expanda tabulações ou corte espaços finais pode destruir evidências antes da análise. Trate o registro-fonte bruto como artefato e derive dele uma versão de exibição, nunca o contrário.

Uma verificação de entrada útil registra tanto a linha bruta quanto uma régua de colunas. Por exemplo, um relatório de inventário deve tornar visível a saída abaixo, mesmo que a extração real rode no IBM i:

member=ORDRPT line=184 bytes=80 spec=C cond_1=03 cond_2=N04 opcode=EXCPT
000001  C   03N04             EXCPT    ORDTOTAL
         1         2         3         4         5         6         7         8
12345678901234567890123456789012345678901234567890123456789012345678901234567890

O formato do relatório não é o ponto. 03, N04, EXCPT e ORDTOTAL precisam ser capturados como campos distintos, com as posições originais. Um analisador de texto genérico vê tokens. Um analisador que entende RPG vê um cálculo condicionado por um indicador ligado e outro desligado, seguido por uma operação de saída de exceção cuja definição pode estar muito mais abaixo no membro.

O RPG em formato livre remove grande parte dessa carga posicional. Em fonte totalmente livre, **FREE aparece na coluna 1 da primeira linha, e as instruções seguintes podem avançar além da antiga área limitada por colunas. Instruções como ctl-opt, dcl-f, dcl-s e dcl-proc expõem suas funções por palavra-chave e terminam com ponto e vírgula. Isso facilita a análise, mas não prova que o programa seja procedural nem que esteja livre de construções antigas. A sintaxe é a primeira classificação, não a última.

Os indicadores formam uma rede oculta de controle

Indicadores numerados comprimem estado, condições e efeitos colaterais em dois caracteres. Um cálculo fixo pode testar indicadores nas colunas de condição e definir indicadores de resultado alto, baixo ou igual em outras colunas. Especificações de entrada podem definir indicadores de identificação de registro, nível de controle e campo. Operações de arquivo podem definir indicadores de erro ou fim de arquivo. Especificações de saída podem usar esses estados para decidir se emitem um registro ou uma linha impressa.

Por isso, trocar *IN03 por um booleano chamado indicator03 é transliteração, não modernização. O nome preserva o local de armazenamento e perde a razão de ele existir. A migração precisa construir um grafo de definição e uso: todos os locais que podem definir o indicador, todas as operações condicionadas por ele, cada reinicialização e cada limite que ele atravessa ainda ativo. Só então a equipe pode decidir se ele significa customerChanged, writeTotals, recordFound, validationFailed ou várias coisas sem relação reutilizadas em momentos diferentes.

A reutilização de indicador é o caso incômodo que a contagem de linhas esconde. Um indicador pode significar uma coisa nos cálculos de detalhe, ser desligado e depois significar outra dentro de uma sub-rotina. Uma busca global relata dois grupos, mas não prova que sejam independentes. O analista precisa incluir ordem de chamada, fase do ciclo e efeitos das operações de arquivo. Se um valor atravessa um limite EXSR ou sobrevive até os cálculos de total, uma renomeação casual pode fundir estados que o original mantinha separados no tempo.

A IBM documenta *IN como uma matriz que cobre os indicadores numerados e alerta que valores diferentes de zero, um, *OFF ou *ON tornam imprevisíveis os testes posteriores. Esse detalhe importa durante a conversão porque alguns programas manipulam trechos da matriz de indicadores como dados. Um destino moderno não deve reproduzir uma matriz mágica de 99 booleanos, a menos que a compatibilidade exija isso em uma fronteira. Deve decodificar as escritas na matriz, nomear os estados pretendidos e fixar o comportamento ambíguo com testes antes de eliminar a representação antiga.

O artefato prático é um registro de indicadores, não uma contagem:

| Indicador | Definido por | Lido por | Fase do ciclo | Significado provável | Confiança | | | | | | | | | 03 | tipo de registro na I-spec | C-spec condicionada | detalhe | registro de pedido selecionado | alta | | 04 | resultado de CHAIN | condição EXCPT | detalhe | cliente ausente | média | | L1 | mudança no campo de controle | cálculos de total | total | quebra de conta | alta | | LR | fim do arquivo primário | totais e encerramento | último ciclo | finalização | alta |

Esse registro dá aos revisores algo que pode ser contestado. Também expõe onde a estimativa precisa de investigação. Dez indicadores bem nomeados e com uma finalidade podem custar menos que três cujo significado muda com a fase do ciclo.

O ciclo RPG controla um fluxo invisível

Um programa orientado pelo ciclo delega a sequência à lógica gerada pelo compilador. Portanto, ler as especificações de cálculo de cima para baixo não revela a ordem de execução. A documentação da IBM sobre programação em ciclo descreve uma sequência repetida que lê um registro, define indicadores de registro e de nível de controle, executa trabalho de total para uma quebra, produz a saída total, verifica a condição de último registro, move campos de entrada e então executa os cálculos de detalhe. A primeira e a última passagem têm comportamento próprio.

Essa ordem surpreende engenheiros que esperam um laço explícito. Os totais do grupo que acabou podem rodar depois que o próximo registro foi lido o bastante para estabelecer uma quebra de controle, mas antes que seus campos de entrada se tornem os dados de detalhe atuais. Saídas de cabeçalho ou detalhe também podem ocorrer em momentos definidos pelo ciclo. Uma reescrita que coloca read() no topo de um laço convencional e os totais no fim pode parecer sensata, legível e estar errada.

Arquivos primários e secundários acrescentam mais comportamento implícito. O programa talvez nunca emita a leitura que avança um arquivo primário porque o ciclo faz isso. Lógica de registros correspondentes, campos de controle, registros de entrada e especificações de saída cooperam por regras do compilador. O indicador LR pode surgir implicitamente após o último registro primário ou secundário, e a IBM observa que definir LR também liga os indicadores de nível de controle para o processamento final de totais. Isso é semântica de execução, não apenas uma marca antiga de término.

A conversão segura torna explícita a máquina de estados oculta antes de mudar sua arquitetura. Ela representa fases como inicialização, seleção de entrada, detecção de quebra de controle, totais do grupo anterior, processamento de detalhe e totais finais. Registra quais campos contêm o registro anterior, o recém-selecionado e os dados atuais de processamento em cada fase. Depois escreve o destino procedural com base nesse modelo.

Um rastreamento mínimo de comportamento pode ser assim:

seq=411 phase=read       account=170 record=invoice
seq=412 phase=break      level=L1 old_account=160 new_account=170
seq=413 phase=total      account=160 amount=9284.15 output=ACCT_TOTAL
seq=414 phase=detail     account=170 invoice=88412 amount=73.20
seq=415 phase=final      lr=on output=REPORT_TOTAL

Se o sistema antigo não consegue emitir um rastreamento com segurança, derive os eventos esperados das entradas gravadas e saídas observáveis. O teste essencial é a ordem. Totais finais iguais não bastam quando o destino escreve um registro posterior, atualiza um saldo ou chama outro programa na fase errada.

Formato livre não significa uma coisa só

O RPG em formato livre cobre vários estilos, e apenas alguns funcionam como código procedural comum. Um membro pode conter cálculos livres entre /FREE e /END-FREE, mantendo especificações F, I ou O fixas. Um membro mais recente pode usar declarações livres e ainda depender de um procedimento principal cíclico. Um módulo totalmente livre pode usar ctl-opt nomain, procedimentos, leituras explícitas, estruturas de dados qualificadas e protótipos. Chamar os três de “formato livre” destrói o sinal mais útil da estimativa.

A documentação da IBM estabelece os limites técnicos com clareza. Fonte totalmente livre usa **FREE na primeira linha; instruções fixas ainda necessárias, como antigas especificações de entrada ou saída, precisam ficar em um arquivo copiado. As regras de especificação do RPG IV também dizem que MAIN ou NOMAIN impede um procedimento principal cíclico, enquanto um módulo sem essas palavras-chave ainda pode ter um. Portanto, **FREE sozinho não responde se o ciclo existe.

Eu classifico os membros em eixos independentes:

• modo de fonte: fixo, misto limitado por colunas ou totalmente livre
• modelo de execução: principal cíclico, principal linear ou procedimentos MAIN/NOMAIN
• acesso a dados: arquivos controlados pelo ciclo, E/S nativa explícita, SQL incorporado ou mistura
• modelo de estado: indicadores numéricos, indicadores nomeados, variáveis explícitas ou mistura
• forma externa: chamadas de programas e áreas de dados, procedimentos de serviço, filas, arquivos ou comandos de job

Essa classificação evita um erro comum de estimativa. Dois membros totalmente livres podem ser radicalmente diferentes se um for um procedimento enxuto com SQL explícito e o outro trouxer antigas O-specs por /COPY, alternar indicadores numerados e terminar com *INLR. Por outro lado, um membro de formato fixo pode ser mecanicamente regular e bem coberto por regras repetíveis. O formato afeta a dificuldade, mas o comportamento a determina.

O nível de compilação também importa. A sintaxe de um membro-fonte mostra o que ele usa, não todas as restrições do compilador ou do ambiente de produção. Inventarie versões de destino, grupos de ativação, diretórios de ligação, arquivos descritos externamente, copybooks, programas de serviço e comandos de compilação. Um plano que ignora o grafo de build vai descobrir “código ausente” que na verdade era injetado ou resolvido na compilação.

A modernização começa por um modelo de comportamento

O destino deve expressar a intenção de negócio e manter compatibilidade em limites nomeados. Para um relatório cíclico, isso costuma significar um leitor que fornece registros tipados, um componente que detecta quebras de controle, um calculador para detalhes e totais e um adaptador de saída que reproduz os registros externos necessários. Para um programa interativo, pode significar separar estado de tela, validação, acesso a arquivo e invocação de comandos. A forma segue o comportamento, não as letras das especificações.

Não converta cada C-spec em uma instrução e cada indicador em um booleano para chamar o resultado de Go ou TypeScript. A abordagem é popular porque pode ser medida: cada linha de origem recebe uma linha de destino, relatórios automáticos de diferença parecem produtivos e revisores encontram rótulos conhecidos. Ela está errada porque preserva estrutura acidental e dificulta reconhecer regras implícitas de execução. O destino vira semântica antiga de RPG escrita em uma linguagem cujos mantenedores não conhecem RPG.

Uma boa representação intermediária mantém fatos que o projeto final descartará de propósito. Ela deve reter localização de origem, tipo de especificação, operação, fatores, resultado, indicadores de condição e resultado, referências de arquivo e formato de registro, arestas de sub-rotina, chamadas de procedimento, origem do membro copiado e fase do ciclo. Também deve distinguir uma aresta derivada pelo compilador de uma escrita no código. Sem essa diferença, a migração não consegue explicar por que um ramo existe no destino.

A decisão de arquitetura também depende do limite do sistema. Se chamadores dependem da lista de parâmetros de um programa RPG, mensagens de fila de dados, formatos de registro descritos externamente, controle de confirmação ou estado no nível do job, preserve primeiro esse contrato. Os componentes internos mudam por trás de um adaptador. Tentar redesenhar ao mesmo tempo todos os contratos vizinhos transforma uma migração de linguagem em um projeto sem limites de modelo operacional.

Alguns comportamentos não devem sobreviver. Alias de indicadores, campos globais mutáveis, aberturas implícitas e temporização do ciclo não merecem lugar permanente no destino. Preserve suas consequências observáveis, prove a paridade e depois remova o suporte temporário. Essa sequência separa “mesmo comportamento” de “mesma implementação”, uma distinção que programas de modernização costumam apagar.

A descoberta deve inspecionar todo o sistema executável

Uma estimativa baseada na contagem de linhas de membros RPG exclui grande parte do programa. O sistema executável inclui membros copiados, arquivos de tela e impressora, definições de banco de dados, wrappers CL, comandos, descrições de jobs, diretórios de ligação, programas de serviço, áreas de dados, filas de dados, arquivos de mensagens, objetos SQL e o procedimento de compilação. Um membro de 300 linhas pode estar no centro de uma superfície de comportamento muito maior.

Comece com um inventário reproduzível cujas linhas possam ser rastreadas até evidências. No mínimo, capture identidade do objeto ou membro, tipo de fonte, metadados da última compilação quando disponíveis, referências diretas, chamadores de entrada, dependências de cópia, modo de acesso a arquivo, quantidade de indicadores por função, uso do ciclo, sub-rotinas e procedimentos, SQL incorporado, chamadas externas e fonte indisponível. Marque fonte gerada e variantes duplicadas em vez de eliminar duplicatas silenciosamente.

A pergunta incômoda é se toda a fonte de produção existe. No IBM i, um objeto executável não garante que a fonte exata ou as opções de compilação continuem disponíveis. Equipes encontram com frequência um membro que parece mais novo em uma biblioteca enquanto a produção executa um objeto compilado a partir de outra revisão. Compare metadados do objeto, listas de bibliotecas, informações de ligação e comportamento implantado. Se a procedência for incerta, precifique essa incerteza em vez de presumir que o repositório é canônico.

A amostragem precisa seguir o risco, não a conveniência. Ler o programa de serviço em formato livre mais limpo diz pouco sobre um relatório de cobrança orientado pelo ciclo. Escolha amostras que cubram cada modo de fonte, modelo de execução, estilo de E/S, padrão de indicadores, tipo de objeto e caminho de negócio. Inclua o membro que todos evitam, aquele com O-specs copiadas e o programa que roda apenas no fechamento. É aí que a estimativa precisa se provar.

Um resultado de descoberta deve separar fatos conhecidos, inferidos e não verificados. “Programa A chama Programa B” pode ser conhecido por um grafo resolvido. “Indicador 42 significa tentar novamente” pode ser inferido de operações e mensagens. “Este ramo está morto” permanece não verificado até que evidências de produção ou um teste controlado o sustentem. Níveis diferentes de confiança exigem reservas diferentes; reduzi-los a uma única pontuação de complexidade esconde o trabalho.

A paridade precisa de evidências parecidas com produção

Compilação bem-sucedida prova sintaxe, e testes unitários provam funções selecionadas. Nenhum dos dois prova que um sistema RPG reescrito se comporte como a produção. Testes de paridade devem comparar o antigo e o novo com entradas que representem trabalho real, incluindo ordem de registros, valores em branco e zero, limites de decimal compactado, códigos de status, quebras de controle, registros ausentes, chaves duplicadas, fim de arquivo e contexto de job.

A unidade de comparação deve corresponder ao contrato. Para um relatório, compare conteúdo normalizado do spool, limites de página e total e quaisquer registros de efeito colateral. Para uma atualização em lote, compare alterações de banco, mensagens, chamadas, limites de confirmação e estado de reinício. Para um fluxo interativo, compare transições de tela, mensagens de validação, comportamento de teclas de função e escritas resultantes. Campos de horário, identificadores gerados e ordenação não determinística precisam de regras declaradas de normalização, não exclusões improvisadas depois de uma diferença.

Use um manifesto para cada repetição:

{"case":"account-break-final-record","input_set":"sha256:...","old_build":"LIBA/ORDRPT:...","new_build":"git:...","normalizers":["run_timestamp"],"expected_events":417}

O harness deve manter a identidade da entrada, as duas identidades de build, saídas normalizadas, saídas brutas quando a política permitir e o primeiro evento divergente. “Os arquivos diferem” cria uma investigação. “No evento 413, o código antigo emitiu ACCT_TOTAL antes de processar a conta 170; o novo emitiu depois” identifica o modelo quebrado de quebra de controle.

Tráfego de produção gravado é especialmente útil porque contém combinações que autores de testes esquecem. Ainda precisa de regras: mascarar ou tokenizar campos sensíveis de modo consistente, preservar igualdade relacional, capturar atributos de job necessários e impedir que repetições chamem sistemas externos reais. Quando o tráfego não pode sair do perímetro do cliente, execute a comparação ali. A CodeHero usa esse modelo: lê toda a árvore, reescreve a arquitetura e verifica o comportamento com um harness de paridade contra tráfego de produção gravado.

Paridade não exige preservar para sempre todo acidente antigo. Primeiro classifique cada diferença como comportamento obrigatório, defeito tolerado, ruído ambiental ou mudança aprovada. Depois torne a decisão auditável. “Corrigir” silenciosamente um cálculo durante a migração pode ser mais perigoso que mantê-lo por algum tempo, pois arquivos posteriores ou processos de conciliação podem depender do resultado antigo.

Estimativas de fixo e livre precisam de unidades diferentes

Uma migração procedural de formato livre muitas vezes pode ser estimada por unidades explícitas: procedimentos, instruções SQL, contratos de arquivo, chamadas externas, telas e testes. Código cíclico de formato fixo precisa de unidades extras para a semântica recuperada: grupos de indicadores, redes de especificações de entrada e saída, grupos de nível de controle, arquivos controlados pelo ciclo, caminhos de saída de exceção, estado de sub-rotinas e reconstrução de fonte. Essas unidades representam análise e verificação, não digitação.

Separe a estimativa em quatro blocos: inventário e procedência, recuperação semântica, implementação de destino e evidências de paridade. Código procedural em formato livre pode gastar mais orçamento na implementação. Código de ciclo fixo normalmente desloca esforço para recuperação semântica e projeto de repetição. Aplicar uma taxa por linha a ambos torna invisível o trabalho difícil e premia a métrica menos informativa.

A complexidade deve aumentar quando as interações se multiplicam. Um indicador de quebra de nível com uma linha de total tem limites claros. Vários níveis de controle combinados com registros correspondentes, indicadores compartilhados, saída de exceção e especificações copiadas criam combinações de estado. Não acrescente uma sobretaxa fixa por recurso fingindo que os efeitos são independentes. Precifique os caminhos combinados de comportamento que precisam ser entendidos e testados.

Use intervalos até que a descoberta resolva incógnitas específicas. Uma boa estimativa registra uma base e uma condição de saída junto de cada intervalo: “semântica do ciclo, confiança média, reduz após dois rastreamentos representativos” é defensável. “Conversão RPG, 500 linhas por dia” não é. O intervalo deve diminuir quando a equipe resolve a procedência, produz o registro de indicadores, valida o grafo de chamadas e repete casos representativos.

A estimativa também deve dizer o que exclui. Limpeza de dados, alteração de regras de negócio, substituição do agendamento anterior, novo projeto de telas ou fusão de aplicativos duplicados podem ser trabalhos sensatos, mas não fazem parte automaticamente de uma reescrita de linguagem. Se as partes interessadas os quiserem, dê a eles decisões, evidências e preço próprios. Caso contrário, toda mudança desejável será cobrada como “dificuldade do RPG”, e ninguém saberá quanto a migração realmente custa.

Coloque os dois estilos na mesma planilha de estimativa e a diferença fica concreta. Para um serviço procedural em formato livre, o analista normalmente identifica um procedimento de entrada, segue leituras explícitas ou SQL, lista chamadas, mapeia valores retornados e conta contratos que precisam de adaptadores. Ainda há incógnitas, sobretudo em estado de job e objetos externos, mas cada uma se liga a uma operação ou limite visível. A estimativa avança rapidamente do inventário ao projeto porque o programa declara quando o trabalho acontece.

Para um relatório cíclico fixo, a primeira planilha começa antes. O analista precisa determinar qual arquivo o ciclo controla, quais especificações de entrada identificam registros, quais campos causam quebras de nível, quando os totais rodam, quais linhas O-spec eles condicionam e o que LR aciona. Depois vem o registro de indicadores, incluindo valores definidos implicitamente por operações de arquivo. Só então o destino expõe a mesma sequência com leitor, lógica de agrupamento, cálculos e adaptadores de saída. Contar ambos como um “membro RPG” apaga uma camada inteira de entregas.

Os critérios de aceite diferem do mesmo modo. O serviço procedural pode ser coberto por casos de requisição e resposta, efeitos no banco e caminhos explícitos de erro. O relatório cíclico precisa de casos ordenados para o primeiro registro, cada nível de controle, registros que mudam vários níveis ao mesmo tempo, entrada vazia ou ausente quando pertinente e o último registro. Se houver lógica de registros correspondentes ou saída de exceção, a matriz cresce em torno dessas interações. Os testes extras não compensam uma conversão ruim. Eles provam que o novo fluxo explícito corresponde ao antigo fluxo implícito.

As habilidades de revisão também entram na estimativa. Um engenheiro Go pode avaliar a estrutura de destino e não perceber que um cálculo de total lê campos de outra fase do ciclo. Um profissional de RPG pode recuperar esse comportamento e aceitar uma arquitetura literal por parecer familiar. Combine as duas revisões até que rastreamentos de paridade e representação intermediária tornem o raciocínio visível. O ponto de entrega deve ser evidência: um revisor precisa rastrear um ramo de destino até uma regra RPG, condição da fonte ou novo projeto aprovado.

Estime retrabalho separadamente da implementação esperada. Uma regra de conversão conhecida aplicada a centenas de cálculos regulares é trabalho de implementação. Um indicador não resolvido que controla cinco formatos de saída é risco de descoberta, e adivinhá-lo cria retrabalho em vez de progresso. Registre responsável, evidência necessária e prazo de decisão para cada risco. Assim a reserva é explicável e a incerteza de poucos membros fixos não infla o preço do código procedural limpo.

Os números ainda podem compor uma proposta comercial, mas ela deve preservar as classes internas. A entrega pode adiantar componentes procedurais de baixa incerteza enquanto o trabalho semântico fecha caminhos cíclicos arriscados, sem fingir produtividade uniforme. Se uma dependência comum bloquear ambas as classes, mostre-a uma vez no portfólio. Se apenas a recuperação do ciclo precisar dela, mantenha o custo nessa classe. Assim um preço de projeto permanece honesto sem impor uma estimativa a dois tipos de trabalho.

A separação também esclarece o controle de mudanças: quando uma nova regra do ciclo altera a estimativa, os envolvidos veem qual classe mudou e por que a previsão procedural não mudou.

Um número misto cria o plano errado

A mesma estimativa não pode cobrir código cíclico de formato fixo e RPG procedural de formato livre porque o trabalho começa em níveis diferentes de certeza. No caso procedural, a equipe geralmente consegue ver o fluxo de controle e gastar tempo reconstruindo contratos com clareza. No ciclo fixo, primeiro precisa reconstruir o fluxo a partir de colunas, especificações, indicadores, regras do compilador e evidências de execução. Ambos podem ser migrados, mas não entram na fábrica pela mesma porta.

Isso não justifica um projeto arqueológico sem fim. Limite a descoberta por tempo em torno de classes representativas de risco e exija resultados concretos: censo de modos de fonte, classificação de modelos de execução, grafo de build resolvido, registros de indicadores para membros arriscados, rastreamentos de ciclo, inventário de contratos e casos de paridade. Se uma tarefa não consegue dizer qual incerteza da estimativa reduz, corte-a.

Para um portfólio, ofereça intervalos separados pelo menos para código fixo ou misto orientado pelo ciclo, código fixo ou misto procedural e código procedural totalmente livre. Depois ajuste por fonte ausente, quantidade de objetos externos, sensibilidade de contratos de dados e evidências de teste. Mantenha a classificação visível no planejamento de entrega, pois ela também determina habilidades de revisão e a ordem em que componentes devem migrar.

A CodeHero se compromete a concluir cada reescrita em menos de 30 dias, inclusive sistemas com mais de um milhão de linhas. Por isso, nossa entrada precisa fazer essas distinções imediatamente, em vez de escondê-las em uma taxa mista. Com ou sem a nossa participação, peça a qualquer fornecedor de migração que mostre como sua estimativa trata fases do ciclo, reutilização de indicadores, especificações copiadas, procedência da produção e paridade em quebras de controle. Se a resposta voltar à contagem de linhas, a estimativa não descreveu o trabalho.