Por que a migração de dados SAP falha e como corrigir

A migração de dados SAP falha por um motivo mais do que por qualquer outro: o plano é montado sobre o que o negócio acha que seus dados são, e não sobre o que uma extração mostra. Este guia é para diretores de programa, líderes de dados e líderes de finanças em um programa de S/4HANA. Ele cobre por que as migrações quebram, os cinco erros por trás da maioria das falhas de cutover, um plano de cargas simuladas que você pode copiar e quais ferramentas SAP servem para cada tarefa em 2026. Se você fizer uma única coisa esta semana, faça uma extração completa dos seus mestres de clientes, fornecedores e materiais e conte os registros você mesmo.

Uma empresa de manufatura gastou 18 meses e US$ 4,5 milhões na implementação do SAP. O dia do lançamento chegou. Todos estavam nervosos, mas animados. Então a migração de dados falhou.

Nada funcionava direito. Faltavam dados de clientes. Os números de estoque estavam errados. A contabilidade não conseguia fechar os livros. O CEO estava furioso.

Não foi o software e não foi a equipe de implementação. A falha estava na distância entre o que o negócio achava que seus dados eram e o que eles realmente eram.

O modelo de dados do SAP não é uma importação plana. Os registros dependem uns dos outros. Um mestre de materiais tem um registro geral (MARA), dados de centro (MARC), dados de avaliação (MBEW) e, onde áreas de MRP são usadas, dados de área de MRP (MDMA). Se você carrega o cabeçalho sem as visões dependentes, o material existe, mas não pode ser usado em uma transação.

O S/4HANA acrescenta a sua própria regra. Clientes e fornecedores são parceiros de negócios. Um cliente legado vira um parceiro de negócios com função de cliente, e um fornecedor vira um com função de fornecedor. Limites de crédito, dados bancários e números fiscais ficam pendurados nesse parceiro de negócios. Um registro que o sistema legado tolerava com lacunas vai falhar na validação aqui.

Depois vem o volume. A maioria das empresas se choca com a quantidade de dados que realmente tem. Um cliente achava ter cerca de 50.000 registros de material. Contando todas as variantes e os registros específicos de cada centro, o número estava mais perto de 500.000. Um plano dimensionado para o primeiro número não sobrevive ao segundo.

Estimativa do negócioExtração completa

Registros de material no escopo500,000+450,000 · +900%

Estimativa do negócio50,000

Extração completa500,000

• Todas as variantes e registros específicos de cada centro contados
• Um plano dimensionado sobre a estimativa não sobrevive a esse número

Isso não era um problema de migração de dados. Era um problema de escopo que virou um.

A avaliação da qualidade dos dados no início de um projeto costuma ser uma descrição dos dados, não um exame deles. O diretor financeiro diz que o mestre de fornecedores é bem mantido. O gerente de armazém diz que os materiais estão quase todos limpos. Isso são impressões.

A primeira extração revela a verdade. Fornecedores que deveriam ter sido limpos anos atrás e não foram. Materiais descontinuados há muito tempo e nunca desativados. Endereços de clientes com códigos de país inconsistentes. Dados bancários ausentes em fornecedores pagos por transferência eletrônica.

Cada um desses itens exige uma decisão de negócio, não uma correção técnica. Só o contas a pagar sabe dizer qual de dois fornecedores duplicados está correto. Só as compras sabem dizer quais materiais obsoletos bloquear e quais deixar para trás. Essas decisões levam tempo e precisam das pessoas que conhecem os dados. Se a avaliação não se baseia em uma extração real, o plano é construído sobre premissas que não sobreviverão ao contato com os dados. Meu estimador gratuito de migração de dados ajuda a dimensionar o esforço quando você já tem contagens reais.

1. Tratar a migração como uma tarefa técnica tardia

A migração pertence a todas as fases do SAP Activate. O Explore define o escopo: objetos, sistemas de origem, volumes e qualidade. O Realize constrói os templates e executa as cargas simuladas. O Deploy executa o ensaio final e a carga do cutover. O Run reconcilia o primeiro fechamento de período com dados reais.

Projetos que começam o trabalho de migração no Deploy começam com meses de atraso. Os problemas de qualidade que deveriam ter sido resolvidos no Realize aparecem na primeira carga simulada, semanas antes do cutover. Meu guia de planejamento de cronograma SAP mostra onde a migração se encaixa no plano geral.

2. Pouco envolvimento do negócio

A migração é técnica na execução e uma atividade de negócio na tomada de decisão. A TI não consegue produzir a lista de fornecedores duplicados. Quais contas de clientes migram como ativas e quais ficam como histórico é uma decisão de finanças. A limpeza de materiais obsoletos exige compras, armazém e gestão de produto.

Programas que alocam na migração apenas pessoas técnicas, e tratam o negócio como uma assinatura no fim, produzem dados que carregam. Do ponto de vista comercial, estão errados.

3. Planejar poucas cargas simuladas

Uma migração de dados SAP bem conduzida precisa de pelo menos três cargas simuladas antes do cutover, e programas complexos precisam de mais. Projetos que planejam uma ou duas estão planejando para dados limpos e um mapeamento limpo. Esse cenário é raro. Mais ciclos não são sinal de uma migração com problemas. São sinal de uma migração bem planejada.

4. Não reconciliar as cargas de teste

Um job de carga que termina sem erros não é validação. Validar é comparar o que foi carregado com o que era esperado: contagens de registros, totais financeiros, saldos de partidas em aberto. Depois, um smoke test de processo confirma que os dados funcionam nas transações.

Uma carga de teste que não foi reconciliada ainda custa tempo. A lacuna que ela produziu continua lá na carga simulada seguinte, só que agora é mais difícil rastreá-la até a causa. Reconcilie cada carga antes de começar a próxima.

5. Uma carga de cutover diferente dos ensaios

A migração do cutover deve repetir exatamente a última carga simulada: os mesmos scripts de extração, a mesma lógica de transformação, a mesma sequência de carga, as mesmas verificações e o mesmo tempo. Qualquer mudança no cutover é um risco não testado no ponto de maior pressão do programa.

A peça menos testada costuma ser o delta. Entre a última carga simulada e o cutover, o negócio continua incluindo fornecedores, alterando pedidos e movimentando estoque. Defina a data de congelamento dos dados e ensaie a carga delta como parte da última carga simulada.

Use esta estrutura de ciclos como ponto de partida. Cada ciclo tem um objetivo e um critério de saída, e só está concluído quando a reconciliação é assinada.

Ciclo	Objetivo	Critério de saída	Responsável
Carga simulada 1	Estrutura: todos os objetos carregam na ordem das dependências	Lacunas de mapeamento e erros de formato registrados por objeto	Líder de migração de dados
Carga simulada 2	Qualidade: testar as correções de mapeamento e expor problemas nos dados	Taxa de erros em queda por objeto; decisões de limpeza registradas	Data stewards
Carga simulada 3	Regras de negócio: exceções e casos-limite	Os data stewards aceitam uma amostra reconciliada em cada domínio	Data stewards
Carga simulada 4	Volume e tempo no tamanho pleno de produção	A carga completa termina dentro da janela do cutover	Gerente de cutover
Ensaio final	Ensaio geral do cutover, incluindo delta e congelamento	Contagens e totais financeiros reconciliados e assinados	Controller financeiro e líder de dados

Em torno desse plano, cinco coisas fazem a diferença:

1. Uma extração completa no Prepare. Tudo, não uma amostra. Faça o profiling de completude, precisão, consistência e duplicidades e depois dimensione a limpeza e o prazo a partir dos resultados.
2. Mapeamento objeto por objeto. Para cada objeto (parceiros de negócios, materiais, pedidos de compra e de venda em aberto, partidas em aberto, estoque, ativos imobilizados), documente os campos de origem e destino, as regras de transformação, as verificações de validação e as regras de exceção.
3. Data stewards nomeados. Finanças é dona dos dados financeiros de clientes e fornecedores. Compras é dona do mestre de materiais. O armazém é dono do estoque. Cada steward assina o seu domínio ao fim de cada ciclo.
4. Reconciliação definida desde o início. Combine quais contagens e totais provam que uma carga está certa antes da primeira carga simulada, para que ninguém discuta isso no cutover.
5. Uma sequência de cutover por escrito. Congelamento, extração, transformação, carga, validação, aprovação do negócio, go/no-go. A mesma sequência do ensaio final.

Para uma nova implementação de S/4HANA, o SAP S/4HANA Migration Cockpit é a ferramenta recomendada pela SAP para a carga inicial. Desde o S/4HANA 2020, ele roda como o app Fiori Migrate Your Data. A transação LTMC está obsoleta, e projetos LTMC existentes só podem ser exibidos. O app oferece duas abordagens: migrar dados usando tabelas de staging (preenchidas a partir de arquivos ou por suas próprias ferramentas) e migrar dados diretamente de um sistema de origem SAP. As equipes de on-premise e de nuvem privada usam a transação LTMOM, o modelador de objetos de migração, para ajustar objetos padrão ou criar os seus. O cockpit foi feito para cargas iniciais, não para interfaces recorrentes nem para alterações em massa.

O SAP Data Services é a plataforma de ETL da SAP. Use-o para grandes volumes, lógica de transformação pesada, vários sistemas de origem, ou quando você quer um framework de qualidade de dados reutilizável que sobreviva ao projeto.

As ferramentas de ETL de terceiros, como Informatica, Talend ou Microsoft SSIS, fazem sentido quando a organização já as possui e tem as competências.

O SAP Datasphere, hoje parte do SAP Business Data Cloud, não é uma ferramenta de migração. O lugar dele é a camada de analytics depois do go-live. Ele importa se você deixa o histórico no sistema legado e ainda precisa gerar relatórios sobre ele.

Na maioria das implementações padrão, o Migration Cockpit cobre a maior parte dos objetos. Grandes volumes, sistemas legados muito customizados ou estruturas de origem incomuns costumam exigir o Data Services ou uma ferramenta de ETL ao lado dele. Conversões a partir do ECC são outro exercício, tratado no meu guia de migração de ECC para S/4HANA.

O que é a migração de dados SAP?

A migração de dados SAP é extrair dados de sistemas legados, transformá-los para se ajustarem às estruturas e regras do SAP e carregá-los no SAP como parte de uma implementação ou conversão. Os objetos típicos são parceiros de negócios (clientes e fornecedores), materiais com dados de centro, pedidos de compra e de venda em aberto, saldos de estoque, partidas financeiras em aberto e ativos imobilizados. É difícil porque o SAP impõe dependências e regras de validação que os sistemas legados muitas vezes não tinham.

Quais são as principais abordagens de migração de dados SAP?

Uma nova implementação (greenfield) carrega dados mestre selecionados e partidas em aberto em um sistema S/4HANA novo, deixando o histórico no sistema legado ou em um arquivo. Uma conversão de sistema (brownfield) converte no próprio lugar um sistema ECC existente e o seu histórico. A transição seletiva de dados fica entre as duas, movendo códigos de empresa, objetos ou fatias de tempo escolhidos. A escolha certa depende da qualidade dos dados, das exigências de histórico e de quanto do processo antigo você quer manter.

O que é o SAP Migration Cockpit e quando usá-lo?

O SAP S/4HANA Migration Cockpit é a ferramenta recomendada pela SAP para a carga inicial de dados no S/4HANA, em todas as edições. Desde o S/4HANA 2020, ele roda como o app Fiori Migrate Your Data; a transação LTMC está obsoleta. Ele oferece objetos de migração predefinidos, valida os dados antes da contabilização e informa os erros no nível do campo. Use-o para objetos padrão em volumes normais. Acrescente o SAP Data Services ou outra ferramenta de ETL quando volumes, lógica de transformação ou estruturas de origem ultrapassarem o que os templates tratam.

Para quantas cargas simuladas um plano de migração de dados SAP deve se preparar?

Pelo menos três, com a última sendo um ensaio completo do cutover. Programas complexos precisam de mais. Em um plano típico, a primeira encontra lacunas estruturais de mapeamento. A segunda testa as correções e expõe problemas de qualidade dos dados. A terceira trabalha as regras de negócio e os casos-limite. A execução final repete o cutover exatamente, e a sua reconciliação vira a linha de base para o dia do go-live.

Como migrar clientes e fornecedores para o SAP S/4HANA?

Como parceiros de negócios. No S/4HANA, os dados mestre de clientes e fornecedores são mantidos por meio do parceiro de negócios, com as funções de cliente e de fornecedor associadas. Em uma nova implementação, o Migration Cockpit os carrega por meio dos seus objetos de parceiro de negócios. Em uma conversão a partir do ECC, a integração cliente-fornecedor precisa ser configurada e executada antes da própria conversão.

O que faz a migração de dados SAP falhar no cutover?

Cinco padrões causam a maioria das falhas de cutover. Poucas cargas simuladas. Uma sequência de cutover nunca testada de ponta a ponta. Mudanças no legado depois da última carga simulada, com uma carga delta não testada. Lacunas de reconciliação deixadas em aberto. Aprovação do negócio baseada em uma checagem por amostragem. “Os primeiros 1.000 registros pareciam bons” não é validação. O go-live exige contagens e totais reconciliados.