
Índice
O custo de uma migração S/4HANA fica nas mesmas faixas de qualquer programa SAP. Planeje de US$ 500 mil a US$ 2 milhões em uma empresa mid-market, de US$ 2 milhões a US$ 10 milhões ou mais em uma grande empresa e de US$ 10 milhões a US$ 50 milhões ou mais em um grupo global. Onde você cai dentro da faixa depende menos do caminho do que do custom code, dos dados, das conversões simuladas, da operação dupla e do seu contrato SAP.
Resposta curta: nenhum caminho de migração é mais barato por padrão. O custo de brownfield vs greenfield depende de quanto custom code você carrega, de quão limpos estão os seus dados e de quanto processo você quer mudar. Na minha experiência, custom code é a fase que mais estoura o prazo, e o custo oculto que as empresas mais esquecem.
Este artigo trata especificamente da conta da migração. Os caminhos, as etapas e os prazos do ECC estão no meu guia de migração de ECC para S/4HANA.
Para saber quanto o SAP custa em geral e para onde vai o dinheiro, leia quanto custa uma implementação SAP. Para entender por que os orçamentos estouram quando o trabalho começa, leia por que projetos SAP estouram o orçamento.
Uma migração é um programa SAP completo, então usa as mesmas faixas de trabalho que uso para qualquer programa SAP. Elas cobrem serviços do parceiro, assinatura ou licenças, dados, testes, treinamento e hypercare.
Esta é a posição de cada faixa, e o que empurra uma migração para cima dentro dela:
| Porte da empresa | Custo total do programa (USD) | O que empurra uma migração para cima na faixa |
|---|---|---|
| Pequena (menos de 200 funcionários) | US$ 80 mil a US$ 500 mil | Volume de dados legados, add-ons sem versão para S/4HANA |
| Mid-market (200 a 1.000) | US$ 500 mil a US$ 2 milhões | Volume de custom code, integrações, qualidade dos dados |
| Grande (1.000 a 10.000) | US$ 2 milhões a US$ 10 milhões+ | Custom code, número de conversões simuladas, escopo do teste de regressão |
| Grupo global (10.000+) | US$ 10 milhões a US$ 50 milhões+ | Muitas entidades e países, operação dupla ao longo das ondas de rollout |
Duas proporções valem em todas as faixas. Os serviços do parceiro ficam com 35 a 50 por cento do total, e uma contingência de 10 a 20 por cento vem por cima, mantida por você e não dentro do preço do parceiro.
As referências públicas ficam no mesmo patamar. A LeverX, parceira SAP, estima uma implementação greenfield de grande empresa nos EUA em US$ 4 milhões a US$ 10 milhões+ (guia de custos da LeverX para os EUA, 2026). Para um primeiro número sobre o seu próprio escopo, use a calculadora de custo de implementação SAP.
As pessoas querem um percentual: brownfield custa X por cento menos que greenfield. Minha resposta honesta é que depende, e não dou um percentual. O caminho muda mais para onde vai o dinheiro do que quanto dinheiro é.
Uma conversão de sistema (brownfield) mantém a sua configuração, o seu custom code e o seu histórico. Uma nova implementação (greenfield) começa limpa e carrega só os dados de que você precisa, e uma selective data transition faz um pouco de cada uma com ferramentas especializadas.
É aqui que cada caminho gasta o dinheiro:
| Caminho | Para onde vai o dinheiro | O que o encarece | O que o mantém baixo |
|---|---|---|---|
| Brownfield (conversão de sistema) | Correção do custom code, execuções de conversão com o Software Update Manager, teste de regressão de tudo o que foi mantido | Uma grande base de custom code que ninguém usa, add-ons a substituir, uma janela de downtime curta em um banco de dados grande | Aposentar o código não usado antes da conversão, processos que já funcionam |
| Greenfield (nova implementação) | Desenho de processos, configuração, extensões, cargas de dados, treinamento e gestão de mudanças | Reconstruir relatórios e lógicas customizadas antigas no novo sistema, redesenhar áreas que funcionavam | Adotar o padrão SAP, carregar partidas em aberto e só o histórico necessário |
| Selective data transition | Ferramentas e parceiro especializados, escopo dos dados, além de algum redesenho e alguma conversão | Seleção complexa de empresas e de histórico, fusões e carve-outs | Uma decisão firme sobre quais áreas serão redesenhadas |
Então, depende do quê? Estas quatro perguntas decidem:
- Quanto custom code você carrega, e quanto dele é usado. Em uma conversão, cada objeto mantido precisa ser verificado, corrigido quando necessário e testado.
- Quão limpos estão os seus dados e quanto histórico você precisa. Dados ruins custam dinheiro em todos os caminhos, em um lugar diferente em cada um.
- Quanto processo você quer mudar. Minha regra: greenfield quando você vem de outros sistemas ou novos processos precisam ser definidos, brownfield quando os processos estão definidos e funcionando, selective quando algumas áreas precisam de redesenho. Pagar para redesenhar processos que já funcionam é a escolha cara.
- Quanto downtime o negócio aguenta. Sistemas grandes com janelas curtas precisam de técnicas downtime-optimized e dos especialistas que as executam.
O custo também acompanha o tempo. Na minha experiência, brownfield leva de 12 a 18 meses, greenfield de 18 a 24 meses e selective data transition de 12 a 18 meses. Meu cronograma de migração S/4HANA e plano de projeto detalha isso fase a fase.
Custom code é a fase que mais vejo estourar em uma migração. É também o custo que as empresas mais esquecem quando definem o orçamento.
Ele se esconde porque parece uma tarefa técnica. Em uma conversão brownfield, os seus programas Z, enhancements e modificações vêm junto, e cada um que toca um modelo de dados alterado precisa ser adaptado e testado de novo.
O SAP Readiness Check é o lugar certo para começar, mas é uma ferramenta de planejamento. Na minha experiência, o que ele deixa passar nos objetos customizados é o que causa problema depois.
O próprio Conversion Guide for SAP S/4HANA Cloud Private Edition 2025 da SAP manda você ao ABAP Test Cockpit para as verificações de custom code. Ele também recomenda remover o custom code que não é mais usado antes de converter.
É nessa recomendação que está a economia. Em um programa, a análise com smartShift nos levou de 18.000 objetos customizados para 3.200, e cada objeto aposentado era um que ninguém precisou corrigir, testar ou carregar para os upgrades futuros.
Antes que alguém precifique uma migração, eu ia querer respostas para isto:
- Quantos objetos customizados existem? Conte a partir do seu próprio sistema, não da estimativa do parceiro.
- Quantos são realmente usados? Dados de uso da produção, ao longo de um ciclo de negócio completo, incluindo o fechamento anual.
- Quais serão aposentados, e quem decide? Uma design authority de negócio e TI, não só os desenvolvedores.
- O que substitui os que você mantém? Funções padrão, APIs liberadas ou extensões side-by-side, em linha com um Clean Core.
Mantenha as customizações no mínimo e governe o restante. O erro comum que vejo é tentar fazer o SAP funcionar como o Oracle, o que transforma cada diferença em código. Meu guia de Clean Core SAP explica como classificar o que sobra.
Na minha experiência, a migração de dados consome de 30 a 40 por cento do esforço. Boa parte desse esforço fica com os seus próprios usuários de negócio, limpando e validando, então ela raramente aparece na proposta de um parceiro.
Em uma conversão brownfield, planejo três conversões simuladas antes do cutover. Cada uma custa dinheiro de verdade: uma cópia do sistema, a equipe técnica executando a conversão, verificações funcionais e a reconciliação dos resultados pela área de negócio.
Verifique o que o seu contrato já cobre. O guia de conversão da SAP para a Private Edition diz que o escopo contratual padrão inclui dois dry runs, um para sistemas não produtivos e um para produção. Mais execuções podem ser adicionadas como serviço faturável.
Se você planeja três, combine de antemão quem paga a terceira.
O downtime é o outro custo desta fase. O downtime de cutover que já vi vai de um fim de semana a uma semana, e o negócio paga por cada dia em que não consegue expedir, faturar ou fechar.
Dá para encurtá-lo. O Software Update Manager oferece uma conversão downtime-optimized, mas o guia da SAP diz que a versão para a Private Edition exige um especialista SAP que tenha concluído o curso ADM329. Isso é uma linha de especialista no orçamento, não um botão gratuito.
Os testes fecham o ciclo. Uma conversão mantém tudo, então o teste de regressão precisa cobrir tudo o que foi mantido, e esse escopo cresce a cada objeto customizado que você não aposentou.
Não é o rótulo do caminho que define a conta da migração. É o custom code que você carrega e os dados que você move.
Dois custos ficam fora do plano de projeto, e os dois caem na mesa do CFO.
O primeiro é a operação dupla. 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 até o fim de 2030 custa dois pontos percentuais a mais (SAP News).
Um programa greenfield iniciado hoje vai até 2028, então o ECC continua rodando, e custando, enquanto você constrói. Orce pelo menos alguma manutenção estendida, a equipe de suporte do ECC e as interfaces que precisam alimentar os dois sistemas durante um rollout em fases.
O segundo é a conversão do contrato. Ir para RISE with SAP significa S/4HANA Cloud Private Edition, que a SAP agora comercializa como SAP Cloud ERP Private. A sua posição de licenças e manutenção vira uma assinatura, e os termos são negociados, não publicados.
As maiores armadilhas que vejo em um contrato RISE são os termos de renovação, o dimensionamento por full user equivalent (FUE) e os créditos de IA. O que sempre negocio para dentro é a lista de módulos incluídos e o preço por fase, para que você pague conforme as fases entram em produção, e não desde o primeiro dia.
Pergunte à SAP, por escrito, o que acontece com as suas licenças e pagamentos de manutenção atuais. Meu guia sobre contrato e preços do RISE with SAP mostra o que está dentro, o que está fora e onde pressionar.
Nos 21 programas SAP que liderei ou resgatei, o maior erro que vejo é não planejar direito no início. Os orçamentos sofrem na fase Explore, conforme a lista WRICEF (relatórios, interfaces, conversões, enhancements, formulários, workflows) cresce, e deixar os fornecedores controlarem o escopo é uma causa raiz.
Esta é a ordem que eu seguiria:
- Rode o SAP Readiness Check e as verificações de custom code antes de pedir preço a alguém.
- Decida qual custom code será aposentado por meio de uma design authority de negócio e TI.
- Faça o perfil dos dados e dimensione o esforço de dados em 30 a 40 por cento do programa.
- Conte as conversões simuladas e os dry runs, e combine quem paga cada um.
- Precifique a operação dupla, incluindo a manutenção estendida se o go-live cair depois de 2027.
- Escreva o escopo você mesmo, para que o parceiro precifique o seu escopo e não o dele.
- Adicione de 10 a 20 por cento de contingência, mantida do seu lado.
Depois, vá aos parceiros. Peça referências e o desenho de alto nível da sua migração, e descarte respostas genéricas que serviriam para qualquer empresa. Meu guia sobre como escolher um parceiro de migração S/4HANA cobre o resto dessa conversa.
O próximo passo concreto: extraia este mês a contagem de objetos customizados e os dados de uso do seu próprio sistema produtivo. É o número que mais mexe em um orçamento de migração, e você pode tê-lo antes de qualquer parceiro entrar na sala.
Se você quer uma visão independente sobre um orçamento de migração ou uma proposta de parceiro, ajudo organizações com isso. Você pode falar comigo aqui.
Quanto custa uma migração para S/4HANA?
As faixas de trabalho que uso são de US$ 80.000 a US$ 500.000 para uma empresa pequena e de US$ 500.000 a US$ 2 milhões no mid-market. Uma grande empresa deve planejar de US$ 2 milhões a US$ 10 milhões ou mais, e um grupo global de US$ 10 milhões a US$ 50 milhões ou mais. Os serviços do parceiro ficam com 35 a 50 por cento do total, e o custom code, os dados e o número de conversões simuladas decidem onde você cai na faixa.
Brownfield é mais barato que greenfield no S/4HANA?
Não por padrão. Depende de quanto custom code você carrega, de quão limpos estão os seus dados, de quanto processo você quer redesenhar e de quanto downtime você aguenta. Uma conversão brownfield com uma grande base de custom code não usado pode custar mais que uma implementação greenfield que adota o padrão SAP.
Qual é o maior custo oculto em uma migração para S/4HANA?
Custom code. Na minha experiência, é o custo que as empresas mais esquecem e a fase que mais estoura o prazo. Conte os seus objetos customizados e verifique quais são usados antes que alguém precifique a migração.
Quantas conversões simuladas uma conversão para S/4HANA exige?
Em uma conversão brownfield, planejo três conversões simuladas antes do cutover. O guia de conversão da SAP para a Private Edition inclui dois dry runs no escopo contratual padrão, um para não produção e um para produção, com mais execuções disponíveis como serviço faturável. Combine quem paga qualquer execução extra antes de assinar.
Quanta contingência devo incluir no orçamento de uma migração para S/4HANA?
Mantenha de 10 a 20 por cento acima do orçamento, do seu lado e não dentro do preço do parceiro. Libere-a contra riscos nomeados, como problemas de custom code ou de dados encontrados nos testes, e não para cobrir escopo que nunca foi precificado.
O RISE with SAP deixa a migração para S/4HANA mais barata?
Ele muda mais a forma do custo do que o tamanho. Licenças, hospedagem e operação técnica passam para uma assinatura, mas custom code, dados, testes e gestão de mudanças continuam no orçamento do seu programa. Fique atento aos termos de renovação, ao dimensionamento por FUE e aos créditos de IA, e negocie os módulos incluídos e o preço por fase.
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.




