CPQ acabou? A hora certa de migrar para o Revenue Cloud, segundo a sua própria org

A pergunta que todo cliente de CPQ está fazendo

Toda semana alguém me pergunta alguma variação de: o CPQ morreu? Devo migrar para o Revenue Cloud agora? A resposta curta é que o CPQ continua funcionando, continua suportado e continua rodando operações de receita gigantes. A resposta honesta é que ele virou um produto sem futuro de investimento, e isso muda o cálculo de qualquer arquitetura nova.

O Salesforce CPQ nasceu como SteelBrick em 2010, foi adquirido em 2015 e virou o padrão de quoting do ecossistema. Hoje a Salesforce direciona toda a inovação de precificação, quoting e billing para o Revenue Cloud. Quem assina contrato novo já entra pela porta nova. Quem está no CPQ precisa decidir quando atravessar, e a pior forma de decidir isso é por pânico ou por hype.

O sinal que ninguém olha: o tipo de problema que o CPQ gera

Eu acompanho as perguntas da comunidade diariamente, e o padrão é revelador. Price Rule que não dispara na ordem esperada. Fórmula no Quote Line Editor que calcula em um salvamento e falha no seguinte. Twin Fields se multiplicando em orgs com 500 produtos. Customização de Quote Document brigando com Visualforce. Clone de cotação disparando erro de registro modificado.

Nenhum desses problemas é bug. É a arquitetura do CPQ operando no teto da própria complexidade. O motor de cálculo é uma caixa preta assíncrona, as regras competem entre si por ordem de avaliação, e cada solução vira uma camada a mais de acoplamento. Em projeto, eu já vi implementações em que ninguém conseguia mais prever o efeito de uma Price Rule nova sem testar em sandbox por dias.

Quando o custo de manter passa a crescer mais rápido que o valor de cada mudança, esse é o sinal. Não é a Salesforce dizendo que o CPQ acabou. É a sua própria org dizendo.

O que o Revenue Cloud muda de verdade

O Revenue Cloud não é um CPQ 2.0. É outra fundação, e é por isso que migração aqui significa reimplementação, não upgrade. Três mudanças estruturais importam mais que qualquer lista de features:

• Precificação declarativa e auditável. As Price Rules dão lugar a Pricing Procedures construídas em Expression Sets, com cada degrau do cálculo visível e testável via Simulate. Escrevi sobre essa mecânica no post do Pricing Waterfall: a lógica que antes vivia espalhada em dezenas de regras vira um pipeline explícito.
• Modelo de dados unificado. Produto, preço, cotação, pedido, contrato e billing conversam no mesmo ciclo, sem o fosso histórico entre o pacote gerenciado e o core. Mapeei essa cadeia no post dos seis objetos centrais do Revenue Cloud.
• API-first e pronto para agentes. Cotação, precificação e catálogo expostos como serviço, o que abre espaço para self-service, integração limpa e para o Agentforce atuar no ciclo de receita com governança.

Quando ainda não é hora de migrar

Também existe o outro lado, e ele merece a mesma honestidade. Se a sua operação de CPQ está estável, com regras sob controle, time treinado e roadmap comercial sem mudanças estruturais, migrar agora só para acompanhar o mercado é queimar orçamento. O CPQ segue suportado, e reimplementação de motor de receita não é projeto de três meses.

Nos projetos de migração em que atuei, o trabalho pesado não foi técnico, foi de arquitetura de negócio: em um deles, reduzimos mais de 90% das Price Rules simplesmente porque a maioria existia para contornar limitações do próprio CPQ. Migrar sem essa faxina é levar a dívida técnica de mudança.

Um roteiro prático para decidir

Se você opera CPQ hoje, três movimentos preparam a decisão sem comprometer nada:

• Inventarie as regras. Liste Price Rules, Product Rules e customizações de QLE, e classifique cada uma: regra de negócio real, workaround de limitação, ou código morto. Esse mapa é o tamanho verdadeiro da sua migração.
• Meça o custo de mudança. Quanto tempo leva hoje para implementar uma mudança de precificação de ponta a ponta, com teste? Se a resposta cresceu ano a ano, você tem um número, não uma opinião.
• Modele o catálogo no padrão novo. Catalog, Category, Product e atributos reutilizáveis. Mesmo antes de migrar, desenhar o catálogo no modelo do Revenue Cloud expõe onde seu produto atual está mal modelado.

Minha leitura

A pergunta certa não é se o CPQ morreu. É quanto tempo a sua operação aguenta crescer em cima de uma plataforma que não recebe mais inovação, e quanto vale entrar na próxima fundação com o catálogo limpo e as regras enxutas. Quem trata a migração como projeto de arquitetura de receita sai na frente. Quem trata como troca de ferramenta leva os mesmos problemas para um lugar novo, pagando mais caro pela mudança.