Faltam pouco mais de 18 meses. O suporte mainstream ao SAP ECC 6 termina em 31 de dezembro de 2027, e o mercado brasileiro está entrando no que integradores como a Tivit descrevem como o "pico de procura" por migrações para o S/4HANA. O detalhe incômodo é que, segundo os mesmos levantamentos, apenas cerca de 30% dos clientes SAP no Brasil estão hoje em processo de migração. Os outros 70% ainda estão decidindo, orçando ou torcendo.
Prazo apertado somado a demanda concentrada produz um efeito bem conhecido em qualquer mercado de serviços: consultor sênior escasso, hora mais cara, cronograma comprimido. Quem começa em 2027 não migra — improvisa em cima do sistema que sustenta faturamento, fiscal, estoque e pedido. Este artigo é sobre por que 2026 é a última janela confortável e, principalmente, sobre o ponto cego que faz projetos de S/4HANA descarrilarem: as dezenas de integrações penduradas no ECC.
O prazo real: o que acontece em 31/12/2027
Encerrado o suporte mainstream, o ECC não desliga. Ele continua rodando — e é exatamente por isso que a armadilha é tão fácil de cair. O que muda é o entorno:
Correções e patches. Sem manutenção regular, falhas descobertas depois do prazo não são corrigidas na linha padrão. A cada trimestre, o sistema que roda o seu faturamento acumula mais dívida técnica não endereçada.
Compliance fiscal. Este é o ponto crítico no Brasil, e é o que costuma acordar o conselho. A legislação tributária brasileira muda todo ano — e a reforma tributária em curso vai exigir adaptações relevantes nos próximos exercícios. Um ERP fora de suporte é um ERP cuja aderência fiscal passa a depender de contratos de suporte estendido, de customização própria ou de terceiros. Nenhuma das três opções é barata, e a última é arriscada.
Custo de suporte estendido. Existe, e é uma saída legítima para ganhar fôlego — mas é um cheque anual sem construção de futuro. Você paga para adiar, não para evoluir.
Ou seja: 31/12/2027 não é uma data em que algo explode. É a data em que o custo de não ter decidido começa a ser cobrado, todo mês, para sempre.
Por que o pico de 2026 encarece quem espera
A conta que quase ninguém faz na hora de adiar é a de capacidade de mercado. O Brasil tem uma base grande de clientes SAP e um número finito de consultores S/4HANA sêniores, com experiência real em migração de core, conhecimento de localização fiscal brasileira e capacidade de conduzir cutover. Quando 70% da base tenta migrar na mesma janela de 18 meses, três coisas acontecem ao mesmo tempo:
A hora sobe. Demanda concentrada com oferta rígida: é economia básica. O mesmo escopo contratado em 2026 e em 2027 tem preços diferentes, e a diferença não é pequena.
O time sênior fica alocado. Os melhores profissionais são fechados primeiro. Quem contrata tarde não recebe o mesmo squad — recebe o squad que sobrou, muitas vezes com pessoas em ramp-up no cliente.
O cronograma comprime. Uma migração de core que caberia confortavelmente em 12 a 18 meses passa a ser vendida em 8. E projeto de ERP comprimido não corta escopo de ERP — corta teste, corta paralelo, corta o cutover ensaiado. É exatamente onde os acidentes acontecem.
Há ainda um efeito de segunda ordem: quanto mais tarde você entra, menos poder de negociação tem, porque o prazo passa a ser seu problema, não do fornecedor.
O ponto cego: as integrações penduradas no ECC
Pergunte a um CIO quantas integrações estão penduradas no ECC hoje. A resposta honesta, em quase toda operação de médio e grande porte, é: "não sei exatamente". E é aí que mora o risco real do projeto — muito mais do que na conversão do banco de dados.
Um ECC maduro, depois de dez ou quinze anos de operação, tipicamente conversa com:
• a plataforma de e-commerce (preço, estoque, pedido, status de entrega, nota fiscal);
• o WMS e a operação logística;
• os marketplaces (via middleware ou hub);
• o PIM e o cadastro de produto;
• os sistemas fiscais e o emissor de NF-e;
• o CRM e as ferramentas de marketing;
• meios de pagamento, antifraude, gateways;
• além de um punhado de rotinas em RFC, iDoc e batch escritas por gente que não trabalha mais lá.
Essas integrações costumam ser fortemente acopladas ao modelo de dados do ECC. Elas leem tabelas, chamam RFC específicas, esperam formatos de iDoc, dependem de campos customizados criados em 2013. Quando o core muda — e o S/4HANA muda estrutura de dados, muda tabelas, simplifica modelos — cada uma dessas conexões vira uma incógnita.
É por isso que a pergunta certa antes de qualquer projeto de S/4HANA não é "brownfield ou greenfield". É: o que exatamente quebra na loja, no marketplace, no fiscal e no WMS quando eu mexer no core? Migrar o ERP sem essa resposta mapeada não é um risco técnico. É um apagão de operação anunciado, na semana em que ninguém pode parar de vender.
Brownfield, greenfield ou "ECC na nuvem + Joule": escolhendo o caminho
Brownfield (conversão do sistema existente). Leva a base atual — customizações, histórico e vícios — para o S/4HANA. É o caminho mais rápido e o de menor ruptura para o usuário final. Serve para quem tem processo estável, dívida técnica administrável e prioridade de prazo. O risco é carregar para o novo core a bagunça acumulada, incluindo integrações mal documentadas.
Greenfield (implementação nova). Reimplanta processos do zero, aproveitando modelos padrão. Serve para quem tem processos desalinhados, muitas customizações inúteis, ou está passando por fusão/reestruturação. Custa mais, demora mais, exige gestão de mudança séria — e é a única forma de realmente limpar a casa.
Abordagem híbrida / seletiva. Migra por empresa, por país ou por linha de negócio, mantendo o resto em ECC por um período. Reduz risco de big bang e é comum em grupos com múltiplas unidades.
Uma nota sobre a discussão do momento: rodar o ECC em nuvem e plugar camadas de IA (do tipo copiloto de ERP) não é uma alternativa à migração. É uma forma de melhorar a vida no interinato. O relógio do suporte não para porque o ERP mudou de datacenter.
E, independentemente do caminho escolhido, o trabalho de integração precisa acontecer. É a única parte do projeto que é obrigatória nos três cenários.
Como a CCX ajuda: inventário de integrações e camada event-driven antes de tocar no core
A CCX não é uma consultoria de conversão de ERP — e é justamente por isso que somos chamados. Nosso trabalho está na fronteira onde o SAP encontra o resto do negócio: integração SAP ↔ e-commerce, Protheus ↔ e-commerce, marketplace, WMS e fiscal, com expertise em OData, iDocs e RFC (§23 do nosso portfólio) e uma prática consolidada de Integrações & APIs Enterprise em arquitetura event-driven com Kafka e RabbitMQ (§13).
A sequência que recomendamos — e executamos — tem três movimentos:
1. Inventário. Mapear cada integração pendurada no ECC: quem chama, com que frequência, por qual protocolo, qual o dono do dado, o que acontece se ela cair por 4 horas. Ao fim, você tem um mapa de risco real do projeto de migração — normalmente com o dobro de integrações que o time achava que existia.
2. Desacoplar. Reconstruir o acoplamento em uma camada de eventos e APIs governadas: o e-commerce deixa de ler tabela do ERP e passa a consumir eventos de preço, estoque e pedido, com idempotência e retry. É o que blinda a loja quando o core se mexe — e o que permite migrar por fatias em vez de big bang.
3. Migrar o core. Aí sim, com a periferia isolada, a conversão do ERP acontece sem que cada mudança de tabela vire um incidente na loja.
Para operações que não têm gente sobrando para essa frente — o caso mais comum, porque o time interno já está tomado pelo próprio projeto de S/4HANA — nossas squads dedicadas entram com onboarding em 48h e engenheiros sêniores (média de 10+ anos), em regime elástico (§10).
Antes de migrar o core, mapeie o que está pendurado nele. É a diferença entre um projeto planejado e um cutover na sexta à noite com o e-commerce fora do ar.
Integrar SAP ao seu e-commerce →
FAQ
O que exatamente acaba em 31/12/2027?
O suporte mainstream do SAP ECC 6. O sistema continua funcionando, mas sem manutenção padrão — o que na prática significa risco crescente de compliance fiscal e dependência de suporte estendido pago.
Ainda dá tempo de começar em 2027?
Tecnicamente sim, mas em condições ruins: consultor escasso, hora cara e cronograma comprimido. Uma migração de core saudável costuma levar de 12 a 18 meses em operações médias — comprimir isso significa cortar teste e ensaio de cutover, que são justamente os itens que evitam parada de operação.
Preciso resolver as integrações antes de escolher brownfield ou greenfield?
Não precisa resolver, mas precisa mapear. O inventário de integrações é uma das entradas que determinam qual caminho é viável e quanto ele custa de verdade.
Rodar o ECC em nuvem me dá mais prazo?
Não. Muda a infraestrutura, não o ciclo de vida do software. É útil como ponte, não como destino.