Se a sua empresa ainda roda integrações no SAP PI/PO, existe um ponto que já não dá mais para ignorar: o tempo. 

O SAP NetWeaver 7.5, base do Process Orchestration, tem fim de manutenção principal em dezembro de 2027. Depois disso, manter o ambiente ativo significa operar com riscos crescentes de segurança, compliance e suporte. 

Mas a migração para o SAP Integration Suite (SCPI) não é apenas uma resposta ao fim do suporte. É uma mudança estrutural na forma como as integrações são pensadas dentro do ecossistema SAP. 

Este artigo explica o que está em jogo e como conduzir esse movimento com estratégia. 

O que é o SAP PI/PO e por que ele ainda está em tantas empresas 

O SAP PI/PO (Process Integration / Process Orchestration) foi, por muitos anos, o middleware padrão do SAP. Ele centraliza integrações entre sistemas SAP e não-SAP, permitindo orquestrar processos, transformar mensagens e conectar diferentes aplicações. 

Na prática, ele virou o “hub invisível” de muitas operações críticas: 

• Integração entre SAP e sistemas legados 

• Comunicação com bancos, fornecedores e parceiros 

• Orquestração de processos entre módulos 

O problema é que, apesar de robusto, o PI/PO foi construído sobre uma arquitetura que já não acompanha as demandas atuais: 

• Forte dependência de infraestrutura on-premise 

• Baixa flexibilidade para APIs modernas 

• Complexidade de manutenção 

• Dificuldade de escalar integrações rapidamente 

Ainda assim, ele continua presente em muitas empresas porque “funciona” e porque substituí-lo sempre parece um projeto grande demais para priorizar. 

O que muda com o fim do suporte em 2027 

O fim da manutenção principal do SAP NetWeaver 7.5 muda completamente esse cenário. 

Não se trata apenas de uma atualização técnica. A partir de 2027, manter o PI/PO ativo significa: 

• Risco de segurança elevado (sem correções regulares) 

• Exposição a problemas de compliance 

• Dependência de soluções customizadas para suporte 

• Dificuldade crescente de encontrar especialistas 

Na prática, o custo de “não fazer nada” começa a superar o custo da migração. 

E existe um ponto adicional: empresas que já estão migrando para S/4HANA ou adotando BTP acabam ficando com uma arquitetura híbrida inconsistente, onde o middleware antigo vira gargalo. 

O que é o SAP Integration Suite (SCPI) e o que ele entrega além da substituição 

O SAP Integration Suite, conhecido como SCPI (SAP Cloud Platform Integration), é a evolução natural do PI/PO dentro da estratégia cloud da SAP. 

Mas tratar o SCPI como “o novo PI/PO” é reduzir demais o que ele entrega. 

Ele é uma plataforma de integração completa dentro do SAP BTP, com quatro pilares principais: 

• Cloud Integration (iFlows): substitui os cenários clássicos do PI/PO 

• API Management: publicação, governança e segurança de APIs 

• Event Mesh: comunicação baseada em eventos (event-driven architecture) 

• Open Connectors: integração simplificada com sistemas não-SAP 

Além disso, ele traz capacidades que não existiam no modelo anterior: 

• Integrações mais rápidas de construir e escalar 

• Uso nativo de APIs REST e eventos 

• Monitoramento centralizado em ambiente cloud 

• Menor dependência de infraestrutura própria 

Para entender como isso se conecta com a estratégia de dados, veja como o SAP Datasphere elimina extrações manuais e unifica informações do ERP.

Por que isso não é um “lift and shift”: é uma mudança de arquitetura 

Um dos erros mais comuns em projetos de migração é tratar o movimento como uma simples cópia do que já existe. 

No caso do PI/PO para SCPI, isso não funciona. 

A mudança envolve uma nova lógica de arquitetura: 

• De integrações baseadas em mensagens para integrações orientadas a APIs e eventos 

• De processamento centralizado para modelos mais distribuídos 

• De customizações pesadas para uso de serviços padrão 

Além disso, entra em jogo o conceito de Clean Core (evitar dependências excessivas dentro do ERP e deslocar extensões e integrações para o BTP). 

Isso exige decisões importantes: 

• Quais integrações devem ser migradas como estão 

• Quais devem ser redesenhadas 

• Quais podem ser eliminadas 

Entenda melhor como isso se conecta ao modelo de extensões no artigo sobre como ativar valor com SAP BTP sem tocar no core. 

E mais: muitas empresas aproveitam esse momento para revisar toda a estratégia de integração (não apenas trocar a tecnologia). 

Como a Coperty conduz a migração na prática 

A abordagem da Coperty parte de um princípio simples: migrar tudo como está é caro e não resolve o problema. 

Por isso, o processo é estruturado em etapas: 

1. Assessment técnico e funcional

Mapeamento completo das interfaces existentes no PI/PO: 

• Volume de mensagens 

• Criticidade 

• Tipo de integração 

• Dependências 

2. Classificação estratégica

Cada integração é enquadrada em um dos caminhos: 

• Migrar (com ajustes mínimos) 

• Redesenhar (aproveitando APIs e eventos) 

• Descontinuar (quando não faz mais sentido) 

3. Desenho da arquitetura alvo

Definição de como o Integration Suite será utilizado: 

• APIs vs iFlows 

• Eventos vs integrações síncronas 

• Uso de conectores padrão 

4. Execução em ondas

A migração não acontece de uma vez. Ela é feita em ciclos controlados, reduzindo risco operacional. 

5. Otimização contínua

Após a migração, o foco passa a ser performance, governança e escalabilidade. 

Esse modelo evita um erro comum: gastar energia migrando problemas antigos para uma plataforma nova. 

Esse tipo de abordagem também aparece em projetos como migração para nuvem sem conversão imediata para S/4HANA, onde a arquitetura é tratada de forma evolutiva , não como ruptura. 

Por onde começar? 

Se a sua empresa ainda está no PI/PO, o melhor momento para começar não é em 2027, é agora. 

Os primeiros passos são mais simples do que parecem: 

• Levantar o inventário de integrações atuais 

• Identificar as mais críticas para o negócio 

• Entender o uso atual (e real) do middleware 

• Avaliar o nível de adoção de BTP 

A partir disso, já é possível definir um roadmap claro — sem precisar iniciar um projeto grande imediatamente. 

E existe um ponto importante: a migração não precisa estar isolada. Ela pode (e deve) ser conectada com outras iniciativas, como: 

• Estratégia de dados 

• Modernização do ERP 

• Governança fiscal e regulatória 

Inclusive, mudanças regulatórias já estão pressionando integrações em áreas como compliance. Veja o que está mudando no artigo sobre transição de SAP GRC para DRC. 

A migração de SAP PI/PO para SCPI não é só uma atualização técnica. É uma decisão estratégica sobre como sua empresa vai integrar sistemas nos próximos anos. 

Esperar até o fim do suporte pode parecer confortável no curto prazo, mas aumenta o risco, o custo e a complexidade lá na frente. 

Começar agora permite fazer esse movimento com controle, priorização e ganho real de arquitetura. 

E, principalmente, evita um cenário comum: trocar a tecnologia… e continuar com os mesmos problemas. 

Fale com a Coperty e saiba como acelerar ainda mais projeto SAP. E se você curtiu este artigo, compartilhe-o e siga navegando pelo blog!