Migração de ECC para S/4HANA: caminhos, etapas e prazos do SAP ECC

Uma migração de ECC para S/4HANA leva o seu sistema SAP ERP do SAP ECC 6.0 para o SAP S/4HANA, com novo banco de dados, novo modelo de dados financeiro e nova interface de usuário. A decisão que você tem pela frente é qual caminho seguir e se consegue entrar em go-live antes de a manutenção principal do ECC terminar, em 31 de dezembro de 2027.

Resposta curta: greenfield se você vem de outros sistemas ou precisa de novos processos, brownfield se os seus processos estão definidos e funcionando, transição seletiva de dados se só algumas áreas precisam ser redesenhadas. Na minha experiência, brownfield leva de 12 a 18 meses, greenfield de 18 a 24 meses e a transição seletiva de dados de 12 a 18 meses. Execute o SAP Readiness Check antes de se comprometer com qualquer um deles.

ECC para S/4HANA não é um simples upgrade. Muda a forma como os dados são armazenados, como as transações são lançadas e como os usuários trabalham.

Em um projeto em que trabalhei, uma equipe mandou reconstruir dezenas de relatórios customizados exatamente como eram no ECC. Ninguém perguntou se ainda eram necessários. Depois, metade deles nunca foi usada.

A migração foi tecnicamente limpa. O valor, não.

SAP ECC significa SAP ERP Central Component. É o núcleo do SAP ERP 6.0, uma das aplicações centrais do SAP Business Suite 7, e quando alguém diz "SAP ECC" quase sempre se refere ao ECC 6.0. Ele cuida de finanças, controladoria, compras, vendas e produção em qualquer banco de dados suportado pela SAP, do Oracle ao SQL Server e ao Db2.

A primeira razão para migrar é a manutenção. Para o SAP ERP 6.0 nos enhancement packages 6 a 8, a manutenção principal termina em 31 de dezembro de 2027. Os sistemas no enhancement package 5 ou inferior saíram da manutenção principal no fim de 2025 (SAP).

O SAP S/4HANA é o sucessor, e a SAP se comprometeu a mantê-lo até o fim de 2040.

A segunda razão é o tempo. Se você iniciar hoje, em outubro de 2026, uma conversão brownfield, o go-live cai entre o fim de 2027 e a primavera de 2028. Se iniciar hoje um greenfield, entra em go-live em 2028.

Portanto, para a maioria dos clientes ECC a pergunta já não é se devem migrar. É qual caminho seguir e quanto de manutenção estendida orçar enquanto isso.

Também falo sobre este tema em um vídeo no meu canal do YouTube (em inglês).

Estas são as diferenças que geram a maior parte do esforço de migração:

Área	SAP ECC	SAP S/4HANA
Banco de dados	Qualquer banco de dados suportado (Oracle, Db2, SQL Server, outros)	Somente SAP HANA
Modelo de dados financeiro	Tabelas separadas de FI, CO e rentabilidade, com tabelas de totais	Universal Journal (tabela ACDOCA) como fonte única de itens individuais
Dados mestre de clientes e fornecedores	Registros separados de cliente e fornecedor	Business partner obrigatório
Número de material	18 caracteres	Até 40 caracteres, se você ativar o comprimento estendido
Gestão de crédito	Gestão de crédito do SD	SAP Credit Management (FIN-FSCM)
Interface de usuário	SAP GUI	Apps SAP Fiori, com o SAP GUI ainda disponível on-premise e na Private Edition
Implantação	On-premise	On-premise, Private Edition (RISE with SAP) ou Public Edition (GROW with SAP)
Extensões	Programas Z e modificações	Clean core: APIs liberadas, ABAP Cloud on-stack ou side-by-side no SAP BTP
Manutenção	EHP 6 a 8: principal até o fim de 2027, estendida até o fim de 2030	Compromisso até o fim de 2040

A SAP registra cada uma dessas diferenças como um simplification item e as publica na Simplification List de cada release do S/4HANA. Algumas são obrigatórias para todos os clientes, como o business partner. Outras só importam se você usa a função, e o SAP Readiness Check mostra quais se aplicam ao seu sistema.

Um cliente europeu da indústria com quem trabalhei em 2023 perguntava sem parar por que seus jobs em lote customizados tinham deixado de funcionar depois da conversão. A lógica dependia de estruturas de tabelas do ECC que o S/4HANA havia alterado. Ninguém tinha perguntado se esses jobs ainda faziam sentido no novo modelo.

A migração move os dados. A verdadeira pergunta é o que você faz com as decisões de design que herda.

Minha regra para escolher é curta. Greenfield quando você está migrando de outros sistemas ou quando é preciso definir novos processos. Brownfield quando os seus processos estão definidos e funcionando, e transição seletiva de dados quando os processos de algumas áreas precisam ser redefinidos.

Decide

Qual caminho de ECC para S/4HANA combina com a sua situação?

→Greenfield

Migração a partir de outros sistemas, ou é preciso definir novos processos

→Brownfield

Os processos estão definidos e funcionando

→Transição seletiva de dados

Só algumas áreas precisam redefinir seus processos

Greenfield: uma nova implementação

Uma nova implementação do S/4HANA. Nenhuma configuração legada é levada adiante, os processos são desenhados com base no padrão da SAP e só os dados de que você precisa são carregados.

É a escolha natural se parte da sua empresa roda hoje em sistemas não SAP. Já vi empresas se arrependerem de não preparar seus usuários para o quanto tudo parece diferente em um sistema greenfield. Se o planejamento da adoção começa no treinamento, já está atrasado.

Brownfield: conversão de sistema

Brownfield é uma conversão de sistema. O seu sistema ECC existente é convertido no próprio lugar, e configuração, código customizado e histórico vêm junto. A conversão técnica é feita com o Software Update Manager (SUM) e sua opção de migração de banco de dados.

A SAP publica um Conversion Guide para SAP S/4HANA para cada release, com os pré-requisitos e a ordem das etapas técnicas. Leia o guia do seu release de destino antes de planejar datas. O risco é a dívida técnica que você carrega, porque a complexidade legada vai junto, a menos que você a limpe deliberadamente.

Transição seletiva de dados

A transição seletiva de dados move empresas, unidades de negócio ou recortes de tempo escolhidos, não tudo. Exige ferramentas especializadas e um parceiro com experiência nisso. Alguns fornecedores a vendem como "bluefield".

Ela serve a grupos em que finanças funciona bem, mas compras precisa de redesenho, ou em que fusões e cisões deixaram processos muito diferentes lado a lado. Você redesenha as áreas que precisam e mantém o histórico onde ele importa.

Assim os três se comparam nas perguntas que os conselhos costumam fazer:

Caminho	Quando escolher	Prazo típico	Principal risco
Greenfield	Migração a partir de outros sistemas, ou é preciso definir novos processos	18 a 24 meses	Carga de mudança sobre os usuários e histórico deixado para trás
Brownfield	Os processos estão definidos e funcionando	12 a 18 meses	Dívida técnica e código customizado sem uso levados adiante
Transição seletiva de dados	Os processos de algumas áreas precisam ser redefinidos	12 a 18 meses	Dependência de ferramentas e parceiros especializados, e delimitação complexa dos dados

O caminho muda os detalhes, mas a sequência é a mesma. Estas são as cinco etapas que eu planejaria, nesta ordem.

A sequência da migração

1. 01

   Readiness check

   Execute o SAP Readiness Check e confirme os pré-requisitos técnicos.

2. 02

   Escolher e planejar

   Escolha o caminho, defina o escopo e planeje o programa inteiro antes de começar a construção.

3. 03

   Código customizado

   Descubra o que é usado, aposente o resto e adapte o que sobra.

4. 04

   Dados

   Classifique, limpe e arquive antes de mover qualquer coisa.

5. 05

   Testar e fazer o cutover

   Várias rodadas de testes e pelo menos um ensaio completo de cutover.

1. Execute o readiness check

Comece por aqui. Sempre. O SAP Readiness Check analisa o seu sistema ECC e informa simplification items, compatibilidade de add-ons, código customizado, volumes de dados e dimensionamento.

As surpresas costumam ser os add-ons e o código customizado. Alguns clientes com quem trabalhei tinham centenas de objetos customizados no escopo. Melhor descobrir isso na segunda semana do que no décimo segundo mês.

Para uma conversão brownfield, verifique ao mesmo tempo estes pré-requisitos:

1. Release: a conversão funciona a partir do SAP ERP 6.0 em qualquer enhancement package.
2. Unicode: o sistema precisa ser Unicode, ou você planeja uma conversão em duas etapas.
3. Dual-stack: sistemas dual-stack precisam ser separados primeiro.
4. Business partner: os dados mestre de clientes e fornecedores precisam ser convertidos em business partners antes da conversão. É este o ponto que pega mais equipes do que qualquer outro.

2. Escolha o caminho e planeje o programa

Use os resultados do readiness check e a minha regra acima para escolher o caminho. Depois planeje o programa inteiro, incluindo dados, testes e cutover, antes de alguém começar a construir.

Nos 21 programas SAP que liderei ou resgatei, o maior erro de migração que vejo é não planejá-la direito no início da implementação. Decida nas primeiras semanas quem é dono da limpeza de dados, qual código customizado será aposentado e quando acontecem os ensaios de cutover. Essas decisões saem caras quando tomadas tarde.

3. Adapte o código customizado

Execute as verificações de S/4HANA no ABAP Test Cockpit, que comparam o seu código com os simplification items da SAP. O Custom Code Migration app mostra os mesmos resultados com dados de uso, para você ver o que é usado antes de corrigir qualquer coisa.

O objetivo é ter menos código Z, não apenas código Z que funciona. Em um programa, a análise com smartShift nos levou de 18.000 objetos customizados para 3.200.

Cada objeto customizado que você carrega adiciona custo a todo upgrade futuro. Já vi empresas reduzirem em 40% o prazo de upgrades com princípios de clean core, e o meu guia de SAP clean core explica como classificar o que sobra.

4. Prepare e mova os dados

Classifique, limpe e arquive antes de mover qualquer coisa. Esta etapa leva mais tempo do que qualquer plano prevê, por isso tem uma seção própria abaixo.

5. Teste, treine e faça o cutover

Faça os testes em rodadas: unitários, de integração e de aceitação do usuário (UAT), e depois pelo menos um ensaio completo de cutover. Coloque no UAT tanto key users quanto usuários ocasionais, porque eles encontram problemas diferentes.

O ensaio não é opcional. Ele expõe lacunas de tempo, validações ausentes e falhas de interface que só aparecem quando a sequência inteira roda. Equipes que o pulam encontram esses problemas no fim de semana do go-live.

Na minha experiência, a migração de dados consome de 30 a 40% do esforço de implementação. É também o motivo mais comum de atraso nos cronogramas.

Como os dados se movem depende do caminho. No brownfield, o SUM converte os dados no próprio lugar. No greenfield, você carrega dados mestre e partidas em aberto com o SAP S/4HANA Migration Cockpit, e na transição seletiva de dados ferramentas especializadas movem o escopo que você escolheu.

Seja qual for o caminho, organize os dados antes de movê-los:

1. Quentes: usados com frequência, necessários para o processamento em produção.
2. Mornos: acesso ocasional, relevantes, mas não diários.
3. Frios: históricos ou sem uso, mantidos apenas para auditoria.

Dados frios não precisam ir para o S/4HANA. Arquive-os. Fornecedores duplicados, unidades de medida inconsistentes e cadastros de clientes preenchidos pela metade existem em todo sistema ECC, e chegam intactos ao S/4HANA se ninguém os corrigir antes.

Um cliente com quem trabalhei passou cinco meses só na limpeza e no arquivamento de dados. Meu artigo sobre por que a migração de dados SAP falha aprofunda esta etapa.

Estas são as cinco ferramentas que usei em programas de ECC para S/4HANA. Duas são da própria SAP e três vêm de fornecedores especializados:

Ferramenta	Quem faz	O que faz	Onde se encaixa
SAP Readiness Check for SAP S/4HANA	SAP	Informa simplification items, compatibilidade de add-ons, impacto no código customizado, volumes de dados e dimensionamento	Antes de escolher o caminho
Custom Code Migration app	SAP	App SAP Fiori que executa as verificações de S/4HANA do ABAP Test Cockpit e usa dados de uso para encontrar código sem uso; roda no S/4HANA ou no ambiente ABAP do SAP BTP	Delimitação e adaptação do código customizado
smartShift	smartShift Technologies	Análise e transformação automatizadas de código ABAP customizado para S/4HANA	Análise e correção do código customizado
SNP (plataforma Kyano)	SNP Group	Software de transformação de dados para transição seletiva de dados, vendido sob a abordagem "Bluefield" da SNP	Transição seletiva de dados, fusões e cisões
Natuvion	Natuvion Group	Software de conversão de dados e ferramentas de cutover para transições para S/4HANA	Transição seletiva de dados e cutover

SNP e Natuvion são membros fundadores da comunidade Selective Data Transition Engagement da SAP. As outras ferramentas SAP que você vai encontrar são o SUM, para a conversão brownfield, e o Migration Cockpit, para as cargas de dados no greenfield.

Uma ferramenta não substitui as decisões. Alguém do seu lado ainda precisa concordar sobre o que aposentar.

Para o SAP ERP 6.0 nos enhancement packages 6 a 8, a manutenção principal termina em 31 de dezembro de 2027. A manutenção estendida opcional vai de 2028 até 31 de dezembro de 2030, com um acréscimo de dois pontos percentuais sobre a sua base de manutenção atual (SAP News).

Depois de 2030 existe uma única rota estreita, a SAP ERP, private edition, transition option. Ela oferece manutenção de 2031 a 2033 para clientes que levam o seu sistema ECC para a nuvem privada da SAP como SAP ERP, private edition, sobre SAP HANA, no RISE with SAP. O sistema precisa ser movido antes de 31 de dezembro de 2030, ter pelo menos 2 TB e exige o plano max success da SAP.

Então 2033 não é um prazo geral. Vale para sistemas grandes que já levaram o ECC para a nuvem da SAP. Para todos os outros, o ECC na sua própria infraestrutura tem 2027 como data da manutenção principal e 2030 como fim da manutenção estendida.

1. 2027Fim da manutenção principal do ECC31 de dezembro, para SAP ERP 6.0 EHP 6 a 8
2. 2028Go-live provável se você começar agoraBrownfield de 12 a 18 meses, greenfield de 18 a 24
3. 2030Fim da manutenção estendidaOpcional, com acréscimo de dois pontos
4. 2033Fim da transition optionSomente SAP ERP, private edition, sistemas de 2 TB ou mais

Fonte: SAP News, fevereiro de 2020 e agosto de 2025

A conta é simples. Orce pelo menos alguma manutenção estendida e use o tempo para limpar dados e aposentar código customizado, não para esperar.

O custo segue os mesmos fatores que o prazo: o caminho, o volume de código customizado, o estado dos seus dados e quantas entidades entram em go-live. Só os dados consomem de 30 a 40% do esforço, e é por isso que um bom plano de dados economiza mais dinheiro do que qualquer negociação de tarifas. Meu guia de custo de migração S/4HANA mostra o que define o orçamento de uma migração, e meu guia de custos de implementação SAP detalha o orçamento por porte de empresa.

Para ver como um programa se desenrolou, leia o meu estudo de caso de migração de ECC para S/4HANA. Para testar as suas próprias opções, faça a avaliação de migração greenfield vs brownfield.

Este artigo é a visão geral. Cada guia abaixo responde a uma pergunta por completo.

1. Cronograma de migração S/4HANA e plano de projeto: fase a fase, por caminho, com conversões simuladas e cutover.
2. Custo da migração S/4HANA: o que define o orçamento de uma conversão, de uma nova implementação ou de uma transição seletiva.
3. SAP Readiness Check e avaliação de migração: o que o check mostra e o que ele não vê.
4. SAP S/4HANA Migration Cockpit, passo a passo: carregar dados com staging tables ou transferência direta.
5. RISE with SAP: nuvem pública ou privada: qual edição se encaixa nos seus processos.
6. Contrato e preços do RISE with SAP: o que a assinatura cobre e o que negociar.
7. Como escolher um parceiro de migração S/4HANA: as perguntas a fazer e os sinais de alerta.
8. Recuperação de projetos SAP: como resgatar uma migração que saiu do rumo.

Duas ferramentas ajudam com os números: a calculadora de custo de implementação SAP e o estimador de migração de dados.

O que é o SAP ECC?

O SAP ECC (SAP ERP Central Component) é o núcleo do SAP ERP 6.0, parte do SAP Business Suite 7. Ele cobre finanças, controladoria, logística e outros processos centrais e roda em vários bancos de dados. O SAP S/4HANA é o seu sucessor e roda somente sobre SAP HANA.

Quanto tempo leva uma migração de ECC para S/4HANA?

Na minha experiência, uma conversão brownfield leva de 12 a 18 meses, uma implementação greenfield de 18 a 24 meses e uma transição seletiva de dados de 12 a 18 meses. A limpeza de dados é o motivo mais comum de atraso nos cronogramas, porque a migração de dados consome de 30 a 40% do esforço de implementação.

O que acontece com o SAP ECC depois de 2027?

Para o SAP ERP 6.0 nos enhancement packages 6 a 8, a manutenção principal termina em 31 de dezembro de 2027. Você pode contratar manutenção estendida opcional até 31 de dezembro de 2030, com dois pontos percentuais adicionais. De 2031 a 2033, a manutenção só está disponível pela SAP ERP, private edition, transition option, para sistemas grandes levados à nuvem privada da SAP antes do fim de 2030.

Brownfield ou greenfield: qual é melhor?

Nenhum é melhor em termos gerais. Escolha greenfield quando estiver migrando de outros sistemas ou quando for preciso definir novos processos, e brownfield quando os seus processos estiverem definidos e funcionando. Se só algumas áreas precisam de redesenho, considere a transição seletiva de dados.

O que é a transição seletiva de dados no SAP?

A transição seletiva de dados move para o S/4HANA empresas, unidades de negócio ou recortes de tempo escolhidos, em vez de converter tudo ou começar do zero. Ela permite redesenhar algumas áreas mantendo o histórico em outras. Exige ferramentas especializadas, como as da SNP ou da Natuvion, e um parceiro experiente.

Quais são os pré-requisitos para converter o ECC 6.0 para S/4HANA?

A conversão funciona a partir do SAP ERP 6.0 em qualquer enhancement package. O sistema precisa ser Unicode, ou você usa uma abordagem em duas etapas, e sistemas dual-stack precisam ser separados primeiro. Os dados mestre de clientes e fornecedores precisam ser convertidos em business partners antes da conversão.

O que o SAP Readiness Check mostra?

Ele analisa o seu sistema ECC e informa os simplification items que afetam você, a compatibilidade de add-ons, o impacto no código customizado, os volumes de dados e o dimensionamento do HANA. Execute-o cedo, porque as equipes encontram com frequência add-ons e código customizado dos quais nem sabiam que dependiam.

Devo escolher RISE with SAP ou GROW with SAP para uma migração de ECC?

A maioria dos clientes ECC com muito código customizado e processos complexos vai para o S/4HANA Cloud Private Edition no RISE with SAP, que suporta a conversão do sistema existente. O GROW with SAP usa a Public Edition, que é uma nova implementação com processos padrão e apenas extensões por APIs liberadas. Serve a empresas dispostas a adotar o padrão da SAP.