quote → cash
EN/FR Contact

Migration·Reference·9 min·Updated 2026-10-05

Coming from Salesforce CPQ

What transfers, what does not, and the distinction that makes most CPQ material inapplicable.

Salesforce docs documented by SalesforceField experience observed on a real orgRecommended pattern what we recommendTo verify unverified

Business requirement

An org on Salesforce CPQ needs to move to the native Revenue Cloud platform.

Why it is not trivial

They are different products, not versions of one. CPQ is an acquired managed package with its own namespace, price rules and product rules. The native platform has no namespace and prices through pricing procedures, expression sets and decision tables. If an org carries the CPQ namespace, almost nothing written about the native platform applies to it — and vice versa.

Recommended architecture

Treat it as a reimplementation of the commercial logic, not a data migration. The catalog and the customers migrate; the rules are rewritten, because the rule engines have no common concepts.

Salesforce components

Select one to open its detail.

Flow

Product and catalog architecture two axes, one product
CATALOG DEFINITION SELLING browse shape required ProductCatalog the container ProductCategory the shelf Classification what it is AttributeDefinition what it carries Product2 the product SellingModel how it is sold RelatedComponent the bundle PricebookEntry the list price

Scroll the diagram sideways

Attributes hang off the classification, not off the product. The category is only what the seller browses. Modelling them as one thing works until the first product needs to appear on two shelves, or two products of the same type need different attributes.

Flow

Pricing architecture context → procedure → price
INPUT DECIDE RUN OUTPUT ContextDefinition what pricing can see DecisionTable only if conditional AdjustmentSchedule tiers and allowances PricebookEntry if no condition Pricing procedure ExpressionSet Net price on the line

Scroll the diagram sideways

The rule that keeps a catalog maintainable: a decision table only when there is a condition or a tier. A flat price belongs on the PricebookEntry. Decision tables added by reflex are what fills a procedure up to its element ceiling.

And the procedure that runs is the compiled _Auto version, not the source you edit.

Implementation

  1. Inventory the commercial rules in business terms, independently of how CPQ expressed them.
  2. Rebuild them as procedures and decision tables, applying the rule that a table is only for conditions and tiers.
  3. Re-derive the catalog structure on the classification / category / bundle axes rather than transposing the CPQ one.

Watch out

  • Check the namespace before trusting any article, including this one. It is the single fastest way to know which product is being described.
  • The platform has been renamed more than once. Salesforce's own documentation now says Revenue Cloud is Revenue Management, and older material uses yet other names for the same thing.

Alternatives

Staying on CPQ remains viable where the commercial model is stable and the rules are deep. The move is worth it for the native lifecycle and billing, not for the quoting experience alone.

Salesforce resources

Guide