Cronograma de migração S/4HANA e plano de projeto por caminho

Na minha experiência, o cronograma de uma migração de SAP ECC para S/4HANA é de 12 a 18 meses para uma conversão brownfield e de 18 a 24 meses para uma implementação greenfield. Uma selective data transition leva de 12 a 18 meses. O plano de projeto segue as seis fases do SAP Activate, e a fase que mais estoura o prazo é o custom code.

Resposta curta: comece o plano com o SAP Readiness Check e reserve de 30 a 40 por cento do esforço para os dados. Em um brownfield, planeje três conversões simuladas e espere um downtime de cutover de um fim de semana até uma semana.

Este artigo é o detalhe de cronograma e planejamento por trás do meu guia de migração de ECC para S/4HANA, que trata dos caminhos e dos prazos do ECC. Se você está implementando SAP do zero, e não saindo do ECC, meu guia de cronograma de implementação SAP cobre esse caso, com a duração de cada fase.

O caminho define a duração. Minha regra: greenfield quando você vem de outros sistemas ou quando novos processos precisam ser definidos. Brownfield quando os processos estão definidos e funcionando, e selective quando os processos de algumas áreas precisam ser redefinidos.

Esta é a duração de cada caminho nos programas que acompanhei, e o que costuma alongá-la:

Caminho	Cronograma típico	Em torno do que o plano é montado	O que costuma alongá-lo
Brownfield (conversão de sistema)	12 a 18 meses	Converter o sistema ECC existente com o Software Update Manager, depois conversões de teste repetidas	Adaptação do custom code e a conversão para business partner
Greenfield (nova implementação)	18 a 24 meses	Desenho Fit-to-Standard, construção e ciclos repetidos de carga de dados	Workshops de Explore que viram longas listas de requisitos, e a limpeza de dados
Selective data transition	12 a 18 meses	Definir quais empresas, unidades e histórico migram, depois ferramentas especializadas	O escopo dos dados e a dependência de parceiros especializados

O calendário importa tanto quanto o caminho. Para o ECC nos enhancement packages 6 a 8, a manutenção padrão termina em 31 de dezembro de 2027 (SAP News). Um brownfield iniciado este mês entra em produção entre outubro de 2027 e abril de 2028, e um greenfield iniciado agora chega em 2028.

Ou seja, a maioria dos planos escritos hoje precisa de alguma manutenção estendida no orçamento. Coloque-a no início, e não como surpresa no segundo ano.

RISE with SAP é um pacote comercial, não um caminho. Um brownfield ou selective sob RISE vai para o SAP Cloud ERP Private, o nome atual que a SAP usa para o que muitos ainda pesquisam como S/4HANA Cloud Private Edition. Os 6 a 9 meses que cito para GROW with SAP e os 9 a 18 meses para RISE valem para novas implementações, não para saídas do ECC.

O SAP Activate é o método de entrega da SAP para o S/4HANA. Ele tem seis fases: Discover, Prepare, Explore, Realize, Deploy e Run (SAP Activate).

Uma migração usa as mesmas fases. O que muda é o trabalho dentro de cada uma.

O plano de projeto da migração

1. 01

   Discover

   Readiness Check, decisão de caminho e business case.

2. 02

   Prepare

   Plano, governança, equipe e primeiro sandbox.

3. 03

   Explore

   Fit-to-Standard ou desenho delta, lista WRICEF acordada.

4. 04

   Realize

   Construção, custom code, cargas de dados, conversões de teste.

5. 05

   Deploy

   Ensaio geral, cutover e go-live.

6. 06

   Run

   Hypercare, estabilização e desativação do ECC.

Isto é o que cada fase contém em uma migração, e onde os caminhos diferem:

Fase	O que acontece em uma migração	Como os caminhos diferem
Discover	SAP Readiness Check, decisão de caminho, business case, primeira visão de custom code e dados	O selective precisa de um primeiro escopo de dados aqui
Prepare	Plano, governança, equipe, responsabilidade pelos dados, sandbox	O brownfield faz uma primeira conversão em sandbox; o greenfield prepara o sistema e a agenda de workshops
Explore	Workshops Fit-to-Standard ou desenho delta, lista WRICEF acordada, mapeamento de dados	O greenfield passa mais tempo aqui; o brownfield trabalha os simplification items aplicáveis
Realize	Construção, adaptação do custom code, ciclos de carga de dados, rodadas de teste	O brownfield faz conversões simuladas; o greenfield faz ciclos de carga, geralmente com o Migration Cockpit
Deploy	Ensaio geral, cutover, go-live	A janela de downtime depende do caminho, do volume de dados e da abordagem
Run	Hypercare, estabilização	Desativar o ECC e arquivar o que foi mantido

WRICEF significa workflows, relatórios, interfaces, conversões, enhancements e formulários. É a lista de tudo o que você constrói além do padrão SAP, e é o número a acompanhar.

Nos 21 programas SAP que liderei ou resgatei, o maior erro é não planejar direito no início da implementação. No Prepare, defina quem é responsável pela limpeza de dados, qual custom code será aposentado e quando acontece cada conversão de teste e cada ensaio. Essas datas viram a espinha dorsal do plano.

Brownfield: planeje em torno das conversões de teste

Um plano brownfield é montado em torno do ciclo de conversão. O Software Update Manager converte o sistema, e cada execução de teste mostra quanto tempo a conversão real vai levar e o que quebra.

Em um brownfield, planejo três conversões simuladas antes do cutover. Cada uma deve rodar sobre uma cópia recente da produção, para que os tempos signifiquem algo. A última deve se comportar como o go-live: mesma sequência, mesmas pessoas, mesmas verificações.

O plano da própria SAP para a sua abordagem downtime-optimized é parecido. Ele prevê uma execução em sandbox, uma execução de garantia de qualidade, uma verificação de carga em um clone e um ensaio geral (SAP Learning). A SAP observa que menos execuções são tecnicamente possíveis, mas aumentam o risco.

Greenfield: planeje em torno do desenho e das cargas de dados

No greenfield, o tempo vai para o Explore. Os workshops Fit-to-Standard decidem quanto do padrão SAP você adota, e cada gap vira um objeto WRICEF a construir, testar e manter.

Os dados migram em ciclos de carga, geralmente com o SAP S/4HANA Migration Cockpit. Planeje vários ciclos de carga completos, cada um seguido de uma reconciliação assinada pela área de negócio. Meu guia passo a passo do Migration Cockpit trata das staging tables, dos objetos de migração e do processo de carga.

Selective: planeje em torno do escopo dos dados

Um plano selective começa com um escopo de dados. Quais empresas, unidades de negócio e anos de histórico migram, e quais processos são redesenhados.

Esse escopo determina as ferramentas, o parceiro especializado e os ciclos de teste. Se ele mudar tarde, o cronograma muda junto.

Na minha experiência, custom code é a fase que mais estoura o prazo. É também o custo oculto mais esquecido em uma migração, assunto do meu guia de custo de migração S/4HANA.

Estes são os pontos que eu acompanharia, nesta ordem:

1. Custom code. As equipes dimensionam a partir de um relatório e só descobrem o tamanho real quando a correção começa. Em um programa, a análise com smartShift reduziu os objetos customizados de 18.000 para 3.200. Primeiro aposente, depois adapte.
2. Objetos customizados que a avaliação deixou passar. Na minha experiência, os objetos customizados que o SAP Readiness Check não pega são os que causam problema depois. Leia meu guia do SAP Readiness Check antes de tratar o resultado dele como o seu escopo.
3. Dados. A migração de dados consome de 30 a 40 por cento do esforço. Quando a limpeza não tem dono, ela começa tarde e depois espreme os ciclos de teste. Meu artigo sobre por que a migração de dados SAP falha vai mais fundo.
4. Explore. Os orçamentos sofrem no Explore, conforme a lista WRICEF cresce. Quando o fornecedor controla o escopo, ninguém do lado do fornecedor tem motivo para impedir esse crescimento.
5. Ensaios cortados para ganhar tempo. Um ensaio eliminado para proteger a data costuma custar mais tempo no fim de semana do go-live do que economizou.

Minha visão: trave a data de go-live no fim do Explore, quando a lista WRICEF e o escopo de custom code são conhecidos. Uma data definida no kickoff é um palpite com uma apresentação para o conselho anexada.

O downtime de cutover que já vi vai de um fim de semana a uma semana. O volume de dados, a abordagem de conversão, o número de entidades e interfaces que entram em produção juntas e a rapidez com que o negócio consegue validar, tudo isso o altera.

Para um brownfield, a SAP oferece uma abordagem de conversão downtime-optimized no Software Update Manager. Ela leva parte da conversão e da migração dos dados para o uptime, enquanto a produção continua rodando.

Não é tempo de graça. A SAP lista execuções de teste extras, um planejamento mais complexo, congelamento de customizing e desenvolvimento antes do downtime e um especialista treinado na abordagem.

Por isso, combine o downtime que o negócio aceita antes de escolher a abordagem técnica. Depois, comprove-o nas conversões simuladas, e não no fim de semana do go-live. Mantenha o cutover longe do fechamento mensal e da alta temporada.

Um plano é tão bom quanto as premissas por trás dele. Estas são as perguntas que eu faria antes de qualquer assinatura:

1. Qual caminho o plano assume, e o que nos resultados do nosso Readiness Check o sustenta?
2. Quantos objetos customizados ficam no escopo após a análise de uso, e quantos serão aposentados?
3. Quem é responsável pela limpeza de dados, e em qual fase ela começa?
4. Quantas conversões simuladas ou ciclos de carga estão planejados, e com quais dados?
5. Que downtime o plano assume, e qual execução de teste o comprova?
6. Quando a data é travada, e o que acontece com ela se a lista WRICEF crescer no Explore?

Peça ao parceiro referências de programas parecidos com o seu e o desenho de alto nível dele. Se as respostas forem genéricas e não específicas para o seu negócio, trate isso como sinal de alerta.

Rode o SAP Readiness Check neste trimestre. Leve as conclusões sobre custom code e dados ao CFO e ao diretor do programa antes que alguém se comprometa com uma data de go-live.

Depois, monte o plano de trás para frente a partir da janela de cutover que você aceita, com três conversões simuladas em um brownfield ou os ciclos de carga que o seu caminho exige. Para testar primeiro o próprio caminho, use minha avaliação de migração greenfield vs brownfield.

Ajudo organizações a montar e pôr à prova planos de migração como este. Se você quer uma visão independente, entre em contato.

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

Na minha experiência, uma conversão brownfield a partir do ECC leva de 12 a 18 meses, uma implementação greenfield de 18 a 24 meses e uma selective data transition de 12 a 18 meses. Custom code é a fase que mais estoura o prazo, e a migração de dados consome de 30 a 40 por cento do esforço.

Quais são as fases de um plano de projeto de migração S/4HANA?

O plano segue o SAP Activate: Discover, Prepare, Explore, Realize, Deploy e Run. Em uma migração, o Discover contém o Readiness Check e a decisão de caminho, o Realize contém custom code, cargas de dados e conversões de teste, e o Deploy contém o ensaio geral e o cutover.

Quantas conversões simuladas são necessárias em uma migração brownfield para S/4HANA?

Em um brownfield, planejo três conversões simuladas antes do cutover. Para a sua abordagem downtime-optimized, a SAP prevê uma execução em sandbox, uma execução de garantia de qualidade, uma verificação de carga e um ensaio geral, e diz que menos execuções aumentam o risco.

Quanto dura o downtime de cutover do S/4HANA?

O downtime de cutover que já vi vai de um fim de semana a uma semana. Depende do volume de dados, da abordagem de conversão e de quantas entidades e interfaces entram em produção juntas. A conversão downtime-optimized da SAP leva parte do trabalho para o uptime, mas exige mais execuções de teste e mais planejamento.

Dá para concluir uma migração para S/4HANA antes do fim do suporte ao ECC em 2027?

A manutenção padrão do ECC nos enhancement packages 6 a 8 termina em 31 de dezembro de 2027. Um brownfield iniciado em outubro de 2026 entra em produção entre outubro de 2027 e abril de 2028, e um greenfield em 2028. A maioria dos programas que começam agora deve orçar alguma manutenção estendida.

O que mais atrasa os projetos de migração para S/4HANA?

Na minha experiência, o custom code é o que mais estoura o prazo, seguido da limpeza de dados que começa tarde e de uma lista WRICEF que não para de crescer no Explore. Não planejar direito no início do programa é a raiz da maior parte desses problemas.