Platform
Salesforce CPQ end of sale: the 2026 migration playbook to Revenue Cloud
Salesforce CPQ has been end-of-sale since March 2025, frozen but still supported, and the move to Revenue Cloud (Agentforce Revenue Management) is a re-implementation of your pricing logic, not an upgrade. Here is what actually moves, what you rebuild from scratch, and the phased plan that keeps quotes flowing while you do it.
If your org runs Salesforce CPQ, you are on a product with a clock on it. It still works, it still gets support, and Salesforce will not switch it off next quarter. It also will not get another real feature.
CPQ went end-of-sale in March 2025. No new customers, no new innovation, and extended support reported to run through at least March 2027. Your quoting engine is now a maintenance release, and the successor, Revenue Cloud, is where the platform’s attention has gone.
The advice I give teams on classic CPQ is the same every time: the migration is a re-implementation of your pricing logic, not an upgrade, so budget it, staff it, and sequence it like one. There is no in-place converter that turns your SBQQ__ package into the new model. Treat “we’ll just upgrade to Revenue Cloud” as the sentence that gets a program into trouble.
End of sale is not end of life, and the difference buys you time
The two phrases get used interchangeably and they are not the same. End of sale means Salesforce stopped selling CPQ to new customers and stopped building it. You can still renew, still add licenses and users, and still open support cases. The official end-of-life page frames it exactly that way.
Salesforce has not published a hard end-of-life date. Third-party guidance clusters around extended support through March 2027, with informed guesses at a full retirement somewhere around the end of the decade. Treat those as guesses. Nothing in your org breaks on a date nobody has announced.
What that buys you is planning room, not a reason to defer. The clock that matters is not Salesforce’s retirement date. It is the day your pricing rules get complex enough that a frozen product can no longer carry them, and you find that out during a deal, not during a planning meeting. Pay the technical debt down on your schedule while you still have one.
The lineage, so you can read the docs
Half the guidance online describes the wrong product, so the names matter. The path runs from Steelbrick, which Salesforce acquired in 2015 and shipped as Salesforce CPQ, a managed package with the SBQQ__ namespace, through Revenue Lifecycle Management (RLM), then Revenue Cloud Advanced (RCA), to today’s umbrella name, Agentforce Revenue Management.
The rebrands are cosmetic. Your licenses and renewal dates carry across them. The shift underneath, from a managed package bolted onto the platform to a native, API-first product built on core objects, is the real one, and it is what makes this a rebuild.
I covered the agent layer that now sits on top, where an agent can build a quote and where a human still has to sign, separately. This piece is the plumbing underneath it: getting off CPQ and onto the engine an agent can safely price from.
What the new model replaces, object by object
CPQ is a managed package. Revenue Cloud is native. That one sentence explains almost every migration surprise, because none of your SBQQ__ objects exist in the new world and the concepts you built on have new homes.
The pieces that change:
- Product Catalog Management (PCM) separates the product from how it is priced and packaged. Configurable bundles are rebuilt with Component Groups, and structured Attributes (tier, term, region) drive configuration, pricing, and rules.
- Transaction Line Items replace
SBQQ__QuoteLine__c, and the Transaction Line Editor replaces the Quote Line Editor. The Twin Fields pattern, where a value lived on both the quote and the line, is gone. - Pricing Procedures, built as Expression Sets, replace Price Rules. Attribute-based pricing moves into decision tables rather than fields written by a rule.
- The Business Rules Engine carries what Product Rules used to do, split into qualification and disqualification rules for what can be sold and configuration rules, expressed in a constraint-modelling language, for what fits with what.
- The Dynamic Revenue Orchestrator decomposes an order into fulfillment steps natively, which is new ground for teams whose CPQ never reached past the quote.
If you wrote a Quote Calculator Plugin in Apex, there is no equivalent to port it to. That logic gets redesigned as configuration in the pricing engine, which is usually a good outcome and always a real project.
What migrates, and what you rebuild by hand
Getting this split straight is the thing to do before anyone quotes you a timeline.
Salesforce provides a first-party migration path, and partner accelerators from firms like Forsys, IdeaHelix, and Prodly automate parts of the catalog and transactional move. What they carry across is data: quotes, orders, contracts, subscriptions, and assets, plus the product-catalog elements the new model supports.
What no tool moves is the logic. Your Price Rules and Product Rules, your QCP Apex, your integrations, your document templates, page layouts, and permission sets do not convert. They get rebuilt against the new engine, because the engine is different by design.
The test I use is simple. Anything that is a record has a migration path, and anything that is a rule is a rebuild. A subscription is a record; the logic that decided its price is a rule. Plan the record migration as data work and the rule rebuild as design work, and never let a vendor deck blur the two into one line item.
Before you scope any of it, inventory what you have. A quick pass over the managed-package objects tells you the size of the rebuild:
-- How much pricing and product logic is really in play?
SELECT COUNT(Id) FROM SBQQ__PriceRule__c WHERE SBQQ__Active__c = true
SELECT COUNT(Id) FROM SBQQ__ProductRule__c WHERE SBQQ__Active__c = true
-- Bundles and options: the configurator rebuild
SELECT SBQQ__ConfigurationType__c, COUNT(Id)
FROM Product2 WHERE SBQQ__ConfigurationType__c != null
GROUP BY SBQQ__ConfigurationType__c
-- Custom calculation logic that has no direct successor
SELECT ApiVersion, NamespacePrefix, Name
FROM ApexClass WHERE Name LIKE '%Calculator%' OR Name LIKE '%QCP%'A count of active price rules and product rules, the spread of bundle types, and every class touching the calculator: those three numbers turn “migrate CPQ” from a slogan into a scope.
The phased plan that keeps deals flowing
The failure mode is the big-bang cutover, where reps quote in the old system on Friday and the new one on Monday and nobody has run a real deal through it. Avoid it. Every credible plan I have seen runs in phases with a parallel period.
A sequence that works:
- Assess and map, four to six weeks translating each CPQ process into its Revenue Cloud equivalent, marking what is out-of-the-box, what is configuration, and what was custom Apex with no successor.
- Prove the pricing by building the two or three pricing models that carry most of your revenue as Expression Sets, and confirm they produce the same numbers your current rules do.
- Rebuild the catalog, redesigning products, bundles, and attributes in PCM. Cut the duplicated and abandoned catalog entries here rather than carrying them across.
- Migrate the data: quotes, orders, contracts, subscriptions, and assets, moved with the first-party path or an accelerator.
- Run in parallel for four to six weeks, putting identical deals through both systems and reconciling price, discount, approval, and integration output line by line.
- Roll out and hold. Pilot one product line or a slice of the sales team, then expand by business unit, with a hypercare window where a human watches every edge case.
A clean org can reach a first release in four to six months. A complex production org, with heavy rules, active subscriptions, billing, and integrations, is realistically a nine-to-eighteen-month program. Anyone quoting a weekend is selling you the crash.
The bridge that reduces risk most: new deals start in Revenue Cloud as soon as the pricing is proven, while existing contracts stay in CPQ and migrate at renewal. You never move a live contract mid-term, and the old system drains instead of getting yanked.
Where the money and the surprises hide
Revenue Cloud is an add-on, sold per user on top of your Sales or Service Cloud licenses. Third-party reporting puts list pricing in the region of a Growth tier around $150 per user per month and an Advanced tier around $200, usually discounted at volume. Confirm the current numbers against a Salesforce quote, because add-on pricing moves and the published figures are third-party estimates.
The cost that ambushes teams is not the license. It is the rebuild of logic that “looked simple in a spreadsheet” and turned out to encode a decade of exceptions. Sales and finance rarely agree on what the rules even are until someone tries to rewrite them, and that conversation is the migration, more than any config screen.
Test all of it against Salesforce’s seasonal releases and in a sandbox that mirrors production, not a scratch org with three clean products. A sandbox strategy that keeps a full-copy environment on the preview release is the difference between finding a pricing regression in October and finding it in a customer’s contract in February.
Before you start, get a single view of how much rule debt and custom Apex your org is carrying. The org health scorecard is a fast first read, and our implementation and consulting team runs this kind of re-platforming as a normal engagement.
Understanding the basics
Is Salesforce CPQ being discontinued?
Salesforce CPQ reached end of sale in March 2025, which means no new customers and no new features, but it is not discontinued. Existing customers can still renew, add licenses, and get support, with extended support reported through at least March 2027. Salesforce has not announced a hard end-of-life date.
Can you migrate from Salesforce CPQ to Revenue Cloud automatically?
No. There is no in-place converter. Salesforce and partner accelerators can migrate transactional and catalog data such as quotes, orders, contracts, and subscriptions, but pricing rules, product rules, custom Apex, integrations, and document templates are rebuilt against the new engine. Treat it as a re-implementation, not an upgrade.
What is Revenue Cloud called now?
The product line has moved from Salesforce CPQ through Revenue Lifecycle Management and Revenue Cloud Advanced to the current umbrella name, Agentforce Revenue Management. Licenses and renewal dates carry across the rebrands. The underlying shift is from a managed package to a native, API-first product on core platform objects.
How long does a CPQ to Revenue Cloud migration take?
A simple org can reach a first release in four to six months. A complex production org with extensive rules, active subscriptions, billing, and integrations is usually a nine-to-eighteen-month program, and full enterprise adoption often runs twelve to twenty-four months. Phased rollout with a parallel-run period is standard.
Start with the inventory, not the demo
If you do one thing this quarter, count your active price rules, your product rules, and your calculator Apex. That number, not a keynote, tells you whether this is a two-quarter project or a two-year one.
The demo will always look easy on three clean products. Your org is not three clean products, and the sooner you know exactly how much logic you are carrying, the sooner the plan stops being a guess.
Weighing a CPQ migration and want a straight read on the size of the rebuild before you commit a budget? Talk to us, and bring your rule counts.
