
Índice
O Clean Core decide se uma atualização do S/4HANA leva seis semanas ou seis meses. Se o seu sistema está cheio de modificações em objetos padrão da SAP, cada release vira um projeto de regressão. Se a sua lógica customizada fica atrás de interfaces liberadas, as atualizações viram manutenção de rotina.
Já vi empresas reduzirem em 40% o prazo das atualizações aplicando os princípios de Clean Core antes de o programa de S/4HANA começar. Uma empresa de bens de consumo substituiu a lógica antiga de preços por um app Fiori modular, construído fora do core, e as atualizações deixaram de quebrar essa lógica.
Muita coisa mudou desde que escrevi este texto pela primeira vez, em abril de 2025. A SAP agora descreve o Clean Core por meio de cinco princípios orientadores e, desde agosto de 2025, classifica cada extensão em um de quatro níveis. Os prazos do ECC também ficaram mais claros. Esta versão reflete isso.
Clean Core significa manter o seu sistema S/4HANA o mais próximo possível do padrão SAP que o seu negócio permitir, e construir qualquer coisa extra de um jeito que sobreviva às atualizações.
Você ainda pode customizar. A customização precisa usar interfaces que a SAP liberou e prometeu manter estáveis. A SAP oferece duas formas de fazer isso:
- On-stack, com ABAP Cloud. As extensões rodam dentro do S/4HANA, mas usam apenas APIs e pontos de extensão liberados.
- Side-by-side, no SAP BTP. As extensões rodam como aplicações separadas e se comunicam com o S/4HANA por APIs ou eventos.
A orientação da própria SAP é escolher caso a caso, com o BTP em primeiro lugar. Na minha experiência, onde o código roda importa menos do que saber se o requisito precisa de código.
Um core sujo parece familiar para quem operou ECC: programas padrão modificados, tabelas Z gravadas diretamente, interfaces que leem estruturas internas da SAP, enhancements implícitos que ninguém documentou. Nada disso estava errado quando foi construído. Só não foi construído para um sistema que é atualizado todo ano ou a cada dois anos.
A SAP organiza o Clean Core em cinco princípios orientadores. A versão anterior deste artigo listava títulos diferentes. Estes são os que a SAP usa, com o que eu olho primeiro em cada um:
| Princípio | O que a SAP quer dizer | O que verifico primeiro |
|---|---|---|
| Processos | Ficar o mais próximo possível do processo padrão da SAP | Quais variantes de processo existem só porque “sempre fizemos assim” |
| Extensibilidade | Extensões desacopladas do core por meio de APIs liberadas, com governança sobre qual opção é usada | Quanto código customizado existe, quanto é usado e em que nível ele está |
| Dados | Dados limpos e em conformidade, com um modelo de governança estabelecido | Dados mestre duplicados e incompletos, campos customizados que ninguém sabe explicar |
| Integrações | Conexões padronizadas e seguras, construídas sobre tecnologias suportadas | Interfaces ponto a ponto que leem tabelas diretamente |
| Operações | Governança, pessoas, processos e ferramentas que mantêm os outros quatro no lugar | Quem aprova uma extensão e o que impede a próxima modificação |
A maioria das equipes começa e termina pela extensibilidade, porque é a mais fácil de medir. Na minha experiência, processos e dados causam mais atraso. O código customizado costuma ser o sintoma. O processo por trás dele é a causa.
Em agosto de 2025, a SAP substituiu o modelo anterior de extensibilidade em três camadas pelo conceito de níveis de Clean Core. Cada extensão é avaliada pela forma como é construída, pelo grau de desacoplamento do core e pela facilidade de atualização.
| Nível | Descrição da SAP | O que significa para a sua atualização |
|---|---|---|
| A | Estender com o SAP Build. Somente interfaces estáveis e publicamente liberadas, on-stack com ABAP Cloud ou side-by-side no BTP | Menor risco. A SAP respalda essas interfaces com contratos de estabilidade |
| B | Usa também as APIs e tecnologias clássicas da SAP | Em geral estável nas atualizações, mas fora do modelo de desenvolvimento em nuvem |
| C | Acessa objetos internos da SAP | Parcialmente em conformidade. Cada atualização exige verificação; a SAP planeja um changelog para objetos internos |
| D | Não recomendado: modificações, gravações em tabelas SAP, enhancements implícitos, objetos explicitamente não recomendados | A dívida técnica a remover primeiro |
Isso é mais útil do que o velho debate entre “limpo ou não limpo”. Permite definir uma meta por objeto. Nem tudo precisa chegar ao nível A. Levar seus objetos de nível D para B ou C antes de uma atualização já é uma redução real de risco.
Fonte: Conceito de níveis de Clean Core da SAP, SAP News, agosto de 2025
Se você me pedisse para avaliar o seu sistema no mês que vem, esta é a ordem que eu seguiria.
- Descubra o que é usado. Execute o SAP Readiness Check, que vem com o seu contrato de manutenção, e colete dados de uso do seu código customizado. Em um programa, a análise com o smartShift nos levou de 18.000 objetos customizados para 3.200. A maior parte do restante simplesmente não era usada.
- Classifique o que sobrou nos níveis A a D. O ABAP test cockpit é a ferramenta da SAP para verificações no nível do código. No RISE, o painel RISE with SAP Methodology informa a adoção de Clean Core.
- Decida objeto por objeto. Aposente-o, leve-o para uma interface liberada, reconstrua-o no BTP ou mantenha-o com um motivo documentado. Comece pelo código que roda todo dia. Um relatório usado duas vezes por ano por uma equipe regional pode esperar.
- Coloque o negócio na sala. Um responsável pela área de finanças com quem trabalhei só entendeu o novo app Fiori depois de uma demonstração de 45 minutos. Essa sessão economizou duas semanas de idas e vindas no UAT.
- Questione o “nosso processo é diferente”. Em um workshop com uma equipe de vendas, o processo “único” se revelou 80% de tarefas administrativas legadas e redundantes. O SAP padrão melhorou a experiência dos clientes assim que os workarounds saíram.
- Comece cedo o trabalho com os dados. Um cliente de varejo tinha mais de 15.000 campos customizados para analisar. Na minha experiência, a migração de dados consome de 30 a 40% do esforço de implementação, e é a parte que a maioria dos planos subestima. Explico o porquê em por que a migração de dados SAP falha.
- Defina a governança antes do go-live. Uma design authority deve revisar cada nova extensão. A pergunta padrão costumava ser “por que isso não pode ficar no BTP?”. Hoje eu perguntaria “por que isso não pode ser nível A e, se não pode, que nível estamos aceitando e por quê?”
Habilidades importam tanto quanto ferramentas. Uma equipe de ABAP que não trabalhou com ABAP Cloud ou BTP vai atrasar o programa enquanto aprende. Um fabricante com quem trabalhei fez um programa interno de BTP de três meses antes de o projeto de S/4HANA começar, e isso compensou em menos surpresas durante a construção.
As equipes que pulam o Clean Core não evitam o trabalho. Elas o adiam, e ele volta na forma de atualizações bloqueadas e código customizado que ninguém entende.
Três perguntas aparecem em quase toda conversa que tenho sobre esse assunto.
O Clean Core é obrigatório no RISE with SAP? Não como regra geral. No S/4HANA Cloud Public Edition você só pode estender por meio de interfaces liberadas, então o próprio sistema impõe a regra. No Private Edition e no on-premise você ainda pode modificar o core. Ali, o Clean Core é uma escolha de governança, e a SAP o acompanha pelo painel da metodologia RISE. Se um integrador disser que é contratual, peça que mostre a cláusula.
Quanto tempo tenho no ECC? Para o SAP ERP 6.0 nos pacotes de melhoria 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 custo adicional, e a SAP pede que os clientes a contratem até o terceiro trimestre de 2027. Os pacotes de melhoria anteriores saíram da manutenção padrão no fim de 2025. Depois de 2030, a opção de transição do SAP ERP, private edition cobre de 2031 a 2033. Ela se aplica apenas a sistemas grandes que já tenham migrado para o SAP ERP, private edition, no SAP HANA antes do fim de 2030, e somente com o plano max success da SAP. Trate 2033 como uma rota de exceção, não como uma data de planejamento. Meu guia de migração de ECC para S/4HANA trata das opções de rota.
O Clean Core importa para a IA? A SAP constrói seus recursos de IA, incluindo o Joule, sobre os seus processos padrão e o seu modelo de dados. O Joule for developers gera código ABAP Cloud com base em APIs liberadas. Minha visão de trabalho é simples: quanto mais próximos do padrão estiverem os seus processos e dados, menos adaptação você precisa antes de esses recursos serem úteis para você. Processos muito modificados são onde os recursos de IA são mais difíceis de adotar.
As equipes que pulam o Clean Core não evitam o trabalho. Elas o adiam, e ele volta na forma de atualizações bloqueadas, maratonas de testes de regressão e código customizado que ninguém entende.
Se você está prestes a assinar um contrato de S/4HANA ou de RISE, peça ao seu integrador uma classificação do seu código customizado atual nos níveis A a D antes de combinar o escopo. Se ele não conseguir produzi-la, isso diz algo sobre a estimativa. Você pode testar as suas opções de migração com a minha avaliação de migração de ECC para S/4HANA ou agendar uma conversa para analisarmos a sua situação.
O que é o Clean Core da SAP?
Clean Core significa manter o S/4HANA próximo do padrão da SAP e criar extensões apenas por meio de interfaces que a SAP liberou e se comprometeu a manter estáveis. As extensões rodam on-stack com ABAP Cloud ou side-by-side no SAP BTP. O objetivo é que as atualizações não quebrem a sua lógica customizada.
Quais são as cinco dimensões do Clean Core da SAP?
A SAP as chama de cinco princípios orientadores do Clean Core: processos, extensibilidade, dados, integrações e operações. Os processos ficam próximos do padrão. As extensões usam APIs liberadas. Os dados são mantidos limpos sob um modelo de governança. As integrações usam tecnologias padronizadas e suportadas. Operações abrange a governança, as pessoas e as ferramentas que mantêm os outros quatro no lugar.
O que são os níveis A, B, C e D do Clean Core da SAP?
Desde agosto de 2025, a SAP classifica as extensões em quatro níveis. O nível A usa apenas interfaces estáveis e publicamente liberadas. O nível B usa também as APIs clássicas da SAP. O nível C acessa objetos internos da SAP e exige verificação a cada atualização. O nível D abrange modificações, gravações em tabelas SAP, enhancements implícitos e outras técnicas não recomendadas, e representa o maior risco.
O Clean Core é obrigatório com o RISE with SAP?
Não como regra geral. O S/4HANA Cloud Public Edition só permite extensões por meio de interfaces liberadas, então impõe o Clean Core tecnicamente. No Private Edition você ainda pode modificar o core, portanto o Clean Core é uma decisão de governança. A SAP informa a adoção de Clean Core pelo painel RISE with SAP Methodology.
Quando termina o suporte ao SAP ECC?
Para o SAP ERP 6.0 nos pacotes de melhoria 6 a 8, a manutenção padrão termina em 31 de dezembro de 2027, com manutenção estendida opcional até 31 de dezembro de 2030, com custo adicional. Os pacotes de melhoria anteriores saíram da manutenção padrão no fim de 2025. A opção de transição do SAP ERP, private edition, se estende até 2033 apenas para sistemas grandes elegíveis que tenham migrado para o SAP ERP, private edition, no SAP HANA antes do fim de 2030.
Como avalio a prontidão do meu sistema SAP para o Clean Core?
Comece pelo SAP Readiness Check e pelos dados de uso do seu código customizado. Classifique o que ainda é usado nos níveis A a D, usando o ABAP test cockpit para as verificações no nível do código. Depois decida, objeto por objeto, se vai aposentá-lo, levá-lo para uma interface liberada, reconstruí-lo no SAP BTP ou mantê-lo com um motivo documentado. Revise processos e dados ao mesmo tempo, porque eles costumam explicar por que o código existe.
Qual é o papel do SAP BTP em uma estratégia de Clean Core?
O SAP BTP é onde rodam as extensões side-by-side. As aplicações no BTP se conectam ao S/4HANA por APIs e eventos, então o core permanece intocado. A SAP recomenda uma abordagem BTP first, com extensões on-stack em ABAP Cloud quando a lógica precisa ficar perto dos dados ou da transação.
Próximo passo
Está conduzindo um programa de ERP agora?
Se este artigo tocou num programa em que você está envolvido agora, uma conversa de 30 minutos costuma render mais do que outra semana de análise interna.




