- Migrer de Salesforce CPQ vers Revenue Cloud Advanced (RCA) n'est pas une mise à jour : c'est une ré-implémentation sur le modèle de données natif de Salesforce.
- Salesforce oriente désormais les nouveaux clients vers Revenue Cloud Advanced ; les clients CPQ existants ont intérêt à planifier la migration plutôt qu'à la subir.
- Le bon moment : avant une refonte du catalogue, un changement de modèle (passage à l'abonnement ou à l'usage) ou quand la dette technique CPQ freine les équipes.
- Le point le plus délicat est la reprise des contrats et abonnements actifs en actifs Revenue Cloud, pour que amendements et renouvellements fonctionnent dès le premier jour.
- Une migration se mène par étapes : audit CPQ, re-modélisation, pricing, cycle de vie, facturation, reprise, coexistence, bascule.
Beaucoup d'entreprises ont déployé Salesforce CPQ, parfois avec Salesforce Billing, entre 2015 et 2023. Ces installations fonctionnent, mais elles ont souvent accumulé des price rules, des product rules, un Quote Calculator Plugin et des développements Apex que plus personne n'ose toucher. Revenue Cloud Advanced change la donne. Ce guide explique comment aborder la migration, sur la base de notre expérience des deux mondes chez Meir IT (certifications CPQ Specialist et Revenue Cloud Consultant).
Pourquoi migrer de Salesforce CPQ vers Revenue Cloud Advanced ?
Revenue Cloud Advanced (RCA) est la suite quote-to-cash native de Salesforce, désormais commercialisée sous le nom Agentforce Revenue Management. Elle remplace progressivement Salesforce CPQ dans la stratégie de l'éditeur. Les raisons de migrer sont à la fois stratégiques et opérationnelles :
- Trajectoire produit : Salesforce oriente désormais les nouveaux clients vers Revenue Cloud Advanced et concentre l'innovation (dont Agentforce) sur la plateforme native. Rester sur CPQ revient à rester sur une branche qui évoluera peu.
- Modèle de données standard : devis, commandes et actifs reposent sur les objets standard de Salesforce, ce qui simplifie les rapports, les intégrations et l'usage de Data 360 ou d'agents IA.
- Pricing plus maintenable : procédures de tarification et tables de décision au lieu d'un empilement de price rules et de code JavaScript.
- Configurateur à contraintes : plus lisible que des dizaines de product rules pour un catalogue complexe.
- Orchestration native : le Dynamic Revenue Orchestrator (DRO) gère l'après-vente, là où CPQ demandait des développements spécifiques.
Pour une présentation complète des composants, voir notre guide Revenue Cloud, RCA, RCB et ARM.
Est-ce une mise à jour ou une nouvelle implémentation ?
C'est le point à comprendre avant tout : il n'existe pas de bouton « upgrade » de CPQ vers RCA. Salesforce CPQ vit dans un package géré (espace de noms SBQQ, et blng pour Billing) avec ses propres objets : Quote, Quote Line, Subscription, Price Rule… Revenue Cloud Advanced utilise d'autres objets, d'autres moteurs et d'autres logiques. Les deux peuvent coexister dans la même org, mais la configuration CPQ ne se « convertit » pas.
En pratique, une migration consiste à :
- reconstruire le catalogue, les prix et les règles dans RCA, en profitant de l'occasion pour simplifier ;
- reprendre les données vivantes (contrats, abonnements, actifs, éventuellement devis en cours) dans le nouveau modèle ;
- adapter les intégrations, les rapports, les automatisations et les documents ;
- former les équipes à de nouveaux écrans et de nouveaux réflexes.
C'est une vraie réimplémentation, mais rarement une page blanche : vos règles métier, votre catalogue et votre historique sont une excellente spécification, à condition d'être audités.
Quand faut-il migrer ?
Il n'y a pas de date unique valable pour tout le monde. Les signaux qui indiquent que le moment est venu :
- vous prévoyez de refondre votre catalogue ou votre politique tarifaire ;
- vous passez à un modèle par abonnement ou à l'usage que CPQ gère mal dans votre configuration actuelle ;
- le temps de calcul des gros devis devient pénalisant, ou le Quote Calculator Plugin est devenu une boîte noire ;
- vous souhaitez internaliser la facturation dans Salesforce (RCB) ou remplacer Salesforce Billing ;
- vous lancez un projet Agentforce et voulez que les agents s'appuient sur des données de devis et d'actifs propres.
À l'inverse, si votre CPQ est stable, simple et sans projet d'évolution à court terme, une migration précipitée n'apporte pas grand-chose. Mieux vaut alors la préparer sereinement : nettoyer le catalogue, documenter les règles, fiabiliser les données d'abonnement.
Les étapes d'une migration CPQ vers Revenue Cloud
- Audit de l'existant CPQ : inventaire des produits, bundles, features, options, price rules, product rules, champs de résumé, QCP, Apex, flows, modèles de documents, intégrations. On classe chaque élément : à reprendre, à simplifier, à abandonner.
- Cadrage cible : quels processus dans RCA, lesquels dans RCB ou dans l'ERP ; quels utilisateurs, quelles entités.
- Re-modélisation du catalogue dans Product Catalog Management : attributs, classifications, bundles. Souvent, des dizaines de produits CPQ quasi identiques deviennent un produit avec attributs.
- Pricing : traduction des price rules et des remises en procédures de tarification et tables de décision.
- Configuration : traduction des product rules en contraintes du configurateur.
- Devis, validations et documents : processus d'approbation, modèle de PDF.
- Cycle de vie : commandes, contrats, actifs, amendements, renouvellements, orchestration DRO si nécessaire.
- Facturation : migration de Salesforce Billing vers RCB, ou adaptation de l'interface ERP. Voir notre article sur Revenue Cloud Billing.
- Reprise de données : contrats et abonnements actifs transformés en actifs Revenue Cloud, avec dates, quantités et prix cohérents.
- Recette et coexistence : tests sur des cas réels (nouvelle vente, upsell, renouvellement, résiliation), puis bascule par périmètre (une entité, une gamme, une équipe).
Correspondance des principaux concepts
| Dans Salesforce CPQ | Dans Revenue Cloud Advanced | Point d'attention |
|---|---|---|
| Produits, features, options | Product Catalog Management (produits, attributs, bundles) | Occasion de réduire le nombre de références |
| Price rules, block pricing, QCP | Procédures de tarification, tables de décision | Le code JavaScript du QCP doit être ré-analysé, pas traduit ligne à ligne |
| Product rules | Règles du configurateur (contraintes) | Logique différente : raisonner en contraintes |
| Quote et Quote Lines du package | Objets standard Quote et Quote Line Item | Rapports et intégrations à repointer |
| Contrats et Subscriptions | Contrats et Assets avec historique | Cœur de la reprise de données |
| Salesforce Billing | Revenue Cloud Billing (RCB) | Bascule à caler sur un cycle de facturation |
Les pièges les plus fréquents
- Vouloir tout reproduire à l'identique. Une migration qui recopie dix ans de règles CPQ dans RCA transporte la dette technique. Chaque règle doit justifier sa place.
- Sous-estimer la reprise des abonnements. Si les actifs repris sont faux (dates de fin, prix, co-terminaison), le premier renouvellement le révélera devant le client.
- Oublier l'écosystème : modèles de documents, signature électronique, rapports, tableaux de bord, intégrations ERP, automatisations qui lisent les objets SBQQ.
- Basculer la facturation en milieu de cycle sans plan de rapprochement : prévoyez une date de bascule propre et un contrôle des premiers runs de facturation.
- Négliger la conduite du changement : les commerciaux changent d'écran de saisie. Une formation courte et des cas pratiques valent mieux qu'un long manuel.
Checklist de migration
- ☐ Inventaire complet de la configuration CPQ (règles, QCP, Apex, flows, documents)
- ☐ Liste des intégrations qui lisent ou écrivent dans les objets CPQ / Billing
- ☐ Catalogue cible validé par les ventes et la finance
- ☐ Règles de prix et de remise documentées, avec cas de test chiffrés
- ☐ Stratégie de reprise des contrats et abonnements actifs, avec contrôles de cohérence
- ☐ Décision sur la facturation : RCB, ERP ou coexistence temporaire
- ☐ Plan de coexistence et date de bascule par périmètre
- ☐ Scénarios de recette : nouvelle vente, amendement, renouvellement, résiliation, avoir
- ☐ Formation des utilisateurs et support des premières semaines
- ☐ Plan de décommissionnement des éléments CPQ devenus inutiles
Questions fréquentes
Peut-on mettre à jour Salesforce CPQ vers Revenue Cloud Advanced ?
Non, il n'existe pas de mise à jour automatique. Salesforce CPQ est un package géré avec ses propres objets, alors que Revenue Cloud Advanced repose sur le modèle de données natif de Salesforce. La migration est une ré-implémentation, accompagnée d'une reprise des données actives.
Salesforce CPQ va-t-il disparaître ?
Salesforce oriente désormais les nouveaux clients vers Revenue Cloud Advanced et concentre ses investissements sur la plateforme native. Pour les clients existants, les conditions de support relèvent de leur contrat : il est prudent de vérifier ce point avec Salesforce et de planifier la migration.
CPQ et Revenue Cloud peuvent-ils coexister dans la même org ?
Oui, ils peuvent coexister pendant la transition, ce qui permet une bascule progressive par gamme de produits ou par entité. Il faut toutefois bien définir quel processus utilise quel outil pour éviter les doublons.
Que deviennent les abonnements CPQ existants ?
Les contrats et abonnements actifs sont repris sous forme d'actifs Revenue Cloud, avec leurs dates, quantités et prix. Cette reprise conditionne le bon fonctionnement des amendements et des renouvellements après la bascule.
Faut-il migrer Salesforce Billing en même temps ?
Pas forcément. On peut migrer d'abord les devis et commandes vers RCA, puis la facturation vers Revenue Cloud Billing (RCB) à une date de bascule propre. Le choix dépend de votre cycle de facturation et de votre ERP.