Migrer de CPQ vers Revenue Cloud : reprendre le parc actif, pas l’historique

Le cas : quelques centaines de contrats CPQ actifs, environ trois mille abonnements en cours, et un Billing CPQ qui a déjà facturé une partie des périodes. Il faut basculer vers Revenue Cloud sans casser la numérotation des factures ni refacturer qui que ce soit.

Ne pas migrer l’historique

Recopier trois mille devis CPQ dans les devis Revenue Cloud, ou deux mille six cents factures de l’ancien Billing dans les factures Revenue Cloud, ne sert à rien : personne ne les retravaillera. Et ça casse la numérotation légale, puisque de vieilles factures prendraient de nouveaux numéros. Recommandé

On ne reprend que le parc actif, sous forme d’actifs Revenue Cloud. Sans actifs, impossible d’amender, de renouveler, d’annuler ou de swapper dans le nouvel outil. L’historique reste consultable dans les objets CPQ et dans ceux de l’ancien Billing, en lecture seule.

C’est la seule décision de cadrage qui compte vraiment : elle divise le périmètre par dix et elle supprime la question de la numérotation.

La méthode : une commande de reprise par contrat

Pour chaque contrat CPQ actif, on crée une commande Revenue Cloud de reprise :

• Sur le même contrat. Le numéro et l’historique du client sont conservés.
• Au prix net négocié. Pas au prix catalogue.
• Avec les quantités nettes. Une fois les avenants CPQ cumulés.
• Activée. Ce qui crée les actifs et les rattache au contrat.

Le prix unitaire se déduit de l’abonnement CPQ : le prix net divisé par le multiplicateur de prorata donne le prix par terme du produit, un mois ou douze mois selon le terme de l’abonnement. On le convertit ensuite au selling model Revenue Cloud, au mois ou à l’année. Terrain

Un même produit peut apparaître à deux prix dans un contrat CPQ, par exemple une partie offerte et une partie payante. Les fusionner fausse le montant : une ligne par prix, toujours. Terrain

Ne pas refacturer ce que l’ancien Billing a déjà facturé

C’est la vraie difficulté. Pour chaque abonnement, l’ancien Billing sait jusqu’où il a facturé — une date de dernière période facturée, portée par la ligne de commande CPQ. On en tire trois cas.

Le marqueur est une simple case à cocher sur la ligne de commande. Le flow qui crée les échéanciers à l’activation ignore les lignes cochées. Au renouvellement, la nouvelle commande n’a pas le marqueur : la facturation reprend normalement, toute seule. Recommandé

L’ancien package de facturation reste actif tant qu’on ne l’a pas coupé, et il réagit aux activations de commande. Le couper est donc un prérequis de la reprise, pas une étape d’après. Terrain

Les sept pièges de la répétition

On a répété sur une sandbox, sur de vrais contrats CPQ. Chaque échec a ajouté une ligne au script.

1. L’action de commande ne se crée pas avec la commande. Créer la commande par l’API en y incluant son action renvoie une exception sans explication. Il faut créer l’action « Add » après, puis la rattacher à chaque ligne. Sans elle, ni facturation ni actif. Terrain
2. Pas de licence Revenue Cloud sur la commande, pas d’actif. Une commande créée depuis un devis porte une affectation d’usage applicatif. Une commande créée par API n’en a pas, et l’assetisation s’arrête sans bruit. Il faut la poser avant l’activation. Terrain
3. Les produits historiques ne sont pas assetisables. Le drapeau d’assetisation était à faux sur la moitié des anciens produits. Message : « couldn’t find order products eligible to be converted to assets ». Terrain
4. Contact de facturation obligatoire. Sans contact à facturer, les échéanciers ne se créent pas. On reprend celui de l’ancien Billing ; à défaut, le premier contact du compte. Terrain
5. Périodicité non annuelle = traitement de facturation obligatoire. Une ligne mensuelle ou trimestrielle sans traitement est refusée : « Add a Billing Treatment to make sure that you can change the Billing Frequency ». On prend le traitement par défaut de la politique de facturation du produit. Terrain
6. Adresse de livraison obligatoire à l’activation. Même pour du logiciel. On recopie l’adresse de facturation du compte. Terrain
7. Evergreen et contrat à durée fixe ne cohabitent pas. Une ligne evergreen refuse toute date de fin. En démarrant à sa prochaine échéance, elle dépasse la fin du contrat CPQ, et le lien actif ↔ contrat est refusé : « Start Date must be before End Date on Asset Contract Relationship ». Un seul refus suffit à bloquer tous les actifs de la commande. On a donné à ces produits une option « à terme », alignée sur le CPQ. Terrain

Et un dernier, sournois : quand la création de commande échoue, elle laisse parfois une commande vide derrière elle. Le script doit la supprimer, sinon il croit le contrat déjà repris et le saute. Terrain

Le catalogue d’abord, et inactif

La reprise pointe vers des produits, des selling models et des prix Revenue Cloud. Ils doivent exister en production avant, sans gêner les commerciaux qui font encore des devis CPQ.

• Le catalogue est créé en copies inactives. Suffixées pour être reconnaissables.
• Les anciens produits sans équivalent sont réutilisés tels quels : On leur ajoute seulement une option de selling model et des prix Revenue Cloud inactifs. Le CPQ ne voit pas la différence.
• Le jour J, un seul script. Active tout, retire le suffixe et désactive les anciens produits devenus doublons.

Le contrôle qui fait foi

Un seul chiffre décide si la reprise est bonne, et il est vérifiable par la finance : montant annuel récurrent CPQ = montant annuel récurrent Revenue Cloud, au centime, contrat par contrat.

Le script le calcule à blanc, avant toute écriture, et sort un rapport par contrat avec les anomalies : produit sans correspondance, absence de contact, composants repris à plat. Sur la répétition : écart nul sur l’ensemble du parc, une ligne CPQ = une ligne de commande = un actif, et aucun échéancier en trop. Terrain

Ce que ça coûte

• Une table de correspondance. Entre produits CPQ et produits Revenue Cloud. C’est souvent la partie la plus longue quand il y a beaucoup de produits historiques, et elle ne s’automatise pas.
• Un champ et une condition de flow. Pour le marqueur « déjà facturé ».
• Des anciens bundles repris à plat. Quand leurs composants n’existent pas dans les nouveaux : la facturation et le renouvellement marchent, la reconfiguration du bundle non.

Composants Salesforce

Sélectionnez-en un pour ouvrir son détail.

Sur quoi ça repose

• La reprise suppose que l’ancien Billing est coupé. Sinon, double facturation possible — c’est le seul risque irréversible du chantier.
• Les sept pièges ont été constatés en Summer ’26 et Winter ’27. Les messages d’erreur cités peuvent changer avec une release.
• Reprendre le parc actif plutôt que l’historique est un choix recommandé, pas imposé : si vos auditeurs exigent l’historique dans les objets standard, prévoyez une numérotation dédiée aux factures reprises.
• Les formules de conversion de prix viennent des champs du package CPQ. Vérifiez-les sur votre version du package avant de les reprendre telles quelles.