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

A manutenção padrão do SAP ECC termina em 31 de dezembro de 2027, daqui a cerca de 15 meses. A manutenção estendida opcional vai até o fim de 2030, por uma taxa maior (SAP News). Migrações complexas facilmente chegam a 18 a 24 meses quando os testes de verdade começam. Se você ainda não escolheu um caminho, entrar em operação antes do prazo já é improvável.

Se você é o CIO ou o líder do programa que precisa tomar essa decisão, tem três caminhos: greenfield, brownfield ou transição seletiva de dados. O trabalho por trás de cada um segue as mesmas cinco etapas. Execute primeiro o SAP Readiness Check e só depois escolha.

A migração de ECC para S/4HANA não é uma atualização simples. Ela muda a forma como os dados são armazenados, como as transações são lançadas e como os usuários trabalham. Num projeto em que atuei, uma equipe mandou reconstruir dezenas de relatórios personalizados 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.

As diferenças que determinam o esforço de migração:

Área	SAP ECC	SAP S/4HANA
Banco de dados	Qualquer banco de dados compatível (Oracle, Db2, SQL Server e 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 de lançamento
Dados mestre de clientes e fornecedores	Registros separados de cliente e de fornecedor	O parceiro de negócios é obrigatório
Interface do usuário	SAP GUI	Aplicativos SAP Fiori, com o SAP GUI ainda disponível no 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	Manutenção padrão do EHP 6 a 8 até o fim de 2027, estendida até o fim de 2030	A SAP se comprometeu com a manutenção até o fim de 2040

Um cliente com quem trabalhei não parava de perguntar por que seus jobs em lote personalizados haviam deixado de funcionar depois da conversão. A lógica dependia de estruturas de tabelas do ECC que o S/4HANA tinha mudado. A migração em si estava concluída. Ninguém tinha perguntado se esses jobs ainda faziam sentido no novo modelo.

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

Decide

Qual caminho de migração combina com a sua situação?

O legado é fragmentado e você quer redesenhar os processos

→Greenfield

Os processos são sólidos, o ECC é estável e o histórico precisa ficar

→Brownfield

Várias entidades, reaproveitamento parcial e dados seletivos

→Bluefield

Greenfield: começar do zero

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

Use quando os sistemas legados forem fragmentados demais para uma conversão limpa, ou quando o negócio quiser repensar os processos em vez de copiá-los.

Fique atento à carga de mudança. Os usuários perdem fluxos de trabalho familiares. Já vi empresas se arrependerem de não preparar seus usuários para o quanto tudo parece diferente num sistema greenfield. Se o planejamento de adoção começa no treinamento, já é tarde.

Brownfield: conversão do sistema

O seu sistema ECC atual é convertido no próprio lugar. Configuração, código personalizado e histórico vão com você. A conversão técnica roda pelo Software Update Manager (SUM), com a opção de migração de banco de dados.

Use quando os processos estiverem maduros, o histórico de transações importar para a conformidade e nenhuma grande reestruturação estiver em andamento.

Fique atento à dívida técnica que você leva junto. A complexidade do legado vai com você, a menos que você a limpe de propósito durante a conversão.

Transição seletiva de dados

Às vezes vendida como “bluefield”. Você move company codes, unidades de negócio ou recortes de tempo escolhidos, e não tudo, em geral com ferramentas especializadas e um parceiro experiente nelas. Serve para grupos formados por fusões ou carve-outs, ou quando anos de histórico já não importam.

Use quando quiser a liberdade de processos de um greenfield com a continuidade de dados de um brownfield onde ela faz diferença.

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

Critérios	Greenfield	Brownfield	Seletiva
Redesenho de processos	Total, com base no padrão SAP	Em grande parte preservado	Escolhido por unidade
Dados históricos	Não são levados adiante (ou só itens em aberto e saldos)	Totalmente levados adiante	Escopo selecionado
Prazo até o go-live	Mais longo	Mais curto	Depende do escopo
Dívida técnica	Eliminada	Levada adiante	Reduzida no escopo migrado
Impacto da mudança	Alto	Menor	Moderado
Mais indicado para	Legado fragmentado, grande redesenho	ECC estável e bem cuidado	Fusões, carve-outs, rollouts em fases

A sequência da migração

1. 01

   Avaliar

   Execute o SAP Readiness Check. Faça o inventário de código personalizado, add-ons e interfaces.

2. 02

   Classificar dados

   Classifique os dados em quentes, mornos e frios. Os dados frios não precisam migrar.

3. 03

   Limpar

   Resolva duplicidades, inconsistências e campos ausentes. Sempre leva mais tempo do que o planejado.

4. 04

   Adaptar código

   Execute as verificações do ABAP Test Cockpit. Reduza o código Z, em vez de apenas portá-lo.

5. 05

   Testar e fazer o cutover

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

1. Avaliação e prontidão

Comece por aqui. Sempre. O SAP Readiness Check analisa o seu sistema ECC e gera relatórios sobre itens de simplificação, compatibilidade de add-ons, código personalizado, volumes de dados e dimensionamento.

As surpresas costumam ser os add-ons e o código personalizado. Alguns clientes com quem trabalhei tinham centenas de objetos personalizados no escopo, e a maioria se surpreende com a quantidade de código inativo que aparece. Melhor descobrir isso na segunda semana do que no décimo segundo mês.

Verifique os pré-requisitos técnicos ao mesmo tempo. A conversão parte do SAP ERP 6.0 em qualquer enhancement package. O sistema precisa ser Unicode, ou você planeja uma conversão em duas etapas. Sistemas dual-stack precisam ser separados antes. Os dados mestre de clientes e fornecedores precisam ser convertidos em parceiros de negócios antes da conversão. Esse último pega mais equipes de surpresa do que qualquer outro.

2. Análise e classificação dos dados

Meça seus dados antes de movê-los e classifique-os:

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

Os dados frios não precisam ir para o S/4HANA. Arquive-os. As equipes que pulam essa etapa levam para o novo sistema um acúmulo de dados desnecessários, que atrasa a migração e prejudica o desempenho.

3. Limpeza e arquivamento de dados

Essa etapa leva mais tempo do que qualquer plano prevê. Cadastros de fornecedores duplicados. Unidades de medida inconsistentes. Dados mestre de clientes preenchidos pela metade. Esses problemas existem em todo sistema ECC e passam intactos para o S/4HANA se ninguém os corrigir antes.

Um cliente com quem trabalhei gastou cinco meses só com a limpeza e o arquivamento de dados. As equipes que pulam a limpeza descobrem os problemas durante o cutover, quando não há tempo para corrigi-los direito. O meu artigo sobre por que a migração de dados SAP falha aprofunda essa etapa.

4. Adaptação do código personalizado

Execute as verificações de prontidão para S/4HANA do ABAP Test Cockpit (ATC), que comparam o seu código com os itens de simplificação da SAP. O resultado mostra o que precisa de correção de sintaxe, o que precisa de substituição funcional e o que deve ser aposentado.

O objetivo é ter menos código Z, não apenas código Z funcionando. Cada objeto personalizado que você leva adiante aumenta o custo de todas as atualizações futuras. O meu guia de Clean Core explica como classificar o que sobra.

5. Testes, treinamento e cutover

Faça os testes em rodadas: unitário, integrado, teste de aceitação do usuário (UAT) e, por fim, pelo menos um ensaio completo de cutover. Coloque no UAT tanto usuários avançados quanto usuários ocasionais. Eles encontram problemas diferentes.

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

As ferramentas SAP que eu esperaria ver em qualquer plano de migração:

Ferramenta	O que faz	Quando usar
SAP Readiness Check	Itens de simplificação, add-ons, código personalizado, dimensionamento	Antes de escolher o caminho
ABAP Test Cockpit (ATC)	Encontra código personalizado que vai quebrar	Adaptação do código personalizado
SAP Signavio	Mostra como os processos realmente funcionam, e não como foram documentados	Antes do congelamento do design
SAP LeanIX	Mapeia aplicações e interfaces	Design da integração
Software Update Manager (SUM)	Executa a conversão técnica	Conversão brownfield
SAP S/4HANA Migration Cockpit	Carrega dados mestre e transacionais	Migração de dados greenfield

Para o SAP ERP 6.0 nos enhancement packages 6 a 8, a manutenção padrão termina em 31 de dezembro de 2027. A manutenção estendida opcional vai até 31 de dezembro de 2030, com um acréscimo de dois pontos percentuais sobre a base de manutenção. Os enhancement packages anteriores saíram da manutenção padrão no fim de 2025.

Depois de 2030, existe uma única rota estreita: a opção de transição do SAP ERP, private edition, da SAP, que cobre 2031 a 2033. Ela vale apenas para sistemas grandes migrados para o SAP ERP, private edition, no SAP HANA antes do fim de 2030, e somente com o plano max success da SAP. Trate-a como exceção, não como plano.

Quanto à duração, migrações completas de sistemas complexos podem chegar a 18 a 24 meses ou mais quando os testes de verdade começam. Para empresas de porte médio a grande, 12 a 18 meses ou mais é um prazo realista para uma conversão bem preparada. Um grande programa greenfield em várias entidades pode levar de 24 a 36 meses.

1. 2027Fim da manutenção padrão do ECC31 de dezembro, para o SAP ERP 6.0 EHP 6 a 8
2. 2028Go-live provável se você começar agora18 a 24 meses depois que os testes de verdade começam
3. 2030Fim da manutenção estendidaOpcional, com acréscimo de dois pontos percentuais
4. 2033Fim da opção de transiçãoPrivate edition, somente sistemas grandes

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

Portanto, a conta é simples. Se você começar hoje uma avaliação complexa, o go-live cai em 2028. Reserve orçamento para a manutenção estendida e use o tempo para limpar dados e aposentar código personalizado, em vez de esperar. Para testar as suas opções, experimente a minha avaliação de migração.

Qual é a diferença entre a migração greenfield e a brownfield de ECC para S/4HANA?

O greenfield é uma nova implementação: nenhuma configuração legada nem código personalizado é levado adiante, os processos são desenhados com base no padrão da SAP e só os dados de que você precisa são carregados. O brownfield converte o seu sistema ECC atual, mantendo configuração, código personalizado e histórico. É mais rápido e menos disruptivo, mas a dívida técnica vai junto. A transição seletiva de dados fica entre os dois.

Qual é o prazo da migração do SAP ECC para o S/4HANA?

Para o SAP ERP 6.0 nos enhancement packages 6 a 8, a manutenção padrão termina em 31 de dezembro de 2027. A manutenção estendida opcional vai até 31 de dezembro de 2030, com um acréscimo de dois pontos percentuais sobre a base de manutenção. Uma opção de transição para 2031 a 2033 existe apenas para sistemas grandes migrados para o SAP ERP, private edition, no SAP HANA antes do fim de 2030.

O que o SAP Readiness Check informa?

Ele analisa o seu sistema ECC e gera relatórios sobre itens de simplificação que afetam a sua configuração, compatibilidade de add-ons, impacto no código personalizado, volumes de dados e dimensionamento do HANA. Executá-lo cedo muda a discussão sobre o escopo, porque as equipes com frequência descobrem add-ons e código personalizado de que não sabiam depender.

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

Uma conversão bem preparada, para uma empresa de porte médio a grande, costuma levar 12 a 18 meses ou mais. Programas complexos, com várias entidades, podem chegar a 18 a 24 meses quando os testes de verdade começam, e grandes programas greenfield a 24 a 36 meses. A limpeza de dados é o motivo mais comum de atraso no cronograma.

O que é o Universal Journal (ACDOCA) e por que ele importa na migração?

O Universal Journal é a tabela única de itens de lançamento, a ACDOCA, que reúne dados de contabilidade financeira, controladoria e rentabilidade que o ECC mantinha em tabelas separadas. O código personalizado e os relatórios que leem as estruturas antigas, como a COEP ou as tabelas de rentabilidade, precisam ser revisados. Alguns pedem pequenos ajustes; outros pedem redesenho.

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

A conversão parte do SAP ERP 6.0 em qualquer enhancement package. O sistema precisa ser Unicode, ou você usa uma abordagem em duas etapas. Sistemas dual-stack precisam ser separados antes. Os dados mestre de clientes e fornecedores precisam ser convertidos em parceiros de negócios. Execute o SAP Readiness Check e as verificações de código personalizado do ATC antes de se comprometer com datas.

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

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