A manutenção do SAP ECC termina a 31 de dezembro de 2027: um aumento de preço, não um encerramento

A 31 de dezembro de 2027, a SAP termina a manutenção principal (mainstream maintenance) do SAP ECC 6.0 e das restantes aplicações nucleares do SAP Business Suite 7. Nada se desliga a 1 de janeiro de 2028. O seu sistema continua a funcionar, os seus utilizadores continuam a lançar faturas e a SAP continua a vender-lhe suporte. O que muda é quanto paga por ele e o que recebe em troca.

A distinção importa, porque muitos dos conselhos que circulam tratam 2027 como um precipício. Para a maioria das empresas que ainda estão no ECC não é, e elas sabem-no: o maior grupo de utilizadores de ECC que resta está a planear para 2030. O risco real é outro. O trabalho que decide de facto a data (ABAP à medida, interfaces, dados) é dimensionado tarde, e 2030 acaba por ser tão apertado como foi 2027.

Este texto é para diretores de sistemas de informação e responsáveis SAP de empresas de média dimensão, a maioria em mercados de língua alemã, que ainda têm o ECC e precisam de decidir como vão ser os próximos três anos.

O que a SAP se comprometeu de facto a fazer

As condições estão na página da estratégia de manutenção da SAP e foram anunciadas pela primeira vez em fevereiro de 2020:

• Até 31 de dezembro de 2027: manutenção principal para as aplicações nucleares do Business Suite 7, entre elas o SAP ERP 6.0, nos três enhancement packages mais recentes. Se o seu sistema está num enhancement package mais antigo, consulte a SAP Note 2881788 (com ligação nessa página) antes de montar um plano com base na data de 2027.
• De 1 de janeiro de 2028 a 31 de dezembro de 2030: manutenção alargada opcional, com «um acréscimo de dois pontos percentuais sobre a base de manutenção». Dito de forma simples, a taxa de manutenção que paga hoje sobe dois pontos.
• Se não contratar a manutenção alargada: passa automaticamente para a manutenção específica do cliente (customer-specific maintenance). O que esta cobre está descrito na SAP Note 52505, com ligação na mesma página. Leia-a antes de partir do princípio de que chega.
• Para o S/4HANA: a SAP comprometeu-se a manter o produto até ao final de 2040.

Há ainda um caminho para um grupo mais restrito. Em agosto de 2025, a SAP apresentou a SAP ERP, private edition, transition option: uma subscrição por tempo limitado que leva o ECC de 2031 a 2033 dentro da nuvem privada da SAP. As condições são exigentes. «Os sistemas têm de ser migrados para o SAP ERP, private edition, em SAP HANA antes de 31 de dezembro de 2030.» O HANA é a única base de dados suportada, a opção só existe em conjunto com o max success plan para 2031 a 2033, e a SAP impõe um mínimo de 2 TB para os sistemas subscritos ao abrigo dela. A SAP diz que se destina aos «nossos maiores e mais complexos clientes de SAP ERP». As «condições comercialmente equivalentes» que a SAP ofereceu eram para os clientes que se comprometessem com a private edition até ao final de 2025.

Seja qual for o nível que escolher, faça uma pergunta por escrito à SAP e ao seu parceiro: que alterações legais (fiscais, de processamento salarial, de formatos de fatura eletrónica) vão continuar a chegar ao seu sistema ECC, e até quando. Para uma empresa alemã, essa resposta pode, por si só, decidir se ficar como está é viável.

O que está a fazer o resto do mercado

O DSAG, o grupo de utilizadores SAP de língua alemã, realizou o seu Investment Report 2026 com 198 inquiridos, entre 8 de dezembro de 2025 e 21 de janeiro de 2026. Desses, 54 por cento ainda usam o ECC ou o Business Suite mais antigo, contra 68 por cento em 2024.

Quanto ao calendário, quase metade dos inquiridos planeia passar para o S/4HANA até ao final de 2030, o que, como o DSAG sublinha, significa pagar manutenção alargada. Outros 37 por cento querem mudar até ao final de 2027, e apenas 4 por cento apontam para 2033 e para a private edition transition option.

O presidente do DSAG, Jens Hungershausen, explicou as razões sem rodeios: a falta de competências, os projetos de transformação em paralelo e os orçamentos limitados estão a empurrar os calendários, «mesmo que isso implique custos de manutenção mais altos».

Os compradores públicos também estão a mexer-se. A nossa própria contagem dos anúncios de concursos públicos na UE encontra cerca de 200 procedimentos de migração para S/4HANA por semestre ao longo de 2025 e 2026, e mais de 300 em 2026 até ao início de outubro, a maioria na Alemanha. O trabalho está a acontecer. Só que está distribuído por um prazo mais longo do que os títulos sobre 2027 dão a entender.

Onde está realmente o trabalho

A conversão técnica do ECC para o S/4HANA está bem servida de ferramentas pela SAP e pelos seus parceiros. Se tem um ECC pouco personalizado, com meia dúzia de interfaces standard, o seu integrador já fez isto muitas vezes e a maior parte do que se segue não é problema seu.

Passa a ser problema seu na proporção do que construiu por conta própria.

ABAP à medida: onde os projetos derrapam

O S/4HANA não é o ECC com uma base de dados nova. Partes do modelo de dados mudaram. Clientes e fornecedores passam a ser parceiros de negócio. Os lançamentos financeiros e de inventário foram consolidados em menos tabelas, mas mais largas. Algumas transações e funções foram eliminadas ou substituídas.

O código à medida que lê tabelas diretamente, depende de um exit que mudou de sítio ou assume discretamente uma ordenação (o HANA não garante nenhuma, a não ser que a consulta a peça) pode passar numa verificação de sintaxe e mesmo assim fazer a coisa errada. É este último tipo que dói, porque aparece nos testes de integração ou depois do arranque em produção, e não na análise de código.

O processo que funciona:

1. Meça primeiro a utilização. Ative o registo de utilização em produção (o ABAP call monitor, transação SCMON) e deixe-o a correr durante um fecho de exercício completo. Em sistemas com muitos anos, uma parte considerável dos objetos à medida muitas vezes nunca é executada. Código que ninguém executa apaga-se, não se migra.
2. Passe as ferramentas de análise pelo que sobra. As verificações da SAP encontram potenciais problemas. Não conseguem dizer-lhe quais deles importam para o negócio.
3. Classifique cada objeto. Retirá-lo, substituí-lo por funcionalidade standard, corrigi-lo no sítio ou reconstruí-lo fora do núcleo. Uma decisão por objeto, com um responsável de negócio identificado.
4. Teste por processo, não por objeto. Alterar o código é a parte barata. Provar que o order-to-cash e o fecho mensal continuam a dar os mesmos números é a parte cara.

Os projetos derrapam aqui por uma razão aborrecida: ninguém fez a contagem a tempo. O volume de código à medida só se conhece por alto, as pessoas que o escreveram muitas vezes já saíram, e as descobertas reais chegam no segundo ciclo de testes, depois de a data já ter sido anunciada internamente.

Interfaces, e o PI/PO com o mesmo relógio

O ECC raramente está sozinho. IDocs para o armazém, chamadas RFC e BAPI a partir da fábrica, ficheiros planos para o banco e para o contabilista, um portal de clientes a ler uma vista da base de dados que alguém criou em 2011. Cada uma destas ligações tem de ser encontrada, testada e, nalguns casos, reconstruída.

Se essas interfaces passam pelo SAP Process Integration ou pelo Process Orchestration, há um segundo prazo nas mesmas datas. O Architecture Center da SAP diz que o PI/PO se aproxima do «fim da manutenção standard em 2027», que os clientes podem prolongar a manutenção até 2030 e que, a partir daí, o suporte da SAP termina. A SAP encaminha os clientes de PI/PO para o SAP Integration Suite, que inclui uma avaliação de migração e ferramentas de migração guiadas por assistente.

As ferramentas ajudam com os objetos standard. Não lhe dizem que interfaces ainda servem para alguma coisa, e a lógica de mapeamento à medida continua a precisar de alguém que a leia. Construa o inventário a partir da configuração do middleware, dos registos e das tarefas agendadas, e não de um questionário. Depois planeie a migração do ERP e a do middleware em conjunto. Feitas uma a seguir à outra, cada interface é testada duas vezes.

Migração de dados

Numa conversão de sistema, os dados mudam com o sistema, e a qualidade deles também. A conversão para parceiros de negócio é normalmente o primeiro choque: clientes duplicados, fornecedores que também são clientes, moradas em campos de texto livre, números de contribuinte no sítio errado. Tudo isso tem de ser limpo antes da conversão, não durante.

Numa implementação nova, extrai, limpa, transforma e carrega, e a parte difícil é a reconciliação. A área financeira só dá o aval quando os saldos e as partidas em aberto batem certo, não quando o processo de carregamento termina. Construa a migração como código repetível, que possa correr uma dúzia de vezes sobre dados cada vez mais limpos, comparando automaticamente os resultados em cada execução.

Em qualquer dos caminhos, arquive primeiro o que já não precisa. Menos dados significam execuções de conversão mais curtas e uma janela de paragem mais curta.

Extensões clean core

Num projeto movido por um prazo, a tentação é levar todas as modificações para o outro lado e prometer arrumar a casa mais tarde. O mais tarde não chega.

A SAP chama clean core à alternativa: deixar o sistema standard sem modificações e construir as extensões sobre interfaces que a SAP publica e mantém estáveis, dentro do S/4HANA ou ao lado dele, na SAP Business Technology Platform. Nem tudo pode ficar limpo no primeiro dia. A regra que se consegue de facto cumprir é mais simples: nada de novo se constrói à maneira antiga. Cada modificação que evita agora é uma que não volta a testar em cada atualização futura.

Um quadro de decisão

Há três caminhos realistas e um quarto de que se fala menos.

Arrancar em S/4HANA até 31 de dezembro de 2027. Serve as empresas que já começaram, têm um sistema essencialmente standard e já têm parceiro contratado. A partir de hoje são quinze meses, e poucas equipas financeiras aceitam uma passagem a produção a meio do fecho do exercício. Se a análise do código à medida ainda não foi feita, este provavelmente não é o seu caminho.

Pagar a manutenção alargada e arrancar até 2030. É para aqui que caminha a maior parte do mercado. O custo é o acréscimo de dois pontos; confirme com a SAP como se aplica se arrancar a meio do período. O risco é tratar 2030 como se tratou 2027: como algo distante, até deixar de o ser de repente.

Optar pela private edition transition option até 2033. Isso implica um contrato RISE with SAP, HANA, o sistema migrado para o SAP ERP, private edition, antes de 31 de dezembro de 2030, o max success plan e o mínimo de 2 TB. Para uma empresa de média dimensão, raramente é a forma mais barata de ganhar tempo.

Sair da SAP. Para alguns fabricantes e distribuidores de média dimensão, um ERP mais pequeno é uma opção real. O trabalho de interfaces e de dados não diminui. Passa a ser a maior parte do projeto.

Os próximos seis meses, seja qual for a escolha

Daqui até ao final de março de 2027, tudo isto compensa em qualquer dos caminhos:

1. Confirme o ponto de partida. Enhancement package, base de dados, contrato de manutenção. Peça por escrito à sua equipa de conta SAP as condições de manutenção alargada que se aplicam ao seu caso.
2. Ative já o registo de utilização, para que apanhe o fecho do exercício de 2026.
3. Faça uma análise do código à medida e saia dela com uma contagem, não com uma impressão: quantos objetos, quantos em uso, quantos tocam nas partes do modelo de dados que mudaram.
4. Construa o inventário de interfaces, incluindo tudo o que passa pelo PI/PO, com um responsável e uma decisão para cada interface.
5. Comece a limpeza dos dados mestre, primeiro clientes e fornecedores.
6. Deixe de acrescentar modificações. O desenvolvimento novo segue o clean core a partir de hoje.
7. Inclua o aumento da manutenção de 2028 no orçamento de 2027, como custo conhecido e não como surpresa.
8. Reserve capacidade: o parceiro, a sua equipa SAP interna e os programadores que cuidam dos sistemas à volta da SAP. A falta de competências é uma das razões que os membros do DSAG apontam para os calendários que derrapam.

Contando para trás a partir de um arranque em 2030: ciclos de testes e ensaios de passagem a produção em 2030, desenvolvimento e correções em 2029, desenho e limpeza de dados em 2028, análise agora. Há menos folga nisto do que parece.

Onde obter ajuda

Não somos uma consultora funcional SAP e não fazemos conversões para S/4HANA; trabalhamos ao lado do parceiro que as faz, no inventário e na reconstrução das interfaces, no código de migração de dados e na respetiva reconciliação, e nas aplicações construídas à volta do ECC que têm de sobreviver à mudança. Esse trabalho está descrito na nossa página de modernização de ERP, e a manutenção de sistemas legados cobre os sistemas que ficam onde estão até à migração. Se quiser ter o ecossistema à volta do seu ERP contabilizado antes de assinar um programa, escreva para office@c9group.dev.