Same vocabulary, different architecture
Salesforce CPQ — the former Steelbrick product — is a managed package installed into your org. Its objects live in the SBQQ namespace, its calculator is a JavaScript engine that runs outside Apex, and its lifecycle model — contracts, subscriptions, amendment quotes — was designed around the quote document. Revenue Cloud, which Salesforce documentation brands Revenue Lifecycle Management, is a rebuild on the core platform: standard objects, a rules-based pricing service, headless REST APIs and an asset-centric lifecycle.
That packaging difference is not trivia. It drives every practical difference an engineering team will feel — how data is modelled, how prices are computed, where custom logic lives and what migration actually involves. Salesforce has also been explicit about where investment goes: new capability lands in Revenue Cloud while CPQ receives maintenance. Check Salesforce's current product notices before committing either way; the commercial position changes faster than the architecture does.
Data model: quote-centric vs transaction-centric
CPQ: the quote is the hub
In CPQ, everything hangs off SBQQ__Quote__c and SBQQ__QuoteLine__c. Bundles are expanded at configuration time — options become child quote lines linked by SBQQ__RequiredBy__c — so each quote carries a flattened copy of catalog structure. Post-sale state is a chain of package objects: the quote generates an order, the order activates into a contract, and the contract holds SBQQ__Subscription__c records for recurring lines. Amendments regenerate a quote from the contract and difference it against existing subscriptions.
Two consequences shape daily work. First, data transport between stages relies on the twin-field convention: create a custom field with an identical API name on quote line, order product and subscription, and the package copies values along the chain. Convenient, and completely invisible — nothing declares the dependency, so renames and type changes break silently. Second, there is no single canonical answer to "what does this customer own"; you reconstruct it from subscriptions, assets and contract lines, which is why so many CPQ orgs grow a custom installed-base layer, a pattern we dissect in our order-to-cash article.
Revenue Cloud: catalog and asset are canonical
Revenue Cloud inverts the model. Product Catalog Management (PCM) is a first-class citizen: products carry selling models — one-time, term, evergreen — bundle structure is data (ProductRelatedComponent records) rather than exploded lines, and attributes are defined once and reused by configuration, pricing and fulfillment. Quotes and orders use the standard Quote, QuoteLineItem, Order and OrderItem objects, with no namespace. A line is treated as one transaction-line concept that moves through states from quote to order to asset instead of being copied between package objects.
Post-sale, the asset is the system of record. Amendments and renewals read the asset's current state and its state history; there is no contract-plus-subscription reconstruction. For teams arriving from CPQ this is the largest mental-model shift: the quote becomes a transient document, while the catalog and the installed base become the durable models. It is also the shift that pays for itself — many of the painful patterns we catalogue in the complex CPQ playbook are workarounds for the quote being the only reliable record.
Pricing engine: price rules vs the price waterfall
How CPQ calculates
The CPQ calculator applies a fixed sequence: list price from the price book, special pricing methods (block, percent-of-total, cost-plus), discount schedules, contracted prices, then the discount layers — partner, distributor, additional. Custom logic enters through price rules — condition-action records evaluated at calculator events (on initialization, before calculate, on calculate, after calculate) — and through the Quote Calculator Plugin, a JavaScript file that runs inside the calculation itself.
It is a powerful, battle-tested engine with well-known failure modes. Rule evaluation order becomes load-bearing and undocumented. Rules trigger recalculation passes that are hard to reason about. QCP scripts grow into an unversioned shadow codebase nobody reviews. And the whole quote recalculates as a unit, so very large quotes slow down in ways users notice — we wrote about how this plays out in real-world deal pricing. The engine is also quote-bound: reusing it to price a self-service cart or an API-created order means either faking a quote or reimplementing pricing. Both are bad.
How Revenue Cloud calculates
Revenue Cloud prices through a pricing procedure: an explicit, ordered sequence of steps — list price, attribute-based adjustments, tiering, bundle adjustments, manual discounts — assembled from expression sets, with each step's input and output recorded. The result is a price waterfall you can audit line by line: sales, deal desk and finance see the same explanation of how list became net, per line, per step.
Because the engine is a service on core rather than a quote plugin, the same procedure prices a rep-built quote, a self-service cart and a payload sent to the pricing API. That is the strategic difference: one pricing brain across every channel. The trade-off is strictness. A waterfall procedure has no slot for the quick "patch it in a price rule before quarter close" hack. Mostly that is a feature; occasionally, mid-quarter, it feels like a constraint. Design your discount governance around it.
Extensibility: package edges vs platform surface
CPQ exposes the extension points a package can: product and price rules, QCP JavaScript, custom actions and the SBQQ.QuoteAPI for programmatic calculate-and-save — the usual route to headless quoting. The API surface is narrow, the calculator is a black box, and anything the package does not expose becomes a workaround. Workarounds accumulate; a fair share of the technical-debt rescues we run start in a CPQ org where the package fought the business model for years.
Revenue Cloud's extensibility is platform-native. Expression sets and decision tables are declarative, versionable metadata that deploy through normal CI/CD. Context definitions control exactly what data the pricing and configuration engines see. REST APIs cover product discovery, pricing and quote and order placement for headless flows. And because the objects are standard, Flow, Apex triggers and platform events work the way they do everywhere else on the platform, under the usual governor limits — no package abstractions in the way.
The honest counterweight: Revenue Cloud is younger. A decade of CPQ releases produced niche capabilities — specific discount methods, document generation workflows, edge amendment scenarios — that may or may not have equivalents yet, and the gap list changes every release. Validate your specific commercial constructs against current Salesforce documentation instead of assuming parity.
Migration reality: re-implementation, not upgrade
There is no upgrade path. Moving from CPQ to Revenue Cloud is a re-implementation with a data migration attached, and pretending otherwise is the main way these projects fail. The work splits into three layers: concept mapping (bundles into PCM components, price rules and QCP logic into pricing procedures and decision tables), data transformation (catalog, contracted prices, open quotes), and the genuinely hard part — converting live contracts and subscriptions into the asset model so in-flight amendments and renewals keep working after cutover.
Plan for coexistence rather than a big bang. Phase by product family or sales motion, keep one engine authoritative per product, and run parallel calculations — the same deal priced by both engines — until the waterfall's outputs match or every difference is explained and accepted. Our field report on this migration covers the phasing in detail, and our data migration practice handles the transformation tooling. Budget most of your contingency for the asset conversion and for the integrations nobody documented — document generation, e-signature, ERP sync and every automation that quietly depends on a twin field.
Decision matrix
No single answer fits every org. Score your situation honestly across these dimensions; the column with more ticks wins.
| Dimension | Leans CPQ (today) | Leans Revenue Cloud |
|---|---|---|
| Existing footprint | Deep, stable CPQ build; migration ROI unclear | Greenfield, or replatforming quote-to-cash anyway |
| Sales channels | Single seller-led desktop quoting flow | Self-service, partner or API-driven selling needing one pricing engine everywhere |
| Pricing model | Discount-led pricing your current rules already handle | Attribute-based, usage or consumption pricing; auditable waterfall required |
| Deal shape | Modest line counts, infrequent amendments | Large quotes, ramp deals, frequent in-life changes on assets |
| Ecosystem needs | Depends on mature CPQ-specific AppExchange tooling | Standard-object integrations, headless APIs, composable stack |
| Team profile | Admin-led team fluent in price rules | Engineering-led team comfortable with APIs, versioned rules and CI/CD |
| Roadmap risk | Accepts a maintenance-mode product with proven behavior | Wants to follow Salesforce's investment direction |
The 2026 default is straightforward: new implementations should start the evaluation from Revenue Cloud and treat CPQ as the exception that needs justification. Existing CPQ orgs should do the opposite of panicking — a stable, well-governed CPQ implementation is not a burning platform. The right migration date depends on your catalog's shape, your asset conversion cost and what your CPQ debt already costs you, not on marketing pressure.
Frequently asked questions
Is Salesforce CPQ end of life?
Salesforce has moved new-feature investment to Revenue Cloud and no longer positions CPQ as the default for new customers, but existing implementations remain supported and widely used. Treat CPQ as a mature product in maintenance rather than something to abandon overnight, and verify current commercial and support commitments in Salesforce's own product notices before planning around them.
Can CPQ and Revenue Cloud run in the same org?
Yes, and coexistence is the normal state during a phased migration. Segment by product family or sales motion, keep exactly one pricing engine authoritative for each product, and avoid mixed quotes that would need both calculators. Most teams route new products through Revenue Cloud while legacy products stay on CPQ until they are converted.
Do CPQ quote lines and subscriptions migrate directly to Revenue Cloud?
No. There is no record-for-record upgrade path. Bundles, price rules and QCP logic must be re-modelled in Product Catalog Management and pricing procedures, and active subscriptions and contracts must be transformed into the asset model before amendments and renewals work. Plan the move as concept mapping followed by data transformation, not as an export and import.
Is the Revenue Cloud price waterfall customizable without code?
Largely, yes. Pricing procedures are assembled declaratively from expression sets and decision tables, and attribute-based adjustments cover many cases that required price rules or QCP scripts in CPQ. Apex and REST extension points take over where declarative tools stop. The practical limit is design discipline: the waterfall rewards teams that model pricing policy explicitly instead of patching rules.
Which product should a new quote-to-cash implementation choose?
Start the evaluation from Revenue Cloud. It is where Salesforce directs its investment, and its core-platform architecture avoids the structural limits of the managed package. Choose CPQ for a new build only when a validated gap blocks you — a specific pricing method, document workflow or ecosystem dependency — and confirm availability and roadmap with Salesforce in writing first.
Related reading
Bring the hard part to a senior Salesforce engineering team.