SAP S/4HANA: versões, edições e ciclo de manutenção vistos pela área de manutenção

O SAP S/4HANA existe em três formas de implantação: on-premise, Cloud Private Edition e Cloud Public Edition. On-premise e Private Edition usam o mesmo software e o mesmo ciclo de releases: desde o release 2023, uma nova versão base sai a cada dois anos e cada uma recebe sete anos de manutenção principal. A Public Edition segue outro código e outro calendário, com dois releases por ano, em fevereiro e agosto, aplicados pela SAP em todos os clientes.

Para a área de manutenção, a edição escolhida define quem decide a data do upgrade, quantas vezes por ano as integrações precisam ser retestadas e que tipo de extensão o SAP aceita. Aplicativos de campo, interfaces de ordens e programas Z de PM dependem diretamente dessas três respostas.

Releases do S/4HANA on-premise e ciclo de manutenção

A SAP lançou o S/4HANA em 3 de fevereiro de 2015. Até o release 2022, publicou uma versão por ano, com cinco anos de manutenção principal para cada uma. Em setembro de 2022, a SAP anunciou a mudança de estratégia: a partir do release 2023, disponível em outubro de 2023, o produto passou a ter ciclo de dois anos, sete anos de manutenção principal por release e feature packs semestrais.

Na mesma comunicação, a SAP ofereceu aos clientes nos releases 1709, 1809 e 1909 uma opção de manutenção estendida para permitir o upgrade direto para o 2023, e reafirmou que, até 2040, sempre haverá ao menos um release do S/4HANA em manutenção.

A tabela resume o que está publicado pela SAP para os releases que importam hoje.

Release	Disponibilidade	Ciclo e manutenção	Observação
Até o 2022	Um release por ano, de 2015 a 2022	Cinco anos de manutenção principal por release	Para 1709, 1809 e 1909, a SAP ofereceu manutenção estendida com upgrade direto para o 2023
2023	Outubro de 2023	Sete anos de manutenção principal	Primeiro release do ciclo de dois anos
2025	Documentação publicada em 08/10/2025; FPS01 em 25/02/2026	Sete anos de manutenção principal	Release mais recente do ciclo em outubro de 2026

Depois de cada release base, a SAP entrega Feature Pack Stacks (FPS) a cada seis meses, com novidades não disruptivas, até o release base seguinte. Quando o release seguinte sai, o anterior passa a receber Support Pack Stacks apenas com correções, até o fim da manutenção principal. Pelo ciclo anunciado, o próximo release base é esperado para 2027; a data deve ser confirmada no roadmap oficial.

O que o FPS muda para quem planeja manutenção

Um FPS não obriga ninguém a mudar de processo, mas altera o sistema. Se a empresa aplica FPS para ganhar uma funcionalidade nova de manutenção, as interfaces de ordens, notas, confirmações e medições precisam entrar no teste de regressão, inclusive as usadas por aplicativos móveis. O FPS deve aparecer no mesmo calendário das paradas planejadas da planta.

As três edições: on-premise, Cloud Private Edition e Cloud Public Edition

As edições compartilham o nome S/4HANA e boa parte das funcionalidades, mas diferem em quem opera, quem decide o upgrade e quanto o cliente pode alterar. Em comunicações recentes, a SAP também passou a usar os nomes SAP Cloud ERP Private e SAP Cloud ERP para a oferta em nuvem.

Critério	On-premise	Cloud Private Edition	Cloud Public Edition
Software	Release base on-premise	Mesmo software e ciclo do on-premise	Linha de código própria da nuvem pública
Releases	Base a cada dois anos e FPS semestral	Base a cada dois anos e FPS semestral	Dois releases por ano, em fevereiro e agosto
Quem decide o upgrade	Cliente	Cliente, com ao menos um upgrade a cada sete anos para ficar na manutenção principal	SAP, por calendário único para todos os clientes
Quem executa o upgrade técnico	Cliente ou parceiro	SAP; planejamento, preparação e testes ficam com o cliente ou parceiro	SAP, automaticamente
Extensões	ABAP clássico permitido; a SAP recomenda o modelo clean core	ABAP clássico permitido; a SAP recomenda o modelo clean core	Somente APIs e pontos de extensão liberados pela SAP, extensões de usuário-chave, ABAP Cloud e extensões no SAP BTP

Cloud Private Edition

A SAP descreve a Private Edition como o mesmo software do on-premise, por isso ela segue o ciclo de releases on-premise. A SAP executa o upgrade técnico; planejamento, preparação, testes e as demais atividades não técnicas são do cliente ou do parceiro de implementação. Dentro do RISE with SAP, o cliente pode solicitar um upgrade por ano e precisa fazer ao menos um a cada sete anos para permanecer na manutenção principal.

A divisão de tarefas entre SAP e cliente está no documento oficial de Roles and Responsibilities da Private Edition. Ele funciona como catálogo: o que não foi contratado e se aplica ao ambiente fica sob responsabilidade do cliente. Administração e monitoramento de interfaces, como IDocs, qRFC, bgRFC e cenários ALE, aparecem como serviço adicional da SAP ou como tarefa do cliente.

Cloud Public Edition

A Public Edition recebe atualizações principais em fevereiro e agosto. O nome do release combina ano e mês: 2602 é o release de fevereiro de 2026, e 2608, o de agosto de 2026. A SAP aplica o upgrade primeiro no sistema de teste e depois nos sistemas de desenvolvimento e produção, segundo um calendário publicado. Entre os releases principais, entram funcionalidades menores que o cliente pode ativar antes; se não ativar, elas passam a valer no release principal seguinte.

Como a SAP atualiza todos os clientes em paralelo, a Public Edition não aceita modificação de objetos SAP. Extensões usam apenas APIs liberadas, pontos de extensão estáveis e tecnologias liberadas para nuvem. A extensibilidade de desenvolvedor, com ABAP Cloud, está disponível desde o release 2208 e exige paisagem de três sistemas.

O que muda para a manutenção em cada edição

O processo de manutenção no S/4HANA, com notas, ordens, operações, confirmações e planos preventivos, mantém a base conhecida do SAP PM. O nome que a SAP dá a essa área no S/4HANA e o que mudou no produto estão em SAP PM virou SAP EAM?. Os apps Fiori que cobrem o trabalho de planejamento e campo estão em SAP Fiori para manutenção.

A diferença entre edições aparece em três decisões de rotina:

• Calendário de regressão: no on-premise e na Private Edition, o cliente escolhe quando aplicar FPS e releases; na Public Edition, a data vem da SAP duas vezes por ano, e o teste das integrações de manutenção precisa caber nessa janela.
• Programas Z de PM: relatórios, validações e enhancements criados no ECC podem continuar no on-premise e na Private Edition, com análise de código customizado; na Public Edition, precisam ser reescritos com APIs liberadas, extensões de usuário-chave ou aplicações no BTP.
• Monitoramento de interfaces: na Private Edition, verifique no contrato se o monitoramento das interfaces de manutenção é serviço contratado da SAP ou tarefa da equipe interna, porque o padrão do catálogo deixa com o cliente o que não foi contratado.

Quem ainda está no ECC precisa olhar também os prazos da Business Suite 7: manutenção principal até o fim de 2027 e estendida opcional até o fim de 2030. O artigo O SAP PM acabou? detalha esse caminho, e a relação entre o banco HANA e o ERP está em SAP HANA: o que é e versões.

O que muda para integrações de mobilidade

Aplicativos de campo leem ordens e gravam confirmações, medições, notas e anexos no SAP. Cada uma dessas escritas depende de uma interface: OData, BAPI, serviço de integração ou API liberada. A edição do S/4HANA determina quais desses caminhos estão disponíveis e quem mantém cada um depois do go-live.

Pergunta ao fornecedor de mobilidade	Por que importa
Quais APIs ou serviços o aplicativo usa para ler e gravar cada objeto de manutenção?	Na Public Edition, só APIs liberadas pela SAP são aceitas; nas outras edições, a escolha afeta o esforço de upgrade
O aplicativo exige código instalado no back-end SAP?	Código no back-end é possível no on-premise e na Private Edition, mas entra na análise de cada upgrade e não é aceito como modificação na Public Edition
Quem testa a integração depois de um FPS ou release?	A SAP executa o upgrade técnico na nuvem, mas não testa os fluxos de campo do cliente
Como o aplicativo se comporta durante a janela de upgrade?	Técnicos offline precisam continuar trabalhando e sincronizar depois, sem perder apontamentos
Que releases e edições o fornecedor já atende em produção?	Compatibilidade declarada precisa ser demonstrada no release e na edição de destino

A SAP oferece o SAP Asset Manager como aplicativo móvel de manutenção, apresentado em SAP Asset Manager: o que é. Existem também camadas de execução de terceiros que trabalham sobre o SAP PM. O PM RUN, do Grupo ITSS, é uma delas: atende operações em SAP PM no ECC 6.0 e no S/4HANA, integra por OData, SAP PI/PO, SAP CPI ou REST e funciona offline, sincronizando com o SAP quando há conexão. Em cada projeto, a arquitetura de integração é definida com a edição e o release contratados e validada fluxo por fluxo. A página de mobilidade para SAP PM descreve o que o aplicativo executa no campo.