Salesforce CPQ to Revenue Cloud Data Mapping: An Object-by-Object Guide

Salesforce CPQ to Revenue Cloud data mapping means translating the SBQQ managed-package model into the standard transaction, product catalog, pricing, and asset models of Revenue Cloud (formerly Agentforce Revenue Management).

A quote becomes a standard Quote with context-field mappings. Bundles shift from ProductFeature and ProductOption to ProductComponentGroup and ProductRelatedComponent, while CPQ price and product rules are rebuilt in the corresponding Revenue Cloud pricing and configuration frameworks.

Object families at a glance:

• Quotes and quote lines move to standard Quote and QuoteLineItem, with field movement handled through Context Service mappings and supported twin mapping for some custom-field scenarios.
• Bundles built from features and options become ProductComponentGroup and ProductRelatedComponent, not a one-to-one copy.
• Configuration attributes become the Revenue Cloud attribute model, using AttributeDefinition records and Product Classification associations.
• Product rules and price rules are re-authored by function. Product configuration logic uses Business Rules Engine or Constraint Rules Engine, while CPQ price rules move to pricing procedures and pricing elements. There is no blanket record-to-record migration of rule logic.
• Discount schedules move into Revenue Cloud discount and pricing structures. The resulting tiers and commercial outcomes still need validation.
• Subscriptions map to Asset in Customer Asset Lifecycle Management, while ProductSellingModel is created separately from CPQ product selling configuration.
• Quote templates are rebuilt as Revenue Cloud quote templates in Document Builder.

Salesforce stopped selling CPQ to new customers in March 2025. Existing customers keep full support and can still renew and add users, and Salesforce has not announced an end-of-life date, but new product investment now goes into Revenue Cloud. That is why teams are mapping their CPQ data now, on their own timeline, rather than waiting for a deadline.

This guide starts with a complete object-by-object table, then covers the transforms that are not one-to-one, which is where migrations most often break. For the business case, timing, and phased plan, see the Salesforce CPQ to Revenue Cloud migration hub.

Why CPQ and Revenue Cloud store the same deal differently

Salesforce CPQ is a managed package, with its logic and most of its data in the SBQQ__ namespace. It also syncs with standard objects in restrictive, opinionated ways.

Revenue Cloud uses standard Salesforce transaction objects together with Product Catalog Management, Context Service, and a rebuilt rules and pricing model.

Because the two models are built differently, the move requires re-architecting the data rather than copying it. A field stored on SBQQ__QuoteLine__c has no guaranteed equivalent on QuoteLineItem. A bundle assembled from features and options in CPQ does not appear in Product Catalog Management with the same structure. The data has to be remodeled first, and only then loaded into the new model.

This is not a push-button conversion. Salesforce's current migration guidance points to tools and accelerators for assessment, data extraction, migration automation, and validation, but custom logic and integration remapping still require design decisions. Migration is a build, and the object mapping below is its specification.

The CPQ data model (what you are migrating from)

CPQ structures a deal around a quote header and its lines. The header is SBQQ__Quote__c and the lines are SBQQ__QuoteLine__c. When a quote is divided into sections, lines are organized under SBQQ__QuoteLineGroup__c. Products remain standard Product2 records, with CPQ adding configuration on top.

Configurable products are organized into bundles. Features (SBQQ__ProductFeature__c) provide the grouping, and options (SBQQ__ProductOption__c) are the child products available within those features. An option's minimum and maximum quantity, required status, and dependencies or exclusions are set on the option and its related records. Configuration attributes (SBQQ__ConfigurationAttribute__c) record the picklist-style selections users make during configuration, separately from the components themselves.

Selling logic is split between two rule families. Product rules (SBQQ__ProductRule__c) control validation, selection, alerts, and filtering through error conditions and product actions. Price rules (SBQQ__PriceRule__c) handle pricing through price conditions and price actions. Volume and term discounts live in SBQQ__DiscountSchedule__c, ongoing commercial relationships are stored as SBQQ__Subscription__c, and quote output comes from SBQQ__QuoteTemplate__c and its template content.

Throughout the system, twin fields pass values downstream between objects when their API names match exactly. That is how CPQ keeps related data in sync without explicit mapping.

The Revenue Cloud data model

Revenue Cloud records transactions on standard objects. A quote uses the standard Quote object, with lines stored as QuoteLineItem records. From there, the deal moves through Order and OrderItem and into the asset lifecycle. Context Definitions, including the Sales Transaction Context, map data across transaction flows, and QuoteEntitiesMapping and OrderEntitiesMapping provide explicit sObject mappings. Twin mapping is supported for custom fields in specific cases, but standard-to-standard Product2 to QuoteLineItem twin mapping is not.

Product Catalog Management models the products. Product2 records are classified through ProductClassification, and attributes are defined as AttributeDefinition records and associated through the classification model. Selling terms (one-time, term-defined, and evergreen) are represented by ProductSellingModel and ProductSellingModelOption. Bundles are assembled with ProductComponentGroup and ProductRelatedComponent, and the catalog is structured through ProductCatalog and ProductCategory.

List prices still live on standard PricebookEntry records, while pricing behavior is defined through pricing procedures and pricing elements. Product configuration rules use Business Rules Engine or Constraint Rules Engine depending on complexity, and some dynamic filter scenarios can be remodeled with Product Classification Components. Because these are different target constructs, CPQ logic has to be inventoried and redesigned rather than assumed to migrate record to record.

CPQ to Revenue Cloud object mapping

The table below is the specification. The left column is the CPQ source object in the SBQQ__ namespace, the next is its role in CPQ, then the Revenue Cloud or Salesforce destination, and the final column describes the type of move, so it is clear when a redesign is involved rather than a direct copy.

The rows labeled "redesign" and "rebuild" decide whether a migration succeeds. Moving the records is only half the work: their relationships must arrive intact, or the new model will not resolve. A technically successful load is not enough if sales reps can no longer generate accurate quotes, apply pricing rules, or follow the approval workflows that govern complex deals.

The transforms that aren't one-to-one

Most rows in the table are a remap or reload. A handful require re-architecting, and each of those brings a referential-integrity trap. Handle them before touching production.

Bundles become component groups

In CPQ, a bundle is built from features and options: SBQQ__ProductFeature__c groups SBQQ__ProductOption__c records, and each option is a child product. Revenue Cloud uses ProductComponentGroup and ProductRelatedComponent for the same structure.

Salesforce maps Product Option records to Product Related Component records and Product Feature records to Product Component Group records. Minimum and maximum quantities become cardinality on the component relationship. Exclusions, requirements, and validation logic move to Constraint Rules Engine or Business Rules Engine, while dynamic bundle and filter-rule scenarios can use Product Classification Components.

Sequence the load so parent structures and referenced records exist before dependent data arrives, then validate relationship integrity in the target. If the catalog is rebuilt incorrectly, guided selling can present the wrong choices or allow combinations the original CPQ setup prevented, so migrate bundles as business logic rather than as a list of child records.

Configuration attributes become the attribute model

CPQ configuration attributes move into Revenue Cloud's product attribute model. Salesforce maps Configuration Attribute to Product Attribute and documents AttributeDefinition records and Product Classification associations as the core of that model. This is a different mechanism, not a field rename.

The mistake most third-party mappings make is treating attributes and bundle components as the same object family. A configuration attribute is not a bundle option, and a bundle option is not an attribute, so they should not be collapsed into one "product attribute" destination. The attribute model captures choices about a product; the component model captures what a bundle contains.

Product and price rules require redesign

SBQQ__ProductRule__c covers selection, validation, alert, and filtering behavior. In Revenue Cloud, configuration rules are handled through Business Rules Engine or Constraint Rules Engine, and dynamic filter-rule scenarios may use Product Classification Components instead.

SBQQ__PriceRule__c, with its price conditions and price actions, maps to pricing procedures and pricing elements. The pricing architecture and execution model differ from CPQ, so this is a redesign, not a record-to-record copy.

The main risk is starting without a complete inventory of every rule and every reference to custom Apex or a Quote Calculator Plugin. Pricing edge cases that apply only to one region, customer, product family, or transaction type are easy to miss. Price rules often encode years of commercial policy, so recreating them correctly is what keeps quotes accurate after cutover.

Discount schedules become pricing tiers

SBQQ__DiscountSchedule__c stores volume- and term-based discount tables. Revenue Cloud models discount behavior inside its pricing architecture, using PriceAdjustmentSchedule and PriceAdjustmentTier along with other adjustment constructs.

Salesforce classes price books and discount schedules as largely automatable migration components, but the migrated structure still has to be checked against the original commercial outcomes. Do not assume breakpoints and rates carry over without validation, especially where pricing depends on volume, contract term, or usage.

Subscriptions and the install base

SBQQ__Subscription__c does not split into ProductSellingModel and Asset. Salesforce maps SBQQ__Subscription__c to Asset in Customer Asset Lifecycle Management, with the required history chain preserved. ProductSellingModel is created separately from CPQ product selling configuration, such as Product2 subscription pricing and subscription-type settings, and associated with products through ProductSellingModelOption.

Amendment, renewal, cancellation, and asset behavior all depend on that history, so the relationships among migrated transaction and asset records must stay consistent. Salesforce supports more than one asset-migration path, including generating assets from historical orders and creating assets directly, so validate the sequence your chosen strategy requires.

This is the biggest migration-integrity risk. If an asset loses its parent or historical lineage, renewals and amendments can fail after go-live, when they are hardest to fix, and the errors flow on into billing and revenue recognition.

Twin fields require explicit review

CPQ twin fields pass values through an exact API-name convention. Revenue Cloud relies on Context Service mappings, including Sales Transaction Context, QuoteEntitiesMapping, and OrderEntitiesMapping. Twin mapping has not disappeared: Salesforce supports it for custom fields in specific scenarios, but standard-to-standard Product2 to QuoteLineItem twin mapping is not supported through Context Service.

Any downstream process that depended on twin-field behavior, such as reporting, billing, approvals, or integrations, needs a field-by-field review.

Quote templates and documents

SBQQ__QuoteTemplate__c and its template content do not migrate record for record. Revenue Cloud quote templates are built in Document Builder, so rebuild and test the output there as a separate workstream. Test generated documents alongside the underlying quote data, because a correct configuration still produces a poor customer experience if the document shows inconsistent pricing, missing terms, or the wrong products.

How to verify the mapping before loading production data

The mapping above is a hypothesis until it has been tested against real data. Check it in a sandbox, not in production.

Start by seeding a sandbox with a referentially intact subset of real CPQ data, so testing reflects the actual shapes and edge cases your org produces instead of clean sample records. A representative dataset that preserves relationships exposes orphaned-record failures before they reach production. For a step-by-step approach, see Salesforce sandbox seeding.

Load in an order that respects the dependencies of your migration path. ProductClassification and ProductComponentGroup records must exist before dependent classification and component records can reference them, and Quote must exist before its QuoteLineItem records. For Customer Asset Lifecycle Management, preserve the required transaction history and sequence if you generate assets from historical orders.

After each load, reconcile. Compare source and target record counts per object, then spot-check the parent-child relationships that matter most: bundle to component, quote to line, and order or transaction history to asset. Trace a handful of real deals end to end to confirm the lineage holds, and keep a rollback path so an integrity problem can be reversed cleanly rather than repaired by hand in a partially loaded org.

Historical transactional scope is a strategy decision. Salesforce states there is no single correct migration strategy, so decide whether historical CPQ quotes stay in place, coexist as read-only history, or are migrated, based on reporting, compliance, and cutover requirements. Functional testing should then follow how sales reps actually work: simple quotes, complex bundles, guided selling, discounting, approvals, renewals, and price overrides.

How Flosum makes the mapped migration safe

The architect owns the redesign. You rewrite the pricing rules, rebuild the bundles in Product Catalog Management, and recreate the pricing behavior, because no migration tool can determine your commercial intent. Flosum Data Migrator handles the data move, transferring the underlying records while preserving the object graph.

That addresses the integrity risk created by the transforms above. Data Migrator preserves parent-child and cross-object relationships across every migration or seeding job, and it ships prebuilt, relationship-aware seeding templates for complex application layers, including CPQ and Revenue Cloud. With those templates, teams can build and test representative datasets in sandboxes with relationships intact, then reseed on demand as the mapping changes.

Flosum supports the data-migration layer in a full transition, a coexistence model, or a phased cutover. It is not a CPQ tool, and it does not redesign pricing rules, product configuration, or commercial logic. If Revenue Cloud configuration and metadata are deployed alongside the data work, Flosum DevOps can manage that deployment workstream through Salesforce-native, Flosum-hosted cloud, and customer-hosted deployment options.

FAQs

See how Flosum protects relationships in a CPQ data migration. Book a demo.