Migração de SAP ECC para S/4HANA: o guia que sua empresa precisa antes de 2027

Se a sua empresa ainda roda SAP ECC, existe uma data no calendário que já deveria estar na pauta do comitê executivo: 31 de dezembro de 2027. É quando a SAP encerra a manutenção mainstream do Business Suite 7, a família que inclui o ECC 6.0.

Isso não significa que o sistema para de funcionar em 1º de janeiro de 2028. Significa algo mais sutil e mais perigoso: seu ERP deixa de receber correções regulares, ajustes de legislação e notas de segurança dentro do contrato padrão. Em um país onde a legislação fiscal muda várias vezes por ano, um ERP sem atualização legal é um passivo que cresce sozinho.

Existe manutenção estendida paga até 2030. Ela funciona, custa um adicional sobre o contrato de manutenção e resolve o curto prazo. O que ela não resolve é o problema de fundo: enquanto o mercado evolui para uma plataforma, sua empresa fica em outra.

Por que a decisão precisa ser tomada agora

A conta é simples e pouca gente faz. Um projeto de migração para S/4HANA de porte médio leva entre 8 e 18 meses, dependendo da rota. Antes disso, há um período de assessment, aprovação orçamentária e contratação que dificilmente sai em menos de três meses.

Some: uma empresa que iniciar a discussão hoje entra em produção com folga. Uma empresa que começar a discutir em 2027 vai contratar consultoria no pico da demanda, disputando os mesmos consultores que todo o mercado estará disputando, e pagando o preço dessa disputa.

Existe ainda um efeito que se repete a cada ciclo de fim de suporte de plataforma: os melhores profissionais são alocados primeiro. Quem entra atrasado não escolhe o time, escolhe quem sobrou.

As três rotas de migração

Não existe uma resposta universal. A rota certa depende de quão bem os seus processos atuais funcionam e de quanto passivo técnico você acumulou.

Greenfield: recomeçar do zero

Você implementa um S/4HANA novo, com processos redesenhados a partir do padrão da ferramenta, e migra apenas os dados mestres e os saldos que fazem sentido levar.

Faz sentido quando os processos atuais são reconhecidamente o gargalo, quando o sistema acumulou customização demais para valer a pena carregar, ou quando a empresa passou por fusão, cisão ou mudança de modelo de negócio.

O custo real não está na tecnologia — está na gestão de mudança. Todo mundo vai trabalhar diferente. Se a organização não estiver preparada para isso, o projeto entrega no prazo e falha na adoção.

Brownfield: conversão do sistema atual

Você converte tecnicamente o sistema existente. Customizações, histórico e configurações vêm junto. É o caminho mais rápido e o de menor ruptura para o usuário final.

Faz sentido quando os processos funcionam razoavelmente bem e o objetivo é modernizar a plataforma, não redesenhar a operação.

O risco é herdar o que não presta. Se ninguém fizer a triagem, a empresa migra para uma plataforma nova carregando customização que ninguém usa há anos e dado mestre duplicado que ninguém quis limpar. O S/4HANA fica moderno por fora e antigo por dentro.

Selective Data Transition: o meio-termo

Você constrói um sistema novo, mas leva seletivamente o que interessa — determinadas empresas, determinados processos, determinado período de histórico.

Faz sentido quando existe muita coisa boa e muita coisa ruim para carregar junto, ou quando o grupo tem várias empresas em estágios diferentes de maturidade.

A complexidade está na regra de recorte. Definir o que vai e o que fica exige domínio funcional e técnico, e é onde o projeto costuma consumir mais tempo de análise.

O que realmente define custo e prazo

Fornecedores costumam orçar por número de usuários e módulos. É uma aproximação grosseira. Na prática, quatro fatores explicam a maior parte da variação:

1. Volume e qualidade das customizações. Não é o número absoluto de objetos Z que importa, é quantos deles ainda são usados e quantos já viraram funcionalidade padrão no S/4HANA. Em ambientes ECC antigos, é comum que uma parcela relevante do inventário de customizações esteja morta — ninguém executa aquele programa há anos, mas ele continua no sistema e entra na conta de migração de quem não fez o levantamento.

2. Qualidade dos dados mestres. Cliente duplicado, material sem classificação, fornecedor com cadastro incompleto. Nenhum desses problemas nasce na migração, mas todos aparecem nela. Limpar dado mestre é trabalho de negócio, não de TI, e é a atividade mais subestimada em cronograma de projeto SAP.

3. Número de integrações. Cada interface com sistema externo é um ponto de teste e um ponto de falha potencial no cutover. Empresas que cresceram por aquisição costumam ter mais integrações do que imaginam.

4. Velocidade de decisão do cliente. Este é o fator que ninguém coloca na proposta e que mais atrasa projeto. Nos workshops de fit-to-standard, cada lacuna entre o processo atual e o padrão exige uma decisão: aderir, configurar ou desenvolver. Quando a decisão fica parada esperando aprovação de alguém que não está no projeto, o cronograma inteiro escorrega.

Os cinco erros que mais atrasam migrações

Tratar como projeto de TI. Migração para S/4HANA muda como as pessoas trabalham. Se o patrocínio for da TI e não da diretoria de negócio, cada decisão vira negociação.

Pular o assessment para economizar. O assessment custa uma fração do projeto e é o que evita a surpresa cara no meio do caminho. Projeto orçado sem inventário de customização é projeto que vai ter aditivo.

Migrar tudo "por segurança". A tentação de levar todo o histórico e todas as customizações é grande, porque decidir dá trabalho. O resultado é um projeto mais caro, mais longo e mais arriscado, para preservar coisas que ninguém vai usar.

Deixar a limpeza de dados para o fim. Dado mestre ruim descoberto no ciclo final de testes vira atraso direto no go-live. A limpeza precisa começar junto com o projeto.

Subdimensionar o teste integrado. Dois ciclos completos de teste integrado mais um teste de aceitação com usuários-chave é o mínimo. Projetos que cortam ciclo de teste para recuperar cronograma pagam isso em dobro no hypercare.

Por onde começar

O primeiro passo não é escolher fornecedor nem definir orçamento. É levantar o que você tem: inventário de customizações com indicação de uso real, mapa de integrações, diagnóstico de qualidade dos dados mestres e resultado do SAP Readiness Check.

Com esses quatro documentos na mão, a conversa com qualquer fornecedor muda de qualidade. Você deixa de receber proposta genérica e passa a receber proposta orçada sobre a sua realidade — e passa a conseguir comparar propostas entre si, o que hoje raramente é possível.

Se você ainda não tem esse material, é exatamente por aí que recomendamos começar.