Salesforce has settled the status of CPQ, in its own words: "end of sale, not end of life". New customers can no longer buy CPQ; existing customers keep support, critical fixes and renewals; no forced migration has been announced, and no end-of-life date has been published. But product innovation is concentrated on Revenue Cloud Advanced. If your company runs on CPQ - all the more so on a CPQ enriched with several years of custom - the question is no longer whether but when and how. A structured answer.
01Why Salesforce is converging
CPQ (formerly SteelBrick) and Billing are delivered as managed packages installed on the platform. Salesforce explains the change by their limits: volumes, ERP integrations, omnichannel pricing. The new-generation Revenue Cloud is rebuilt natively on the Salesforce core - standard objects (quote, order, asset, invoice), Flow automations, no managed package for the core - and designed for Agentforce and Data 360, depending on edition and add-ons. What the official comparison table highlights:
- SKU-based products → attribute-based products, one product sellable under several models (one-off, subscription, usage).
- A rule-based pricing engine running in the browser → a server-side engine, in declarative pricing procedures, with simulation.
- Custom contract prices → a standard object; a separate CLM → native contracts; Billing as a package → native billing.
02Should you migrate now?
Three situations, three answers:
- Your CPQ works, limited custom → no urgency. Plan the migration in your 2027 roadmap and follow the official "Salesforce CPQ end of sale" page: no end-of-support date has been published to date.
- Your CPQ cracks at every release, custom developments everywhere → the migration is the opportunity to purge the debt. Every month of waiting adds custom to dismantle.
- You don't have a CPQ yet → the question no longer arises: CPQ is no longer sold to new customers. The only open trajectory is Revenue Cloud.
The migration is not a "lift & shift": it is a deliberate redesign - Salesforce itself advises against like-for-like replication. Those who treat it as a mere tool swap recreate their debt in the new system.
03The trajectory that works
- Audit the existing custom. Every specific rule goes under the microscope: still useful? covered as standard by Revenue Cloud? to be dropped? On the projects we take over, 40 to 60% of legacy custom no longer has a business justification - and Salesforce recommends archiving inactive rules before any migration.
- Rebuild the catalog cleanly - it is the central asset of the new system, not data to be migrated as is. Price rules and calculation scripts are mostly rewritten as declarative pricing procedures.
- Migrate by segments: one product line or one business unit first, in parallel with the existing CPQ, then progressive extension. Keep at least one active CPQ license throughout the migration, and work in a full-copy sandbox.
- Handle active contracts separately - renewals and amendments are the truly delicate subject; define a cut-over date per contract type, and migrate amendments in chronological order: an asset taken over out of sequence breaks the history and future amendments.
- Do not count on an automatic migration. The partner tools Salesforce cites carry over catalog, price lists and assets - not Apex, integrations, document templates or permissions. And reports have to be rebuilt: the data models differ.
04What it changes for your teams
For sales reps, the quoting experience is smoother (and closer to the rest of Salesforce). For admins, declarative pricing procedures and Flow (approvals, asset creation, orchestration tasks) replace most of the proprietary CPQ configuration - a more standard skill set, easier to hire for. For finance, contract-order-invoice continuity reduces manual reconciliation.
Want to know where you stand? Our audit assesses your existing CPQ and costs the trajectory - and if the right answer is "wait until 2027", we will tell you. Revenue Cloud expertise · Contact.