A manutenção mainstream do SAP Business Suite 7 termina no fim de 2027 para os releases cobertos. O sistema não deixará de funcionar no dia seguinte, mas adiar a decisão reduz opções, comprime testes e pode elevar o custo da transição
A SAP mantém a manutenção mainstream do SAP Business Suite 7 até 31 de dezembro de 2027 para os releases incluídos em sua política, entre eles os três enhancement packages mais recentes do SAP ERP 6.0. De 2028 a 2030, clientes elegíveis podem contratar manutenção estendida com acréscimo de dois pontos percentuais sobre a base de manutenção. O prazo efetivo de migração depende do ambiente, do escopo e da abordagem escolhida; por isso, diagnóstico e planejamento não devem esperar 2027.
O fim da manutenção mainstream não é um botão de desligamento. O SAP ECC não deixará automaticamente de funcionar em 1º de janeiro de 2028. O que muda é o modelo de manutenção disponível para os sistemas e releases cobertos pela política da SAP.
A SAP informa que a manutenção mainstream das aplicações centrais do SAP Business Suite 7 vai até o fim de 2027. Para o SAP ERP 6.0, a cobertura se aplica aos três enhancement packages mais recentes — EHP 6, EHP 7 e EHP 8. Entre 2028 e 2030, existe a opção de manutenção estendida, com um prêmio de dois pontos percentuais sobre a base de manutenção. Depois disso, ou para quem não aderir à extensão, entra em cena a manutenção específica do cliente, com escopo diferente.
Essa precisão importa porque “fim do suporte” costuma ser interpretado de duas formas equivocadas: como uma paralisação imediata ou como uma data que pode ser ignorada porque o sistema continuará operando. Nenhuma das duas leituras ajuda a empresa a decidir.
Essa é a data da política de manutenção da SAP, não a data ideal de início da transformação de cada cliente.
Uma migração para o SAP S/4HANA pode envolver análise de código customizado, compatibilidade de add-ons, revisão de integrações, qualidade e volume de dados, simplification items, desenho de processos, adequações de infraestrutura, testes, treinamento e cutover. A duração varia de acordo com a complexidade do ambiente e com a estratégia adotada.
Por isso, uma estimativa genérica de meses não deveria substituir um diagnóstico. Uma empresa com poucos processos customizados e escopo controlado enfrenta um cenário diferente de um grupo com múltiplas sociedades, países, interfaces e anos de customizações.
O erro de planejamento é contar apenas o tempo de execução técnica. Antes dele, a organização precisa escolher a abordagem, definir o caso de negócio, montar a governança, priorizar processos e preparar o ambiente atual.
De forma simplificada, a empresa pode considerar:
• nova implementação (greenfield): redesenho mais amplo, com adoção de processos padronizados e migração seletiva de dados;
• conversão do sistema (brownfield): transformação do ambiente existente, preservando maior continuidade de processos e históricos;
• transição seletiva de dados: alternativa intermediária para cenários que exigem escolher quais dados, estruturas ou unidades serão transferidos.
A SAP reconhece a transição seletiva como uma alternativa à conversão e à nova implementação. A escolha correta depende de objetivos de negócio, qualidade do legado, necessidade de mudança e restrições de prazo — não apenas de preferência técnica.
Esperar tem consequências mesmo quando nada parece mudar no curto prazo.
Primeiro, a empresa reduz a margem para realizar saneamento de dados, testes integrados e preparação de usuários. Segundo, concentra decisões complexas em uma janela menor. Terceiro, pode chegar a 2028 dependente de manutenção estendida enquanto ainda executa a transformação.
Há também uma questão de capacidade. Quanto mais organizações avançam simultaneamente rumo ao SAP S/4HANA, maior tende a ser a disputa por profissionais experientes, agendas de parceiros e janelas internas de negócio. Projetos iniciados sob pressão têm menos espaço para reavaliar escopo ou corrigir premissas.
Isso não significa migrar às pressas. Significa começar cedo o suficiente para preservar opções.
O primeiro passo é verificar a situação real do ambiente. A empresa precisa saber qual release e enhancement package utiliza, quais componentes estão em escopo e que dependências podem influenciar a transição.
O SAP Readiness Check para SAP S/4HANA ajuda a levantar aspectos como simplification items, código customizado, add-ons, integrações, dimensionamento e volume de dados. Ele funciona como instrumento de planejamento e não substitui uma avaliação detalhada do projeto, mas organiza a conversa com evidências do próprio ambiente.
Na prática, um diagnóstico de prontidão deve responder:
1. qual é a cobertura de manutenção aplicável ao sistema atual;
2. quais customizações e integrações são críticas;
3. que dados precisam ser saneados, arquivados ou migrados;
4. qual abordagem de transição faz sentido;
5. quais períodos do negócio são inadequados para testes e go-live;
6. quais capacidades internas e externas serão necessárias.
Com essas respostas, 2027 deixa de ser uma ameaça abstrata e vira um marco dentro de um roadmap.
A empresa ainda pode ter alternativas, mas o tempo disponível precisa ser calculado de trás para frente: go-live desejado, estabilização, cutover, testes, construção, desenho e diagnóstico.
Quanto antes esse cálculo for feito, maior a chance de escolher a abordagem pelo valor que ela entrega. Quando o prazo aperta, a organização passa a escolher pelo que ainda cabe no calendário.
Não automaticamente. O encerramento da manutenção mainstream muda as condições de manutenção e suporte disponíveis. O impacto específico depende do release, do contrato e da estratégia do cliente.
Para o escopo elegível do SAP Business Suite 7, a SAP informa manutenção estendida opcional do início de 2028 até o fim de 2030, com prêmio de dois pontos percentuais sobre a base de manutenção.
O diagnóstico deve combinar inventário do ambiente, SAP Readiness Check, análise de processos, dados, integrações, customizações, riscos e objetivos de negócio.
A Engine realiza o diagnóstico de prontidão e ajuda sua empresa a transformar a política de manutenção do ECC em um plano viável de migração. Comece a #ClimbToCloud antes que a pressão do calendário limite suas escolhas.