Em 9 de julho a Comissão Europeia encerrou a investigação sobre as políticas de manutenção e suporte on-premise da SAP, e a empresa anunciou maior flexibilidade nessas práticas — enquadrada explicitamente como apoiar o cliente a modernizar rumo à "empresa autônoma" no seu próprio ritmo. Some-se o que a CIO.com vinha apurando em campo: o prazo de 2027 está fora do alcance da maioria, e "a histeria atual vai passar".
Para quem toca o projeto, a leitura imediata é tentadora e quase automática: então dá pra empurrar. Muitos comitês de TI vão fazer exatamente essa conta neste mês.
Aqui está a armadilha. O que afrouxou foi o prazo de suporte. O que não afrouxou foi o custo de continuar como está — e esse custo não é de licença. É a dívida de integração, que é debitada todo mês, com ou sem projeto de migração em andamento.
1. O que a SAP anunciou e o que a decisão europeia mudou
É importante ler o anúncio pelo que ele é. A investigação da Comissão Europeia tratava das práticas de manutenção e suporte para clientes on-premise — o tipo de política que, na prática, limita a liberdade de escolha de quem sustenta o sistema e em que condições. Com o encerramento, a SAP assumiu compromissos de maior flexibilidade nessas práticas.
O que isso significa para o cliente: mais respiro para operar o ambiente atual sem ser forçado por uma cláusula de suporte a um cronograma que não é o seu. É uma boa notícia real, especialmente para empresas que estavam sendo empurradas para uma migração mal planejada por pressão contratual em vez de por decisão de negócio.
O que isso não significa: que o S/4HANA deixou de ser o destino, ou que o trabalho ficou menor. A própria SAP enquadra a flexibilidade como apoio à modernização — não como alternativa a ela. E o dado da CIO.com que circula junto com o anúncio diz outra coisa incômoda: se 2027 está fora de alcance para a maioria, isso não é um sinal de que o prazo era exagerado. É um sinal de quanto trabalho acumulado existe na base instalada.
2. O calendário que continua valendo
Antes de qualquer decisão de comitê, vale ter os marcos na mesa, porque eles são o que sobra quando a manchete passa:
S/4HANA 2022 — manutenção mainstream até 31/12/2027. Este é o marco mais próximo e o mais esquecido, porque afeta quem já migrou: estar no S/4HANA não é um estado final, é uma release com ciclo de vida própria.
Business Suite 7 — cobertura até 2027, com extensão até 2030. É o marco que a maioria das discussões chama simplesmente de "o prazo".
S/4HANA — compromisso de manutenção até 2040. É o horizonte que sustenta o argumento de que o destino não mudou.
Repare no que essa linha do tempo revela quando lida em conjunto: o intervalo entre "posso adiar" e "preciso ter terminado" é menor do que parece, porque a migração de uma empresa de porte não é um evento de alguns meses. É um programa de vários anos que inclui limpeza de dado, redesenho de processo, tratamento de customizações e — o item que este artigo defende ser o mais crítico — reconstrução das integrações. Ganhar dois ou três anos de suporte não é ganhar dois ou três anos de folga; é ganhar exatamente o tempo necessário para fazer bem o que seria feito mal.
3. Por que "dá pra empurrar" é a leitura errada
A dívida de integração não aparece em nenhum contrato de suporte. Ela aparece na operação, todo dia, em itens que os times já aceitaram como normais:
O pedido que concilia no braço. Alguém exporta uma planilha, compara com o ERP e corrige divergência — todo dia, ou toda semana. Esse custo é recorrente, escala com o volume e nunca entra no business case da migração porque está diluído em salário de gente que "sempre fez assim".
O estoque que chega ao site com atraso. Quarenta minutos de defasagem entre o ERP e a vitrine significa venda de item que já não existe, cancelamento, reembolso e atendimento. Em data de pico, significa isso multiplicado. É receita perdida com precisão mensurável — e ninguém mede.
O customizado que ninguém documentou. A modificação feita há oito anos por um consultor que não trabalha mais lá, que ninguém sabe se ainda é usada, e que trava qualquer tentativa de padronizar o núcleo. É o assunto do clean core, e ele não é ideologia de fornecedor: código customizado no núcleo é exatamente o que impede um agente de IA de operar com segurança sobre o ERP.
A IA que fica pra fase 2. A consequência de tudo acima. Sem dado padronizado e sem integração confiável, a camada de inteligência é a primeira coisa cortada do escopo — e a "fase 2" raramente ganha orçamento próprio.
Nenhum desses quatro itens tem qualquer relação com o prazo de suporte. Eles continuam custando com o ECC, com o Business Suite 7, com o S/4HANA e com o que vier depois. Adiar a migração não adia nada disso — apenas adia o momento em que a empresa para de pagar por eles.
E há um efeito composto. Cada mês de operação sem integração estruturada gera mais divergência de dado, mais rotina manual institucionalizada e mais customização criada para contornar a falta de integração — que é justamente o que tornará a migração futura mais cara. É por isso que migração adiada com integração adiada não é fôlego: é juros compostos.
4. Como usar a janela extra: integrar agora, no ERP atual
A leitura correta da flexibilidade é o oposto de empurrar. Se você ganhou prazo, ganhou a única coisa que faltava para fazer a migração direito: tempo para pagar a dívida de integração antes do swap.
Isso é contraintuitivo para muitos comitês, que assumem que integração é trabalho a ser feito durante a migração, no sistema novo. Na prática, é o contrário: integração feita no ERP atual, com arquitetura event-driven e contratos de API bem definidos, tem três propriedades que a tornam o investimento certo para uma janela de espera.
Ela paga sozinha, antes da migração. Eliminar conciliação manual e reduzir a defasagem de estoque gera retorno imediato, no ambiente atual, independentemente de quando o S/4HANA entrar.
Ela é transferível. Uma camada de integração desenhada com contrato de API e eventos não está acoplada ao ERP de origem. Quando o sistema de registro muda, o que muda é o conector — não o modelo de eventos, não a fila, não os consumidores, não o e-commerce. É exatamente o oposto de uma integração ponto a ponto, que precisa ser refeita inteira.
Ela reduz o risco do go-live. A migração de quem chega com integração desacoplada é uma troca de fornecedor de dado. A de quem chega com integração ponto a ponto é uma reconstrução simultânea de tudo, no pior momento possível.
Foi essencialmente essa a lógica de casos como o da Samsung, que investiu tempo considerável integrando e padronizando processos antes de migrar, e atravessou o corte em uma fração do prazo que empresas comparáveis levaram. A maioria não faz isso — não por desconhecimento, mas porque, sem uma janela de prazo, tudo o que não é essencial ao go-live é cortado. Agora existe janela. A pergunta é o que será feito com ela.
5. Como a CCX faz: diagnóstico, TCO comparativo e integração event-driven
A CCX entra nessa janela por duas frentes que se sustentam.
A primeira é a de Consultoria em Tecnologia: avaliação da infraestrutura, arquitetura e processos atuais, com entregáveis objetivos — diagnóstico, arquitetura-alvo, roadmap, TCO comparativo e plano de migração. A recomendação é feita por contexto, não por plataforma: a CCX opera SAP, Salesforce, VTEX, Shopify, Adobe, MuleSoft e stack open-source, e não tem incentivo para empurrar um destino específico. O TCO comparativo é a peça que muda a conversa no comitê, porque coloca lado a lado o custo de migrar agora, o de migrar depois e — o número que quase nunca é calculado — o custo de continuar como está pelos próximos 24 meses, com conciliação manual, defasagem de estoque e retrabalho incluídos.
A segunda é a execução em Integrações & APIs Enterprise: conectividade via REST, GraphQL e gRPC e arquitetura event-driven com Kafka e RabbitMQ, incluindo SAP ↔ e-commerce e Protheus ↔ e-commerce com sincronização de estoque, preço, pedido e nota fiscal, além de consultoria MuleSoft (Anypoint, API-led connectivity) para quem já padronizou por ali. É esse trabalho que substitui a planilha de conciliação por reconciliação automática e os quarenta minutos de defasagem por evento propagado em segundos.
Quando o gargalo é capacidade — e em ano de migração ele quase sempre é —, entram as squads dedicadas: engenheiros sêniores com onboarding em 48h e escala elástica, que assumem a frente de integração sem tirar do time interno as pessoas que precisam estar no núcleo da migração. Tudo dentro de uma metodologia de discovery, arquitetura-alvo, sprints, QA, go-live assistido e evolução.
Ganhou prazo na migração do S/4HANA? A CCX usa essa janela para integrar SAP ↔ e-commerce event-driven no ERP atual — assim você chega no swap com a fundação pronta, não com a dívida dobrada. Integrar SAP ao seu e-commerce →
6. FAQ
A SAP adiou o prazo de 2027?
Não. O que foi anunciado, após o encerramento da investigação da Comissão Europeia em 09/07, foi maior flexibilidade nas práticas de manutenção e suporte on-premise. Os marcos de calendário seguem como referência: Business Suite 7 com cobertura até 2027 e extensão até 2030, S/4HANA até 2040, e S/4HANA 2022 com manutenção mainstream até 31/12/2027.
Se o prazo afrouxou, posso congelar o projeto?
Pode — e é exatamente a decisão que costuma sair mais cara. O prazo de suporte é uma das variáveis, não a única. Conciliação manual de pedido, defasagem de estoque no e-commerce, customizações não documentadas e IA em "fase 2" continuam custando todo mês. Congelar o projeto sem endereçar esses itens transfere o custo para frente com juros.
Faz sentido investir em integração num ERP que vou trocar?
Faz, desde que a integração seja desacoplada. Uma camada event-driven com contratos de API bem definidos não pertence ao ERP de origem: quando o sistema de registro muda, troca-se o conector e o restante — modelo de eventos, fila, consumidores, e-commerce — permanece. Integração ponto a ponto, essa sim, é jogada fora na migração.
Por onde começar se o comitê acabou de ganhar fôlego?
Por um diagnóstico curto que produza três números: quanto custa hoje a operação manual em volta do ERP, qual a latência real de cada integração crítica, e qual o TCO comparativo entre migrar agora, migrar depois e continuar como está. Com esses três números, a decisão sobre a janela deixa de ser opinião de comitê.
O clean core tem a ver com isso?
Diretamente. Customização no núcleo é a principal razão pela qual migrações estouram prazo e pela qual agentes de IA não conseguem operar sobre o ERP com segurança. Usar a janela para mover lógica customizada para fora do núcleo, atrás de APIs e eventos, é a mesma obra que reduz o custo da migração e habilita a camada de inteligência depois.