Salesforce CPQ to Revenue Cloud Data Migration (What Actually Moves)

Salesforce CPQ is end of sale, not end of life. Existing customers can keep using it, renew, and add seats. New licenses are not sold to new customers, and Salesforce’s strategic path for quote-to-cash is Revenue Cloud (including Revenue Cloud Advanced under Agentforce Revenue Management).

That move is not a package upgrade. It is a rebuild of how products, pricing, and quotes work, plus a data migration for the records you still need in the new org.

This post is about the data slice only: Quotes, Products, Price Book entries, Assets, Contracts, and related records that have a home in the target org. Dataimporter is built to move those records between Salesforce orgs. It does not rebuild CPQ price rules, product constraints, quote UI, or Revenue Cloud pricing procedures. Say that up front so the project plan matches reality.

1. CPQ end of sale is not a lift-and-shift

CPQ was a managed package. Revenue Cloud is native Salesforce architecture. There is no Salesforce button that converts your CPQ org into Revenue Cloud with pricing logic intact. Salesforce has not announced a forced end-of-life date for CPQ; the pressure is on new features and net-new deals going to Revenue Cloud.

Consultants correctly focus on reimplementing product catalog models, pricing procedures, constraints, and quote experience. Admins and ops still have a separate problem: the commercial history and related records sitting in the CPQ org (or a legacy org) need to land in the Revenue Cloud org without a month of CSV exports.

2. What “migration” means here

Split the work into two tracks so nobody expects the loader to do the rebuild.

Rebuild (out of scope for a data tool)

• Product catalog model and bundling rules
• Pricing procedures, discount schedules, and constraints
• Quote UI, guided selling, and approval flows
• Integrations that called CPQ-specific APIs or custom Apex

Data move (in scope)

• Records and relationships from CPQ / shared standard objects into the target org where they map
• Typical candidates: Product2, Pricebook2, PricebookEntry, Quote, QuoteLineItem, Asset, Contract, Order, Account, Contact, plus Files and related custom objects your map includes
• Lookups preserved so quote lines still point at the right products and accounts after load

Object names above are illustrative of the commercial spine most teams care about. Your exact CPQ custom objects (SBQQ__ and friends) and Revenue Cloud targets depend on the implementation. Do not invent a 1:1 field map from a blog post. Confirm the map with your architect or partner before you load volume. Salesforce’s own CPQ and Revenue Cloud developer docs are the source of truth for object behavior; this post is the ops runbook for moving records once that map exists.

3. Where Dataimporter fits

Once the map exists, you need an org-to-org path that can:

• Connect the CPQ / source org to the Revenue Cloud org or sandbox
• Run sequenced Migration Templates with lookups preserved
• Filter for a sample load before cutover
• Bring related records and Files without a CSV hop for every object
• Snapshot before risky cutover loads so you have a rollback path

That is the Salesforce to Salesforce migration path in Dataimporter: templates, SOQL filters, formulas for transforms (owners, record types, external IDs), preview, then run. Pair it with backup when the target already has data you care about.

What Dataimporter does not do: convert price rules, rebuild bundle logic, or generate Revenue Cloud configuration. Those stay with Salesforce CPQ docs, Revenue Cloud implementation guides, and your partner.

4. Practical sequence for the data move

1. Document which source objects and fields still have a home in the Revenue Cloud / target model. Park anything that only existed for CPQ pricing engine behavior.
2. Export and back up the source org. Deduplicate Accounts, Contacts, and Products before you transform.
3. Stand up the Revenue Cloud org (or a dedicated sandbox): users, permission sets, product and price book structure you already rebuilt, migration key fields.
4. Seed a sandbox from production with a filtered subset so pricing UAT has realistic quotes and assets without full volume.
5. Sample-load mapped objects in dependency order (usually Accounts and Contacts, then Products / Price Books / Entries, then Contracts / Assets, then Quotes / Quote Lines, then Files). Reconcile counts and a handful of quote timelines.
6. Full job after sample sign-off. Snapshot target records you might overwrite if you are re-running into an org that already has data.

For the broader org-to-org pattern, see the Salesforce to Salesforce migration guide and the migration checklist. If a load goes wrong, use the rollback guide.

5. What not to expect

• Automatic conversion of CPQ price rules, product options, or custom Apex into Revenue Cloud procedures
• A perfect 1:1 object map for every CPQ custom object
• Quote line math that still depends on CPQ calculation engines after the records land

If a field only existed to feed CPQ calculation, leave it off the load map unless Revenue Cloud has an explicit home for it. Loading dead fields creates cleanup work and false confidence in UAT.

6. Run a filtered job into a Revenue Cloud sandbox

Before production cutover, pick one Account family or a date-bounded set of Quotes and run that subset end to end.

• Connect source and sandbox with the same Migration Template you will use later
• Map only objects that survived the rebuild
• Apply a tight SOQL filter so the sample stays reviewable
• Reconcile record counts, a few quote-to-line timelines, and File links
• Fix the map before you scale volume

If the sample is wrong, production will be too. That filtered S2S job is the cheapest place to learn.

Bottom line

CPQ to Revenue Cloud is a rebuild of pricing and quote experience, plus a separate org-to-org data migration for commercial history. Get the map from your architect, sample-load first, keep a rollback path, and do not ask a loader to invent price rules.

If you want to run that sequence between two Salesforce orgs without living in CSV exports, start with a filtered template on Dataimporter Migrate.