CPQ to Revenue Cloud migration: phases, effort, cutover

A migration from Salesforce CPQ to Revenue Cloud is a rebuild on Salesforce standard objects, with a new pricing logic, a new configurator and new reports. Salesforce Help splits it into three phases: prepare, choose a strategy, execute, each finished before the next. Salesforce names 3 to 6 months from discovery to go-live as typical, longer for complex orgs. During that time CPQ keeps running in the same org. Tools speed up the mapping of products and prices, but three decisions stay with you: who owns the price, when you cut over and how much history you move. Without those decisions, any partner estimate is guesswork.

What actually changes between CPQ and Revenue Cloud?

Salesforce CPQ and Salesforce Billing came from SteelBrick, which Salesforce bought in December 20151. Both are managed packages with their own objects. Revenue Cloud, which Salesforce Help currently calls Revenue Management and which started as Revenue Lifecycle Management (RLM), is built on standard objects. Salesforce’s CPQ end-of-life page2 puts it briefly: CPQ uses custom objects in a managed package, Revenue Cloud a standard data model with API-first quoting logic, and “CPQ-specific objects, custom fields, pricing rules, and scripts don’t map directly”.

What that means for the migration, block by block:

Area	Salesforce CPQ and Billing (SteelBrick)	Revenue Cloud	Consequence for the migration
Data model	Package objects, such as SBQQ__Quote__c	Standard objects such as Quote, Order, Asset	Remap every field, flow and integration
Products	Products with options and features	Catalog, classifications, attributes, bundles	Redesign the catalog, not just copy it
Configuration rules	Product rules	Configuration rules and the constraint rules engine with CML	Model the rules again
Pricing	Price rules, JavaScript Quote Calculator Plugin3	Pricing procedures, decision tables	Rebuild logic and test it with real quotes
Contracted business	CPQ subscriptions	Assets with state periods	Create assets for every open subscription
Billing	blng package	Revenue Cloud Billing on standard objects	Separate cutover, see below
Reporting	Reports on package objects	Reports on standard objects	Recreate everything

The detailed comparison is in Salesforce CPQ vs Revenue Cloud: the real differences. For planning, one point is enough: there is no upgrade button, and every line in this table is a work package.

Salesforce splits the migration into three phases

The Help article Migrate to Revenue Management4 sets out the frame. The work runs in phases, and Salesforce asks you to “complete all the tasks of each phase in the mentioned sequence before moving to the next phase”:

1. 01

   Prepare

   Assess which Revenue Cloud capabilities you need, and settle operational planning. Help lists two practical requirements here that apply "regardless of your migration strategy": retaining the CPQ licence and coexistence during the transition.

2. 02

   Choose a strategy

   Decide the migration strategy, how transactional data moves and how rollout and cutover work. Help says these rollout decisions belong early, because they affect scope, integrations, cutover and change management.

3. 03

   Execute

   Migrate product data, asset data and billing data, rebuild reporting and run change management as a parallel workstream from the start.

Help sets no fixed timeframe. The CPQ page names 3 to 6 months as typical and adds that complex implementations can take longer. My reading: 3 months is realistic for a clean org with few price rules, and a grown org with years of custom scripts belongs at the upper end or beyond. A technical debt assessment before the estimate tells you which one you have.

The licence point matters for the budget. While you build, CPQ keeps quoting in production, so you pay for CPQ and Revenue Cloud in parallel for the length of the project. That is one more reason not to stretch the migration over years.

Data moves in the order of its dependencies

Help names three groups: product data, asset data and billing data. The order inside them follows the dependencies that the Revenue Cloud Developer Guide lists in its object deployment reference5. Parents before children, metadata before records:

1. Catalog structure: attribute definitions and picklists, product classifications, then the products themselves.
2. Selling and pricing: product selling models, price books, cost books, price book entries, then price adjustments.
3. Bundles and catalogs: component groups and related components, catalogs and categories.
4. Assets: one asset for every open CPQ subscription, so that amendments and renewals work in Revenue Cloud. On Trailhead6, every amendment starts from an asset and runs through a quote and an order.
5. Billing data: only if you use Salesforce Billing today. That part has its own article: from Salesforce Billing to Revenue Cloud Billing.

How catalog and prices then move from sandbox to production is a separate topic: Revenue Cloud deployments.

What do migration tools do, and what do they not?

On its CPQ page, Salesforce names three partner offerings: Forsys RevRamp for data transformation and schema mapping, IdeaHelix with automation across the migration lifecycle, and Prodly, which analyses the existing CPQ setup. Salesforce also says that about 15% of Revenue Cloud Advanced customers are companies that migrated from CPQ.

These tools save time on products, price book entries and subscriptions. Help is clear about the limit: tools do not replace human design decisions, “especially for custom logic and integration remapping”. A price rule that fixes a historical rounding problem, a script that reads a field from SAP, an approval chain with exceptions for one country: someone has to decide whether that logic is still needed and how it looks in a pricing procedure.

When you compare partner offers, I would ask each partner for the same three numbers: how many price rules, product rules and scripts they counted in your org, and what they plan for each. A partner who quotes without counting is selling a range. How to set up such a comparison and which commercial model fits is covered in fixed price vs time and materials and in the AI masterclass chapter on AIforce and system integrators.

Worked example: a component maker on CPQ since 2018

Assume a component maker has used Salesforce CPQ since 2018. It has 60 quoting users, 1,200 products, 40 price rules, a quote calculator plugin with logic added over the years, and 3,500 active service subscriptions for remote monitoring. Invoices come from SAP. All figures are assumptions.

The plan could look like this:

• Weeks 1 to 4, prepare: count rules and scripts, decide which logic disappears, set SAP as price master for list prices and Revenue Cloud for discounts.
• Weeks 5 to 8, strategy: cutover per product line, starting with spare parts and service, machines last. Subscriptions move in batches, always before their renewal month.
• Months 3 to 5, execute: catalog and pricing in the pipeline, assets for the first batch of subscriptions, reports rebuilt, sales trained per product line.
• Month 6: last product line moves, CPQ goes read-only, the CPQ licence ends at the next renewal date.

Since Billing is not in use, this scenario has no billing cutover. With Salesforce Billing it would add a period-end cutover and the sign-off from finance.

Training per product line covers only part of the change management that Help asks for as a parallel workstream. 60 users who have quoted in CPQ for years also need to understand why their tool is changing. Why training alone rarely does it is described in Salesforce change management: why rollouts fail.

What must the client decide itself?

These decisions belong to you, not to the partner or the tool:

• Price master: which prices come from SAP, which are calculated in Revenue Cloud. Two masters for one price never work.
• Cutover model: all at once, per product line or per country, and the date CPQ becomes read-only.
• History: what moves, what is archived, what stays readable in CPQ.
• Ownership after go-live: who maintains classifications, constraint rules and pricing procedures. An object ownership matrix helps when several partners work in the same org.
• Licence end: when the CPQ contract ends. CPQ has no end-of-life date, so this date is entirely yours.

Whether you should move at all, or stay on CPQ for now, is the question of keep Salesforce CPQ or move to Revenue Cloud. The whole topic is covered in the masterclass chapter from CPQ to Revenue Cloud, and steering several partners through such a move is part of my work in partner governance.

Sources6

1. 1bought in December 2015 (opens in a new tab)siliconangle.com
2. 2CPQ end-of-life page (opens in a new tab)salesforce.com
3. 3JavaScript Quote Calculator Plugin (opens in a new tab)developer.salesforce.com
4. 4Migrate to Revenue Management (opens in a new tab)help.salesforce.com
5. 5object deployment reference (opens in a new tab)developer.salesforce.com
6. 6Trailhead (opens in a new tab)trailhead.salesforce.com