Salesforce CPQ is end of sale, not end of life. Salesforce has stopped selling it to new customers, but existing customers can keep using it, renew, add users and receive support, and nobody is being forced to migrate. Its successor is Revenue Cloud Advanced, which runs natively on the platform instead of as an installed managed package. Move when CPQ is holding back how you sell, or when a major quoting redesign is coming anyway. If quoting works and your pricing model is stable, staying put is a defensible choice.
What end of sale means for a CPQ customer
Salesforce states plainly that its quote-to-cash investment has shifted to Revenue Cloud Advanced, and that CPQ is in a maintenance phase with support and critical fixes. As of this review, no end-of-life date has been announced. In practice, that means the CPQ you run today will keep working, but you should not expect significant new capability in it.
The decision that matters is less about the license and more about where your next round of investment goes. Every new price rule, custom script or bundle you add to CPQ is work you may later have to redo. If a large quoting project is on the roadmap, settle the platform question before it starts, not halfway through.
What actually changes between the two
Revenue Cloud Advanced is not CPQ with a new name. Salesforce describes the two as different architectures, and says CPQ objects, custom fields, price rules and scripts do not map directly across. Treat the move as a reimplementation of your quoting process on a new data model, with your CPQ org serving as the requirements document.
| Area | Salesforce CPQ | Revenue Cloud Advanced |
|---|---|---|
| Foundation | Managed package installed on top of Salesforce | Built into the core platform, API-first |
| Product catalog | SKU-based products, bundles and options | A single attribute-based catalog shared across channels |
| Configuration | Product rules on bundles | Rules-based and constraint-based configurator |
| Pricing | Price rules, discount schedules and custom scripts | Declarative pricing procedures and pricing elements |
| After the quote | Orders, contracts and subscriptions on CPQ objects | Order capture, contracts, asset lifecycle, amendments and renewals |
| Selling channels | Mainly rep-led quoting | Direct, partner, ecommerce, self-service, and agents through APIs |
| Invoicing | A separate billing product, if used | Consumption and invoicing in Advanced; Revenue Cloud Billing for payments and collections |
Three changes deserve the most design time. The product catalog shifts from a long list of SKUs to products described by attributes such as size, tier or region, which can collapse dozens of near-identical products into a few. Pricing moves from rules and scripts into pricing procedures that admins can read and change, so logic buried in a quote calculator plugin has to be understood and rewritten, not copied. And the path from accepted quote to order, contract and asset changes shape, which affects every integration that reads those records, especially the one feeding your ERP.
Signals that it is time to move
- You are adding a revenue model CPQ handles awkwardly, such as usage-based or hybrid subscription and consumption pricing.
- Partners, a customer portal or an online store need to configure and price the same products your reps sell.
- Quote calculation is slow on large deals, and the fixes so far have been more custom script.
- Only one person understands the price rules, and that person is busy or leaving.
- Amendments and renewals regularly produce wrong quantities or prices that someone corrects by hand.
- You plan to put Agentforce or other automation in front of quoting and need catalog and pricing exposed through APIs.
- A catalog overhaul, repricing or acquisition is already forcing a large rebuild.
One signal alone rarely justifies the project. Two or three, especially paired with a planned redesign, usually do.
When staying on CPQ is the right call
Plenty of CPQ orgs are doing their job. If reps quote quickly, approvals are traceable, renewals come out right and finance trusts what arrives downstream, a migration spends real money to arrive roughly where you are. That money may be better spent cleaning up the product list, retiring unused price rules and documenting the ones that remain, which also makes an eventual move cheaper.
Waiting also makes sense when the business is mid-change: pricing strategy under review, a new ERP being selected, or a sales reorganization in progress. Migrating onto a pricing model that is about to change means doing the design twice. In those cases, freeze major new CPQ customization, keep maintaining what exists, and revisit once the business decisions settle.
How to plan the move
Salesforce puts a typical CPQ-to-Revenue Cloud Advanced migration at three to six months from discovery to go-live, with complexity driving where you land. The sequence below keeps business decisions ahead of configuration.
- Inventory what CPQ does today: every product rule, price rule, discount schedule, script, approval and template, and mark which ones still fire.
- Rationalize the catalog before mapping it. Retire products nobody has quoted recently and group near-duplicates into attribute-based products.
- Rewrite pricing as a sequence of steps the business signs off on, then build it as pricing procedures, not as a translation of old scripts.
- Map the post-quote flow: how orders, contracts and assets are created, and what your ERP, billing and reporting read from them.
- Decide what history migrates. Active contracts and subscriptions usually must; closed quotes may only need to stay reportable.
- Pick a cutover rule for in-flight quotes, such as finishing open quotes in CPQ while new quotes start in Revenue Cloud.
- Test renewals and amendments on real customer examples, since those are where errors surface months later.
Active subscriptions are the hardest part. A customer mid-term on a CPQ contract still needs a correct amendment next quarter and a correct renewal next year, so their contract and asset records must arrive in Revenue Cloud with the quantities, prices and dates finance already agreed to. Reconcile a sample of migrated contracts against billing before cutover, and keep CPQ readable for a period afterward so anyone can check how an old deal was priced.
Who should own the decision
This is a revenue operations decision with finance at the table, not an admin upgrade. Sales operations owns how products are sold, finance owns how revenue is recognized and billed, and IT owns the integrations that carry orders onward. Name one business owner for pricing logic before the project starts. Most delays in quoting migrations trace back to pricing questions nobody had authority to answer.
