O que sobrevive à migração do ECC para S/4HANA?

O prazo de 2027 não é a data para começar uma migração do ECC para S/4HANA. É a data em que as decisões difíceis, reescritas, simulações e aprovações do negócio já precisam estar concluídas. A conversão padrão da SAP raramente é o que descarrila um programa. O problema costuma ser o sistema particular construído ao redor do SAP durante vinte anos: programas Z, includes modificados, user exits, BAdIs, jobs em segundo plano, trocas de arquivos, formulários, relatórios e premissas que ninguém registrou.

Tratar esse patrimônio como uma pilha de ABAP que só precisa compilar produz um sistema tecnicamente verde, mas com o comportamento de negócio quebrado. A avaliação deve comprovar quatro fatos distintos para cada objeto: se ele ainda executa, se a SAP ainda permite seu ponto de extensão, se alguém ainda o usa e se o resultado continua correto. Essas perguntas exigem evidências diferentes. Uma única varredura não responde às quatro.

O prazo de 2027 muda a ordem do trabalho

O compromisso de manutenção publicado pela SAP prevê manutenção convencional para os principais aplicativos do SAP Business Suite 7 até o fim de 2027, com manutenção estendida opcional até o fim de 2030 para os clientes que a comprarem. A extensão cria espaço, não um projeto de migração. Compras pode adquirir cobertura de suporte, mas não consegue recuperar os anos necessários para entender uma lógica de liquidação sem documentação ou reconstruir com segurança uma interface de armazém.

Por isso, o primeiro marco sensato é uma avaliação que produza evidências, não um slide de arquitetura futura. Ela deve deixar um inventário de objetos, dados reais de uso, grupos de dependências, impactos conhecidos das simplificações, comportamentos de negócio testáveis e responsáveis nomeados. Se entregar apenas a contagem de objetos personalizados por pacote, terá contado o problema sem descrevê-lo.

Comece enquanto o ECC ainda representa a verdade. Carga de produção, histórico de jobs, tráfego das interfaces e resultados financeiros conciliados são muito mais úteis do que lembranças coletadas depois de um congelamento. Quando as equipes começam a desativar jobs ou mudar integrações por causa do programa, a referência fica contaminada. Já vi equipes tentarem reconstruir o comportamento antigo do fechamento mensal com base em atas porque ninguém capturou uma execução limpa quando podia. Isso é evitável.

O prazo também muda o sequenciamento. A análise do código personalizado deve vir antes da definição firme do escopo de conversão, pois as descobertas podem alterar o destino. Uma transação ECC muito modificada pode virar uma extensão S/4HANA, um serviço separado, uma capacidade padrão ou ser aposentada. Não dá para estimar esses caminhos com honestidade antes de saber quais códigos e dados cada transação toca.

O patrimônio personalizado vai além do namespace Z

Uma lista de objetos Z é um início útil e uma definição perigosa de escopo. O comportamento do cliente pode estar em namespaces, modificações de objetos SAP, implementações de enhancement, código gerado, variantes, regras de workflow, conteúdo BRFplus, formulários, cadeias de jobs, ramificações dependentes de autorização e programas externos que chamam RFCs ou leem arquivos. Parte do código de maior consequência não tem uma transação Z que um responsável de negócio reconheceria.

Monte o inventário com várias fontes e preserve as chaves de junção. Os metadados do repositório mostram o que existe. O ATC e as verificações de S/4HANA apontam padrões estáticos que conflitam com a versão de destino. SCMON e SUSG mostram procedimentos executados durante um período representativo. Os dados do ST03N ajudam a relacionar transações e usuários. O histórico do SM37 expõe caminhos batch. Onde há modificações, SPAU e SPDD mostram onde o cliente se afastou da SAP. Catálogos de interfaces, destinos RFC, configuração de IDoc e agendas de transferência cobrem caminhos fora do diálogo.

Não reduza tudo cedo demais a uma pontuação de risco. Mantenha por objeto pelo menos identidade no repositório, pacote, componente, última alteração, relações entre chamador e chamado, execução observada, processo de negócio, dados tocados, descoberta de simplificação, mecanismo de extensão, evidência de teste e responsável. Um objeto sem uso observado pode ser um relatório anual. Um utilitário chamado com frequência pode ser de baixo risco porque apenas formata datas. Frequência e consequência são eixos separados.

O código alcançado indiretamente é a categoria difícil. Um user exit chamado pelo processamento padrão talvez nunca apareça como transação nomeada nas estatísticas. Um módulo de função pode executar somente por um RFC externo. Uma rotina de formulário pode ser selecionada no customizing. A análise de dependências deve começar nas entradas do negócio e atravessar chamadas, tabelas, mensagens, jobs e interfaces. Contar objetos isolados esconde os grupos que precisam migrar juntos.

Também incluo artefatos operacionais no escopo. Variantes de jobs, destinos de impressão, caminhos lógicos de arquivos, gatilhos de eventos, certificados e usuários técnicos não são ABAP, mas o comportamento reconstruído muitas vezes depende deles. Uma equipe que declara o código concluído enquanto o Basis recompõe essas dependências durante o cutover não concluiu a avaliação.

Compilar prova menos do que muitos gostariam

Uma verificação sintática limpa prova que o compilador aceita o programa no novo ambiente. Não prova que o programa lê os mesmos registros, aplica a mesma ordem, lança os mesmos documentos, respeita os mesmos bloqueios ou termina dentro da janela batch. Compatibilidade é uma barreira necessária e um teste de negócio fraco.

O S/4HANA muda modelos de dados e oferece views de compatibilidade em alguns pontos para facilitar a transição. Isso pode manter leituras antigas funcionando enquanto esconde um problema de arquitetura. Um código que lê uma view de compatibilidade pode retornar dados plausíveis e ainda ignorar a API liberada ou o modelo semântico esperado pelo novo projeto. Pode ser correto substituir o acesso, aposentar o caminho personalizado ou mantê-lo temporariamente com validade explícita. Um resultado verde no ATC não toma essa decisão.

O comportamento implícito do banco também gera falsa confiança. Considere uma rotina antiga como esta:

SELECT * FROM vbap
  INTO TABLE @DATA(items)
  WHERE vbeln = @order_number.

READ TABLE items INDEX 1 INTO DATA(first_item).

Sem ORDER BY, o banco não garante qual linha aparece primeiro. Se o código posterior trata o índice um como o item mais antigo, uma mudança no banco ou no plano de execução pode alterar o resultado sem erro de sintaxe. A correção não é acrescentar uma ordenação arbitrária até o teste passar. A equipe deve recuperar a regra de negócio pretendida, codificá-la claramente e testar limites como itens rejeitados, renumerados ou excluídos.

SQL nativo, hints de banco, premissas sobre tabelas pooled ou cluster, atualizações diretas em tabelas da SAP e padrões amplos de SELECT * merecem atenção, mas não formam toda a avaliação. Chamadas dinâmicas, rotinas carregadas de field symbols e instruções geradas podem escapar de um rastreamento estático simples. Combine descobertas automáticas com leitura focada nos pontos de entrada de maior consequência. A análise estática oferece um mapa, mas não explica por que a estrada foi construída.

User exits e BAdIs são contratos

Uma implementação de enhancement não pode ser julgada apenas pelo código que contém. Seu contrato real inclui quando a SAP a chama, quais dados estão completos naquele momento, se as atualizações ocorrem no diálogo ou na update task, quais exceções o chamador trata e qual lógica padrão posterior pode sobrescrever alterações. Um BAdI substituto de nome semelhante pode ter outro contrato.

User exits e customer exits clássicos costumam carregar pouco código com peso desproporcional para o negócio. Algumas linhas podem derivar um centro de lucro, rejeitar um pedido, mudar preços ou encaminhar uma aprovação. Durante a avaliação, registre gatilho, estado de entrada, efeitos colaterais, comportamento de erro e consumidor posterior de cada implementação. Depois, associe-a ao ponto de extensão recomendado para a versão e o modelo de implantação exatos. Não suponha que uma opção on-premise exista do mesmo modo em todos os destinos.

A recomendação comum de substituir todo exit imediatamente por um BAdI é grosseira demais. Parece moderna e dá ao programa uma métrica fácil, mas o contêiner não determina a qualidade do projeto. Algumas lógicas pertencem a uma extensão in-app liberada, outras a um serviço side-by-side, outras à configuração padrão e outras devem desaparecer. Mover lógica opaca para um hook mais novo preserva a opacidade.

Modificações de objetos SAP pedem uma decisão ainda mais rigorosa. Pergunte por que a modificação existia, se a SAP depois ofereceu a capacidade e se o negócio ainda depende da diferença. O trabalho de SPAU não deve virar um ritual de reaplicar toda alteração histórica. Cada modificação retomada aumenta o peso das futuras atualizações, então seu responsável deve defendê-la com evidências atuais e um teste que falhe sem ela.

Documente a decisão como contrato: dado este evento e estado do negócio, a extensão deve produzir estas alterações ou este erro e não deve alterar estes campos protegidos. Essa declaração funciona se o destino for ABAP, configuração, Go ou um workflow fora do núcleo.

Dados de uso precisam de um calendário do negócio

Evidência de execução é essencial, mas uma janela não é representativa só porque é longa. Ambientes SAP contêm fechamento trimestral, imposto de fim de ano, inventário anual, preços sazonais, extratos de auditoria e jobs executados apenas em operações excepcionais. Decidir que um código não é usado requer um calendário de negócio e um responsável, não apenas a data da última execução.

Use o SCMON para coletar uso no nível de procedimento e o SUSG para agregar os resultados da análise. Combine essas evidências com histórico de carga, agendas batch e monitoramento de interfaces. O período deve incluir de propósito os eventos importantes para a organização. Se não puder incluir um evento anual, examine a execução anterior e converse com o operador que concilia o resultado.

Classifique candidatos como manter, alterar, aposentar ou não resolvido. Não exclua código não resolvido para melhorar um painel. A aposentadoria exige três evidências: nenhuma execução relevante, nenhum caminho de entrada configurado ou indireto e um responsável de negócio que aceite a remoção. Arquive a decisão e as dependências para resolver objeções tardias sem reiniciar a descoberta.

O uso também ajuda a escolher testes. Código frequente gera muito tráfego, mas caminhos raros e de alta consequência precisam de casos preparados. Uma liberação de crédito ou correção fiscal pouco usada pode merecer testes mais profundos do que um relatório aberto toda manhã. Classifique pelo dano de um resultado errado, dificuldade de detecção e possibilidade de recuperação.

Outra armadilha é a lógica duplicada. Dois programas Z podem calcular o mesmo conceito de modos diferentes no diálogo e no batch. A análise de execução vê dois objetos ativos. A análise de negócio deve ver uma regra em disputa. Revele essas diferenças antes da migração. Reescrever ambos fielmente preservaria uma falha no conhecimento da organização.

Descobertas de simplificação exigem decisões

SAP Readiness Check, Simplification Item Catalog e verificações ATC fornecem evidências essenciais, mas cada descoberta ainda precisa de interpretação local. Um item de simplificação diz que uma mudança técnica ou funcional importa. Não sabe se o programa é obsoleto, se um caminho de compatibilidade serve para a transição ou qual resultado do negócio precisa sobreviver.

Para cada descoberta, registre objeto, processo afetado, tratamento proposto, mecanismo de destino, teste que prova a decisão e pessoa que a aceita. Evite anotações como "ajustado" ou "não relevante" sem evidência. Seis meses depois, ninguém saberá se "não relevante" queria dizer código inacessível, falso positivo, processo aposentado ou premissa nunca verificada.

Uma sequência prática é esta:

1. Execute verificações ATC da versão de destino em todo o escopo personalizado, incluindo modificações e namespaces.
2. Relacione descobertas ao uso observado e aos grupos de dependências, em vez de revisar objetos em ordem alfabética.
3. Rastreie cada grupo de alto impacto até uma entrada de negócio e um responsável.
4. Escolha aposentar, manter temporariamente, adaptar ou redesenhar, registrando o motivo.
5. Anexe evidência executável: regressão, resultado conciliado, troca de interface gravada ou exceção aprovada.

Essa sequência evita um fracasso comum: desenvolvedores encerram milhares de descobertas locais enquanto o programa perde um processo entre sistemas. O número de descobertas mede o tamanho da fila de trabalho, não a prontidão. Um grupo com doze descobertas e teste de paridade conhecido pode ser mais seguro do que uma rotina de lançamento construída dinamicamente que nenhuma ferramenta resolve.

Mantenha isenções restritas e com data. Se uma descoberta permanecer porque uma view de compatibilidade é permitida durante a transição, nomeie a premissa de versão e a condição de remoção. Dispensas permanentes sem registro de projeto viram a arqueologia da próxima equipe de migração.

Interfaces falham nos limites de responsabilidade

A avaliação de uma interface deve cobrir protocolo, semântica do payload e acordo operacional. As equipes costumam inventariar RFCs, IDocs, APIs e arquivos e considerar uma interface compreendida porque conhecem seu endpoint. As falhas se escondem no significado dos campos, na sequência, no tratamento de duplicatas, nas confirmações e no caminho de reparo manual quando um lado não está disponível.

Comece pelas trocas observadas e pela configuração, não pelo nome no catálogo. Registre iniciador, agenda ou gatilho, autenticação, versão do payload, formato do volume, timeout, repetição, idempotência, premissa de ordem e responsável pela conciliação. Para arquivos, inclua nomes, codificação, separadores, totais de controle, diretórios e arquivamento. Para IDocs, preserve tipo de mensagem, tipo básico, extensões, perfis de parceiro, status e jobs de reprocessamento. Para RFCs, encontre chamadores externos e destinos configurados no SAP.

O ABAP personalizado muitas vezes expõe um contrato de dados por acidente. Um consumidor pode depender de um campo não documentado, de uma mensagem específica, de vazio em vez de zero ou da ordem das linhas. O S/4HANA pode oferecer uma API liberada mais limpa, mas mudar o endpoint não apaga essas premissas. Compare contratos antigo e novo campo a campo e decida se adapta o consumidor, instala uma camada de compatibilidade na fronteira ou versiona a troca.

A conciliação merece um teste próprio. Uma resposta HTTP bem-sucedida ou um status IDoc verde prova entrega até uma etapa técnica. Não prova que os dois sistemas aceitaram o mesmo evento de negócio exatamente uma vez. Defina a chave para relacionar registros, os totais ou estados comparados pelos operadores, o atraso aceitável e como repetir um item sem duplicar o lançamento. Capture exceções atuais porque o reparo pode conter regras ausentes do programa.

Peço às equipes que percorram uma falha completa. Suponha que o ECC grave toda noite um arquivo de preços, transfira-o para um sistema de armazém e arquive a origem. A transferência expira depois que o receptor guarda o arquivo, mas antes que o ECC registre sucesso. A repetição envia uma segunda cópia. Se o receptor identificar arquivos apenas pelo nome de chegada, importará os dois e mudará a avaliação do estoque duas vezes. A migração precisa preservar ou melhorar a detecção de duplicatas, não apenas reproduzir a execução feliz. Um caso de paridade deve exercitar timeout, repetição e conciliação.

Interfaces também limitam a sequência do cutover. Se um sistema externo não puder aceitar o novo contrato no mesmo dia, defina uma convivência limitada e o responsável por removê-la. Evite camadas bidirecionais com propriedade de estado pouco clara. Parecem flexíveis no plano e tornam-se permanentes quando ninguém consegue provar qual lado mantém o registro oficial.

Trate todo consumidor não documentado como risco aberto. Pesquise registros de rede e gateway disponíveis, atividade de usuários técnicos, logs de coleta e pergunte aos operadores quais extratos movem manualmente. Torne o contrato explícito antes de alterar o produtor. O pior momento para descobrir que um pequeno banco de desktop ainda consome um relatório Z é depois do primeiro fechamento no sistema novo.

A paridade deve ser registrada antes da reescrita

O melhor momento para capturar o comportamento esperado é enquanto o ECC ainda processa trabalho real e as equipes de finanças, cadeia de suprimentos e operações ainda conciliam seus resultados. Uma reescrita testada apenas com exemplos feitos à mão perderá combinações estranhas acumuladas por anos de uso.

Construa um harness de paridade em torno dos limites do negócio. Para relatórios, compare conjuntos ordenados e totais, com tolerâncias documentadas para campos cuja representação muda legitimamente. Para interfaces, grave solicitações, respostas, IDocs, arquivos e efeitos e reproduza casos higienizados contra o destino. Para lançamentos, compare tipos de documento, imputações, valores, moedas, impostos, transições e mensagens de erro das quais os operadores dependem. Mascare dados sensíveis sem destruir as combinações que acionam a lógica.

Um registro de caso útil pode ser simples:

{
  "case_id": "sales-order-credit-hold",
  "entry_point": "order_create",
  "input_ref": "fixture/credit-hold-017.json",
  "expected": {
    "status": "HELD",
    "posted_documents": 0,
    "message_id": "ZCREDIT-014"
  }
}

Os identificadores são ilustrativos, mas o formato obriga a equipe a declarar o que conta como igual. Acrescente precondições e efeitos protegidos quando necessário. Guarde o resultado bruto e a comparação normalizada para que os revisores vejam o que o harness ignorou. Se a normalização remover timestamps, ordem ou identificadores gerados, documente por que essas diferenças não têm significado para o negócio.

O tráfego gravado exige seleção cuidadosa. Raramente é preciso reproduzir cada chamada, e o volume bruto pode representar demais os casos fáceis. Selecione classes de equivalência, valores limite, combinações raras de status, erros e cada ramificação regulatória ou contratual conhecida. Depois, acrescente casos para regras encontradas na leitura do código mesmo que não apareçam na janela de captura.

Paridade não exige preservar uma arquitetura ruim. Ela fixa o comportamento externo relevante e permite limites e propriedade de dados mais claros. A CodeHero usa essa abordagem ao reescrever ABAP: a plataforma lê toda a árvore e um harness compara o sistema novo com tráfego de produção enquanto a arquitetura muda. O harness sustenta a aceitação, não a semelhança entre códigos-fonte.

Parte do ABAP não deve ir para o S/4HANA

A migração permite reduzir o núcleo personalizado, mas "clean core" não é uma ordem para mover todo programa questionável a outra plataforma. O local depende do comportamento, limite transacional, propriedade dos dados, latência e suporte. Mover uma validação muito acoplada para um serviço remoto pode acrescentar falhas sem criar uma fronteira útil.

Mantenha a lógica perto do núcleo quando ela precisar participar de modo síncrono de uma transação SAP e o destino oferecer um mecanismo liberado com o contrato necessário. Retire-a quando possuir uma capacidade distinta, puder operar por APIs ou eventos liberados e ganhar com um ciclo independente. Substitua código por comportamento padrão do S/4HANA quando o negócio aceitar a regra. Aposente-o quando as evidências mostrarem que o processo não existe mais.

A linguagem de destino é uma decisão secundária. Go pode servir a serviços com interfaces e operação claras. Rust pode servir a núcleos numéricos onde correção e controle importam. TypeScript pode servir a clientes e workflows. Nenhuma delas conserta um contrato de negócio ausente. Se a equipe não consegue dizer o que uma rotina ABAP deve fazer, traduzi-la para uma linguagem da moda só encarece a incerteza.

Cuidado com código remoto que ainda trata tabelas SAP como banco particular. Extrair um programa Z e manter o acoplamento direto cria um monólito distribuído com falhas de rede adicionais. Defina contrato de API ou evento, proprietário do estado, repetição e idempotência e teste falhas parciais. Um diagrama limpo sem conciliação não é um projeto concluído.

Também existe uma fronteira humana. Especialistas ABAP frequentemente conhecem exceções que arquitetos descartam como dívida técnica. Junte-os aos responsáveis de processo e engenheiros do destino. O objetivo não é preservar toda implementação antiga, mas evitar perder o conhecimento antes que a regra de negócio tenha outro lugar.

O entregável deve sustentar uma decisão de avançar ou parar

Uma avaliação confiável mostra a um executivo o que pode ser aposentado, adaptado ou redesenhado, o que segue desconhecido e quais evidências sustentam cada afirmação. Também deixa um engenheiro rastrear um risco até objetos, dependências, tráfego e testes. Se qualquer público precisar de uma história oral à parte, o entregável está incompleto.

Organize por capacidade de negócio e grupo de dependências, não por milhares de objetos. Para cada grupo, mostre escopo, entradas atuais, uso, impactos de simplificação, dependências de dados e interfaces, destino, cobertura de paridade, responsável e decisões abertas. Estime e sequencie por grupo, pois objetos de lançamento ou atendimento raramente migram de modo independente.

Defina critérios explícitos de saída. Todo objeto deve pertencer a um grupo ou conjunto de aposentadoria justificado. Todo grupo de alta consequência precisa de destino e responsável. Todo comportamento mantido precisa de uma fonte de teste. Todo item aberto precisa de data e evidência para decisão. Esses critérios expõem a incerteza, em vez de escondê-la num percentual.

Não deixe o programa declarar a descoberta encerrada sem evidências de produção. Registre agora tráfego representativo, resultados conciliados e execuções excepcionais enquanto o ECC está disponível e é confiável. Verificações estáticas podem ser repetidas depois. Uma ramificação de fim de ano ou um chamador externo esquecido talvez não possa ser recuperado quando necessário.

O prazo de 2027 é real porque as opções de manutenção ficam mais restritas e caras, mas pânico não é método de planejamento. A ação imediata é precisa: autorizar coleta de execução, fixar o formato do inventário, escolher o primeiro grupo de alto impacto e capturar seu comportamento. Com essas evidências, arquitetura, custo e prazo viram decisões de engenharia, não palpites.

Reserve orçamento para a incerteza, não apenas para correções conhecidas. Separe capacidade de decisão para objetos sem responsável, chamadas dinâmicas, relatórios irreproduzíveis e interfaces de consumidores desconhecidos. Não são pendências administrativas. São os pontos onde o escopo muda tarde quando alguém finalmente descobre o que o código faz.

Mantenha as evidências sob controle de versão e atualize-as quando o programa alterar o ECC. Um transporte emergencial, uma variante de job revisada ou uma mudança de interface depois da captura inicial pode invalidar mapa e testes. Adote uma regra: toda mudança em produção durante a migração deve indicar qual grupo, decisão e casos de paridade afeta. Assim, a referência não se afasta em silêncio do sistema real.

Por fim, ensaie o processo de decisão tanto quanto o software. Dê aos responsáveis um grupo realmente ambíguo e exija que escolham o destino, aprovem o comportamento aposentado e aceitem a evidência de paridade. Se ninguém tiver autoridade durante a avaliação, o mesmo assunto esperará numa reunião de cutover com menos tempo e opções piores.