Migrating from Salesforce CPQ to Revenue Cloud Advanced

Many companies deployed Salesforce CPQ, sometimes alongside Salesforce Billing, between 2015 and 2023. These implementations work, but they have often accumulated price rules, product rules, a Quote Calculator Plugin and Apex code that nobody dares touch any more. Revenue Cloud Advanced changes the picture. This guide explains how to approach the migration, based on our experience of both worlds at Meir IT (CPQ Specialist and Revenue Cloud Consultant certifications).

Why migrate from Salesforce CPQ to Revenue Cloud Advanced?

Revenue Cloud Advanced (RCA) is Salesforce's native quote-to-cash suite, now sold as Agentforce Revenue Management. It is progressively replacing Salesforce CPQ in the vendor's strategy. The reasons to migrate are both strategic and operational:

• Product roadmap: Salesforce now steers new customers towards Revenue Cloud Advanced and is focusing innovation (including Agentforce) on the native platform. Staying on CPQ means staying on a branch that will see little evolution.
• Standard data model: quotes, orders and assets are built on standard Salesforce objects, which simplifies reporting, integrations and the use of Data 360 or AI agents.
• More maintainable pricing: pricing procedures and decision tables instead of a pile of price rules and JavaScript code.
• Constraint-based configurator: easier to read than dozens of product rules for a complex catalogue.
• Native orchestration: the Dynamic Revenue Orchestrator (DRO) handles post-sale fulfilment, where CPQ required custom development.

For a full overview of the components, see our Revenue Cloud, RCA, RCB and ARM guide.

Is it an upgrade or a new implementation?

This is the first thing to understand: there is no "upgrade" button from CPQ to RCA. Salesforce CPQ lives in a managed package (the SBQQ namespace, and blng for Billing) with its own objects: Quote, Quote Line, Subscription, Price Rule… Revenue Cloud Advanced uses different objects, different engines and different logic. The two can coexist in the same org, but the CPQ configuration does not "convert".

In practice, a migration means:

• rebuilding the catalogue, prices and rules in RCA, taking the opportunity to simplify;
• migrating live data (contracts, subscriptions, assets and possibly open quotes) into the new model;
• adapting integrations, reports, automations and documents;
• training teams on new screens and new habits.

It is a true re-implementation, but rarely a blank page: your business rules, catalogue and history make an excellent specification, provided they are audited.

When should you migrate?

There is no single date that suits everyone. The signals that the time has come:

• you are planning to redesign your catalogue or pricing policy;
• you are moving to a subscription or usage-based model that CPQ handles poorly in your current configuration;
• calculation time on large quotes is becoming a problem, or the Quote Calculator Plugin has turned into a black box;
• you want to bring billing into Salesforce (RCB) or replace Salesforce Billing;
• you are launching an Agentforce project and want agents to rely on clean quote and asset data.

Conversely, if your CPQ is stable, simple and has no short-term changes planned, a rushed migration adds little value. You are better off preparing it calmly: cleaning up the catalogue, documenting the rules, making subscription data reliable.

The steps of a CPQ to Revenue Cloud migration

1. Audit of the existing CPQ setup: inventory of products, bundles, features, options, price rules, product rules, summary variables, QCP, Apex, flows, document templates and integrations. Each item is classified: keep, simplify or drop.
2. Target scoping: which processes go into RCA, which into RCB or the ERP; which users, which entities.
3. Catalogue re-modelling in Product Catalog Management: attributes, classifications, bundles. Dozens of near-identical CPQ products often become a single product with attributes.
4. Pricing: translating price rules and discounts into pricing procedures and decision tables.
5. Configuration: translating product rules into configurator constraints.
6. Quotes, approvals and documents: approval process, PDF template.
7. Lifecycle: orders, contracts, assets, amendments, renewals, DRO orchestration where needed.
8. Billing: migrating from Salesforce Billing to RCB, or adapting the ERP interface. See our article on Revenue Cloud Billing.
9. Data migration: active contracts and subscriptions converted into Revenue Cloud assets, with consistent dates, quantities and prices.
10. Testing and coexistence: tests on real cases (new sale, upsell, renewal, cancellation), then cutover scope by scope (one entity, one product line, one team).

Mapping the main concepts: CPQ vs RCA

The most common pitfalls

• Trying to reproduce everything identically. A migration that copies ten years of CPQ rules into RCA carries the technical debt across. Every rule has to earn its place.
• Underestimating the subscription migration. If the migrated assets are wrong (end dates, prices, co-termination), the first renewal will expose it in front of the customer.
• Forgetting the ecosystem: document templates, e-signature, reports, dashboards, ERP integrations, automations that read SBQQ objects.
• Switching billing mid-cycle without a reconciliation plan: plan a clean cutover date and check the first billing runs.
• Neglecting change management: sales reps are getting a new data-entry screen. A short training session with hands-on cases beats a long manual.

CPQ to Revenue Cloud migration checklist

• ☐ Complete inventory of the CPQ configuration (rules, QCP, Apex, flows, documents)
• ☐ List of integrations that read from or write to CPQ / Billing objects
• ☐ Target catalogue approved by sales and finance
• ☐ Pricing and discount rules documented, with priced test cases
• ☐ Migration strategy for active contracts and subscriptions, with consistency checks
• ☐ Decision on billing: RCB, ERP or temporary coexistence
• ☐ Coexistence plan and cutover date per scope
• ☐ Test scenarios: new sale, amendment, renewal, cancellation, credit note
• ☐ User training and support for the first few weeks
• ☐ Decommissioning plan for CPQ components that are no longer needed