Tem uma configuração no Salesforce CPQ que a maioria das equipes técnicas deixa passar até que o problema apareça em produção: o modelo de renovação. Especificamente, a diferença entre o Legacy Renewal Service e o Upgraded Renewal Model — e o que acontece quando você cresce operando com o legado.
Já acompanhei renovações de contrato travando em produção porque a lógica estava espalhada entre Triggers, Process Builders obsoletos e uma Opportunity-mãe que ninguém mais sabia de onde tinha vindo. O sistema funcionava — até o volume escalar. Então parou de funcionar exatamente quando a equipe de Customer Success estava tentando fechar o trimestre.
Esse cenário tem endereço: é o Legacy Renewal Service.
O que é o Legacy Renewal Model e por que ele ainda existe?
O Legacy Renewal Service foi o modelo original de renovações do Salesforce CPQ. Ele funciona criando uma nova Opportunity de renovação baseada na oportunidade original — um processo que parecia intuitivo quando o CPQ tinha volumes menores e menos complexidade.
Com o tempo, dois problemas se tornaram evidentes:
Primeiro: o modelo depende de uma cadeia de objetos (Opportunity → Quote → Order → Contract) que, quando tem customizações no meio do caminho, vira um sistema frágil. Cada Trigger, cada Process Builder, cada campo personalizado adicionado ao longo dos anos cria um ponto de possível falha no próximo ciclo de renovação.
Segundo: o modelo não escala bem. Com centenas ou milhares de contratos renovando simultaneamente, os limites de governador do Salesforce são atingidos com mais frequência, e a performance degrada de forma previsível.
O motivo pelo qual ainda existe em muitas orgs: porque funcionou. Quem implementou o CPQ há quatro ou cinco anos configurou o Legacy, as renovações saíram andando, e ninguém teve incentivo para mexer no que estava "funcionando" — até o momento em que deixou de funcionar.
Por que o Upgraded Renewal Model é diferente — e melhor
O Upgraded Renewal Model muda a lógica fundamental. Em vez de criar renovações baseadas em Opportunities antigas, ele trabalha com Assets e Subscriptions — os objetos que representam o que o cliente realmente possui, desacoplados da oportunidade original que gerou a venda.
Essa mudança de paradigma tem consequências práticas importantes:
Rastreabilidade real de ativos do cliente. Você sabe, em tempo real, o que cada cliente está usando, quando vence, qual é o preço de renovação e se há oportunidades de upsell. No modelo legado, essa visão dependia de conseguir navegar pela cadeia de oportunidades e contratos — o que em orgs com muito customização vira um exercício de arqueologia.
Automação via Flow, não via Trigger. O Upgraded Model foi projetado para funcionar com Flows declarativos, não com código customizado. Isso significa menos dependência de desenvolvedores para manutenção, menos pontos de falha silenciosa e mais facilidade de auditoria. Um Flow tem log de erros; um Trigger customizado pode falhar silenciosamente se não tiver tratamento de erro adequado.
Alinhamento com o roadmap da Salesforce. Com o CPQ em End of Sale desde março de 2025, a Salesforce não está mais investindo no modelo legado. O Upgraded Renewal Model é o que recebe melhorias, otimizações de performance e integração com Revenue Cloud. Continuar no Legacy é continuar em uma trilha que está sendo gradualmente abandonada.
Performance em escala. O modelo baseado em Assets/Subscriptions tem overhead muito menor nos limites de governador. Orgs com volume alto de renovações simultâneas sentem essa diferença na prática.
| Legacy Renewal | Upgraded Renewal | |
|---|---|---|
| Objeto base | Opportunity antiga | Asset / Subscription |
| Automação | Triggers e Apex | Flow declarativo |
| Escalabilidade | Limitada | Alta |
| Manutenção | Requer desenvolvedor | Admin pode manter |
| Roadmap Salesforce | End of Sale | Alinhado e em evolução |
| Integração Revenue Cloud | Frágil | Nativa |
A migração: o que realmente acontece
Aqui está o que ninguém te conta na documentação: migrar do Legacy para o Upgraded Renewal Model não é um toggle que você ativa. É uma migração de dados e de lógica que exige planejamento cuidadoso.
O que precisa acontecer nos dados:
Os objetos de Asset e Subscription precisam estar populados corretamente antes de qualquer migração. Em muitas orgs legadas, esses objetos existem mas não estão completos — porque a lógica de criação de assets estava inconsistente, ou porque foram criados manualmente em algum momento, ou porque integrações externas alimentaram os dados de forma errada.
Isso significa que, antes de ativar o Upgraded Model, você precisa fazer um inventário completo dos seus Assets e Subscriptions: datas de início e fim consistentes, produtos associados corretamente, preços de renovação configurados nos produtos, vinculação correta com os Contracts ativos.
O que precisa acontecer no código:
Toda lógica customizada de renovação precisa ser mapeada. Isso inclui:
·Triggers em Opportunity, Quote, Order ou Contract que manipulam o processo de renovação
·Apex classes que calculam preço de renovação, aplicam descontos ou copiam campos
·Process Builders (especialmente os criados antes do Flow) que ainda estão ativos
·Integrações externas (ERP, sistemas de billing, ferramentas de CS) que dependem do fluxo de renovação legado
Cada um desses pontos precisa ser avaliado: o comportamento precisa ser recriado em Flow? Pode ser eliminado porque o Upgraded Model já faz isso nativamente? Precisa de adaptação para o novo modelo de dados?
O que precisa acontecer no processo de negócio:
A equipe de Customer Success e de Vendas precisa entender como o novo modelo funciona — especialmente se o processo atual envolve steps manuais para criar renovações. O Upgraded Model pode automatizar mais, mas exige que as pessoas saibam o que esperar.
Checklist técnico completo de prontidão
Dados e configuração:
·Assets estão sendo criados corretamente a partir de Orders aprovadas?
·Subscriptions têm datas de início e fim preenchidas e consistentes com os Contracts?
·Produtos têm preço de renovação configurado (Renewal Pricing Method)?
·Discount Schedules de renovação estão documentadas e refletidas nos produtos?
·Products com Subscription Pricing têm Subscription Term configurado?
·Contracts ativos têm quantidade, preço e período corretos para gerar renovações precisas?
Código e automações:
·Inventário completo de Triggers relacionados a: OpportunityLineItem, QuoteLine, Asset, Subscription, ContractLineItem
·Process Builders ativos que interagem com qualquer objeto no ciclo de renovação
·Apex classes com lógica de renovação — documentadas e com testes unitários?
·Integrações: quais sistemas externos recebem eventos do processo de renovação?
·QCP (Quote Calculator Plugin) tem lógica relacionada a renovações?
Processo e negócio:
·Documentação do processo atual de renovação — quem faz o quê, quando, com que ferramentas
·KPIs de renovação definidos: taxa de renovação, ARR em risco, tempo médio de ciclo de renovação
·Casos de borda mapeados: co-termos, upgrades mid-term, cancelamentos parciais, renovações com mudança de produto
·Plano de comunicação para equipes impactadas
Ambiente de testes:
·Sandbox com dados representativos — especialmente os casos mais complexos da produção
·Plano de testes para os top-10 cenários de renovação mais críticos
·Critérios de sucesso definidos antes de começar os testes
Os riscos que merecem atenção especial
Renovações duplicadas no período de transição. Se a migração não for feita com uma estratégia de cutover clara, você pode acabar com renovações criadas pelo modelo legado E pelo modelo novo para o mesmo contrato. A definição de "a partir de quando o novo modelo assume" precisa ser explícita e comunicada.
Perda de lógica de precificação customizada. Se alguém implementou no Trigger uma regra do tipo "se o cliente está no segmento X, aplica desconto Y na renovação", essa lógica não migra automaticamente. Ela precisa ser recriada no Flow ou nas regras de preço antes de desligar o modelo legado.
Integrações quebradas. Sistemas externos que consumiam eventos de criação de Opportunity de renovação podem parar de funcionar se o novo modelo não gerar os mesmos eventos. Isso inclui ferramentas de CS, sistemas de forecasting e ERPs integrados.
Comportamento inesperado em casos de borda. Renovações parciais, cancelamentos mid-term, upgrades retroativos, contratos com múltiplas moedas — esses cenários precisam ser testados explicitamente, não assumidos como funcionando.
A abordagem que funciona na prática
A abordagem recomendada é o que chamamos de "bridge" — um período de transição em que você garante que os dados do Upgraded Model estão corretos antes de desativar o Legacy.
Fase 1 — Assessment (2-4 semanas): Levantamento completo de Assets, Subscriptions, Triggers, Flows e integrações. Identificação de gaps de dados. Definição do backlog de remediação.
Fase 2 — Remediação de dados (2-8 semanas): Correção de Assets e Subscriptions inconsistentes. Garantia de que novos contratos estão sendo criados corretamente antes de avançar.
Fase 3 — Migração de lógica (3-6 semanas): Recriação de customizações críticas em Flow ou regras declarativas. Testes unitários e de integração.
Fase 4 — Piloto em sandbox (2-3 semanas): Testes com dados representativos. Validação dos casos mais críticos com as equipes de CS e Vendas.
Fase 5 — Produção em fases: Ativar para contratos novos primeiro. Validar por 30-60 dias. Depois migrar contratos existentes com monitoramento próximo.
Perguntas frequentes sobre migração do Legacy para Upgraded Renewal Model
Qual a diferença prática entre Legacy e Upgraded Renewal Model no CPQ?
O Legacy Renewal cria renovações baseadas em Opportunities antigas, enquanto o Upgraded Renewal usa Assets e Subscriptions — objetos que representam o que o cliente possui de fato. O resultado prático: o Upgraded Model é mais escalável, mais transparente e mais integrado com o restante da plataforma Salesforce.
A migração para Upgraded Renewal Model é obrigatória?
Não há uma deadline obrigatória apenas para a mudança do modelo de renovação. Mas com o CPQ em End of Sale desde março de 2025, manter o modelo legado significa continuar em infraestrutura sem evolução de produto — e com gap crescente em relação ao Revenue Cloud.
Quanto tempo leva a migração do Legacy para o Upgraded Renewal Model?
Depende muito do estado da org: volume de customizações, consistência dos dados de Asset e Subscription, e complexidade das integrações. Orgs simples podem fazer em 6-8 semanas. Orgs com muito código customizado e integrações complexas ficam em 4-6 meses.
O Upgraded Renewal Model precisa de Revenue Cloud?
Não — o Upgraded Renewal Model é uma funcionalidade do Salesforce CPQ. O Revenue Cloud Advanced tem seu próprio modelo de renovação nativo. São coisas diferentes, embora o Upgraded Model seja um passo na direção da arquitetura do Revenue Cloud.
Quais dados precisam ser corrigidos antes de migrar?
Principalmente Assets e Subscriptions: datas de início/fim consistentes, vínculo correto com Contracts, produtos associados corretamente e preços de renovação configurados. Gaps nesses dados geram renovações incorretas no novo modelo.
O que acontece com renovações em andamento durante a migração?
A recomendação é não migrar contratos que estão em ciclo de renovação ativo — esperá-los fechar e migrar em um período de menor movimentação, com monitoramento próximo nos primeiros ciclos.
