Migrer de Salesforce CPQ vers Revenue Cloud

Migrer de CPQ vers Revenue Cloud revient à réimplémenter le cycle de vente sur un nouveau modèle de données, avec une reprise de données. Voici le plan recommandé étape par étape, les deux modèles de données côte à côte, l'équivalence objet par objet et les pièges qui coûtent le plus cher.

Le plan de migration

01Inventairece que CPQ fait vraiment
02Catalogueà restructurer
03Tarificationprocédures testées
04Reprisedevis, contrats, abonnements
05IntégrationsERP, documents
06Basculecoexistence puis fin de CPQ

1. Inventorier ce que CPQ fait vraiment

On commence par extraire et documenter l'existant : produits et options, bundles, règles de prix et de produits, barèmes de remise, templates de devis, processus d'approbation, automatisations Apex et Flow qui touchent aux objets CPQ, intégrations ERP et outils tiers. On note pour chaque élément s'il est utilisé, par qui, et s'il répond encore à un besoin.

Cet inventaire révèle presque toujours des règles mortes et des contournements accumulés. C'est le moment de les abandonner.

Modèle de données Salesforce CPQ (package SBQQ)

Les objets du package sont préfixés SBQQ__. Le devis, ses lignes et les abonnements vivent dans ce modèle, à côté des objets standard.

2. Repenser le catalogue avant de le migrer

Revenue Cloud repose sur un catalogue unique avec classifications et attributs. Le catalogue CPQ, souvent construit produit par produit, gagne à être restructuré : familles cohérentes, attributs au lieu de variantes multipliées, bundles qui reflètent l'offre commerciale. Le marketing et les ventes y participent, avec l'équipe technique.

Modèle de données Revenue Cloud (objets standard)

Tout repose sur des objets standard : le catalogue structure les produits, les actifs portent le cycle de vie des abonnements, la facturation en découle. Les procédures de prix s'appliquent aux prix du catalogue.

3. Convertir les règles de prix en procédures

Les règles de prix de CPQ ne se transposent pas une à une. On repart des cas de tarification réels, comme les listes de prix, remises par volume, prix négociés et majorations, et on les modélise en procédures de tarification lisibles. Les cas de test sont des devis réels extraits de CPQ : chaque procédure doit reproduire les montants attendus avant d'aller plus loin.

4. Décider du sort des devis, contrats et abonnements

Devis en cours : migrés s'ils sont actifs, sinon conservés en lecture dans CPQ ou archivés.
Contrats et abonnements : le point le plus sensible. Les abonnements CPQ actifs deviennent des actifs dans Revenue Cloud ; ils doivent être repris avec leurs dates, quantités et conditions de renouvellement, pour que les avenants et renouvellements fonctionnent.
Historique de facturation : rarement migré ; on garde l'accès en lecture et on documente la règle.

Cette reprise suit la même méthode qu'une migration de données classique : staging, mapping, chargements par lots, recette par comptage et par échantillons, plan de rollback.

Équivalences objet par objet, de CPQ vers Revenue Cloud

Salesforce CPQRevenue Cloud

Produit, option, fonctionnalitéProduct2, SBQQ__ProductOption__c, SBQQ__ProductFeature__cProduit, composant de bundleProduct2, ProductRelatedComponentLes bundles sont redéfinis comme des composants avec cardinalités.

Attribut de configurationSBQQ__ConfigurationAttribute__cClassification et attributsProductClassification, AttributeDefinitionLes attributs deviennent des définitions réutilisables par classification.

Catalogue de prixPricebook2, PricebookEntryCatalogue de prixPricebook2, PricebookEntryInchangé ; les modèles de vente (ProductSellingModel) précisent abonnement ou usage.

Règle de prix, conditions, actionsSBQQ__PriceRule__c, SBQQ__PriceCondition__c, SBQQ__PriceAction__cProcédure de tarificationPricing Procedure (Expression Set)Pas de conversion automatique : on remodélise à partir des cas réels.

Barème de remiseSBQQ__DiscountSchedule__c, SBQQ__DiscountTier__cBarème d'ajustementPriceAdjustmentSchedule, PriceAdjustmentTierÉquivalence directe, par paliers de quantité ou de montant.

Règle de produitSBQQ__ProductRule__cRègles de configurationConfigurateur avancéValidation, sélection et alertes se paramètrent dans le configurateur.

Prix négociéSBQQ__ContractedPrice__cTarifs par compteProcédure de prix + listes de prix dédiéesLes prix contractuels s'expriment par des listes et des ajustements ciblés.

Devis et lignesSBQQ__Quote__c, SBQQ__QuoteLine__cDevis et lignes standardQuote, QuoteLineItemSeuls les devis actifs sont repris ; les autres restent en lecture.

Modèle de devisSBQQ__QuoteTemplate__cGénération de documentsDocument Builder, OmniStudioLes templates sont refaits, c'est l'occasion de les simplifier.

Contrat et abonnementsContract, SBQQ__Subscription__cContrat et actifsContract, Asset, AssetStatePeriodLe point critique : dates, quantités et conditions de renouvellement doivent être reprises.

Avenants et renouvellementsDevis d'amendement et de renouvellementCommandes basées sur l'actifAsset-based orderingModifier, renouveler ou résilier se fait depuis l'actif.

Facture Salesforce Billingblng__Invoice__c, blng__InvoiceLine__cFacture standardInvoice, InvoiceLine, BillingScheduleL'historique de facturation reste en général consultable en lecture seule dans l'ancien système.

Noms d'API indicatifs, selon les éditions et versions. L'équivalence n'est jamais un simple renommage : chaque ligne se valide sur des devis et contrats réels.

5. Rebrancher les intégrations

Les flux vers l'ERP, pour les commandes, la facturation et les référentiels produits, et les outils de signature ou de génération de documents sont à reconstruire sur les nouveaux objets. C'est souvent l'occasion de simplifier : les objets standard de Revenue Cloud s'intègrent plus directement que le modèle CPQ.

6. Organiser la coexistence et la bascule

Peu d'entreprises basculent tout en un jour. Une coexistence par équipe, par gamme ou par pays limite le risque, à condition de définir clairement où chaque devis se crée pendant la transition. La bascule finale suit un plan daté : gel des devis dans CPQ, dernier delta d'abonnements, contrôles, ouverture dans Revenue Cloud, période de support renforcé.

Les pièges les plus fréquents

Reproduire le paramétrage CPQ à l'identique, y compris ses défauts.
Sous-estimer la reprise des abonnements et des contrats.
Tester avec des devis fictifs au lieu de devis réels.
Oublier les rapports et tableaux de bord qui lisaient les objets CPQ.
Lancer la migration sans propriétaire métier du catalogue et des prix.

Questions fréquentes

Combien de temps dure une migration CPQ vers Revenue Cloud ?

De trois à neuf mois selon la complexité du catalogue, le nombre de règles de prix et le volume d'abonnements à reprendre. L'inventaire initial permet de donner une estimation fiable.

Peut-on migrer progressivement ?

Oui, par périmètre, qu'il s'agisse d'une équipe, d'une gamme ou d'un pays, à condition de fixer des règles claires de coexistence et de ne pas laisser la transition s'éterniser.

Lucas Massoni

Consultant indépendant, expert Salesforce, Revenue Cloud et Tableau. Il intervient du cadrage à la mise en production : devis et facturation, migration de données, intégrations avec l'ERP et tableaux de bord.

Profil LinkedIn