Migrer de Salesforce CPQ vers Revenue Cloud

Avec l'annonce de la fin de commercialisation de nouvelles licences Salesforce CPQ et le repositionnement de Revenue Cloud comme plateforme de référence, de nombreuses entreprises se posent la question du calendrier et de la méthode de migration. Il ne s'agit pas d'une mise à jour de version : c'est un projet de remodélisation qui doit être traité comme tel. Voici une méthodologie concrète.

Étape 1 : cadrer l'ampleur réelle du changement

Avant tout chiffrage, il faut établir un audit précis de l'existant CPQ : nombre de produits, complexité des bundles (Product Rules, Price Rules), volumétrie de Quote historiques, intégrations tierces connectées (ERP, plateforme de paiement, outil de génération documentaire), et développements Apex custom autour du moteur CPQ. Plus le custom est important, plus l'effort de migration sera élevé, car Revenue Cloud ne reprend pas ces personnalisations telles quelles.

Un audit doit répondre à ces questions :

• Combien de Product Rules et Price Rules sont réellement actives et utilisées en production ?
• Quelle part du catalogue relève de bundles complexes à configuration conditionnelle ?
• Quelles intégrations tierces dépendent directement des objets Quote/QuoteLineItem CPQ ?
• Y a-t-il des développements Apex qui interceptent le calcul de prix (triggers, classes de calcul custom) ?

Étape 2 : choisir une stratégie de migration

Trois approches sont possibles, à arbitrer selon la taille de l'organisation et sa tolérance au risque :

1. Big bang : bascule complète à une date donnée, catalogue et process reconstruits sur Revenue Cloud puis coupure de CPQ. Adapté aux organisations de taille moyenne avec un catalogue maîtrisé.
2. Coexistence progressive : les nouveaux clients ou une nouvelle ligne de produits basculent sur Revenue Cloud, pendant que le portefeuille existant continue sur CPQ jusqu'à son renouvellement naturel. Plus long, mais réduit le risque opérationnel.
3. Migration par segment : bascule par business unit ou par région, utile pour les grands groupes multi-entités où un big bang global est irréaliste.

La coexistence progressive est la plus fréquente en pratique, car elle évite de bloquer l'activité commerciale pendant la remodélisation du catalogue.

Étape 3 : remodéliser le catalogue produits

C'est le chantier le plus lourd. Les Product2 peuvent souvent être conservés, mais les Product Options doivent être reconstruites en ProductRelatedComponent, et chaque Price Rule doit être retraduite en Pricing Procedure (voir notre article dédié). Il n'existe pas d'outil de conversion automatique fiable à ce jour : chaque règle doit être revue manuellement, ce qui est aussi l'occasion de nettoyer les règles obsolètes accumulées au fil des années sur l'org CPQ.

Retour d'expérience : les projets qui sous-estiment le temps de remodélisation du catalogue sont ceux qui dérapent le plus. Prévoir un minimum de 30 à 40 % du budget total du projet sur cette seule étape pour un catalogue de taille moyenne à complexe.

Étape 4 : migrer les données historiques

Se pose la question du sort des Quotes et Contracts existants. En général, il n'est pas nécessaire de migrer l'historique des devis clos dans les nouveaux objets Revenue Cloud — ils restent consultables en lecture dans leur format d'origine. En revanche, les abonnements actifs doivent être recréés sous forme d'Order et OrderItem dans Revenue Cloud pour que la facturation et les renouvellements futurs soient pris en charge par le nouveau moteur, avec un mapping précis des dates de fin de période en cours pour éviter une double facturation.

Étape 5 : plan de test et formation

• Construire un jeu de scénarios de recette couvrant les cas réels les plus fréquents ET les cas limites (remise cumulée, proratisation, changement de devise).
• Faire tourner un mois en parallèle si le contexte le permet, en comparant les prix calculés par CPQ et par Revenue Cloud sur les mêmes configurations.
• Former les équipes commerciales tôt : l'ergonomie du configurateur Revenue Cloud diffère de CPQ, même si les grands principes restent proches.

Ce qu'il faut retenir

Une migration CPQ vers Revenue Cloud réussie n'est pas un projet technique isolé : c'est un projet transverse impliquant les ventes, la finance et l'IT, avec un chantier de remodélisation du catalogue à ne surtout pas sous-dimensionner. Bien planifiée, elle est l'occasion de simplifier des années de dette de configuration accumulée sur CPQ, et de préparer l'organisation aux modèles de vente hybrides (abonnement, usage) que Revenue Cloud gère nativement.