Salesforce CPQ end of life: what it means for manufacturers
Salesforce CPQ is not at end of life. Salesforce calls it end of sale: no new customers, while existing customers keep their licenses, renewals and support. This guide covers what changed, what replaces it, what a migration involves, and the options for a plant with complex configuration rules.
End of sale, not end of life
Salesforce’s page on the subject, dated July 10, 2026, says Salesforce CPQ is “end of sale, not end of life.” In practice:
- New customers can no longer buy it. Salesforce stopped selling new Salesforce CPQ licenses to companies that do not already have it.
- Existing customers keep it. They keep their licenses, can add users, can renew and keep receiving support.
- Nobody is forced to move. Salesforce states there is no forced migration.
- No new features. Salesforce describes the product as in a maintenance phase: supported, with no new development.
Salesforce has announced no end-of-life date and no end-of-support date. The March 2025 end of sale comes from partner timelines, such as Kugamon’s, not from Salesforce’s page. A March 31, 2027 date circulates on blogs; Kugamon notes it is not official, and Advanced Communities calls any specific end-of-life year speculation.
Where Salesforce CPQ came from
Salesforce agreed to acquire SteelBrick on December 23, 2015, according to its filing with the SEC. SteelBrick’s product became Salesforce CPQ: a managed package that sits on top of Salesforce with its own object model. Its objects still carry the SteelBrick namespace, SBQQ, so every custom field, trigger, flow and report that touches a quote touches an SBQQ object.
The successor takes a different route. Salesforce describes it as native to Salesforce core: quotes, products and prices live in Salesforce’s standard objects instead of a package’s. That difference is why a move is a rebuild, not an upgrade.
What replaces it: Revenue Cloud Advanced
Salesforce names Revenue Cloud Advanced as the successor, with Revenue Cloud Billing for billing and collections. The product has carried three names in two years. Forsys, a Salesforce partner, gives the sequence: Revenue Lifecycle Management in spring 2024, then Revenue Cloud Advanced, then Agentforce Revenue Management at Dreamforce 2025. Trailhead confirms the latest name and notes the older ones still appear in the app and the documentation.
| Salesforce CPQ | Revenue Cloud Advanced | |
|---|---|---|
| Where the data lives | A managed package with its own objects | Salesforce’s core objects |
| Product catalog | SKU-based bundles | Attribute-based products |
| Pricing | Price rules and custom scripts | Declarative pricing procedures |
| Configuration rules | Product rules | Validation, selection and constraint rules |
| New features | None | All new development |
The catalog, pricing and data rows come from Salesforce’s comparison on its end-of-sale page. Trailhead describes the configuration rules: they keep products compatible, add required items and block invalid options, with constraint-based modeling for the complex cases.
What a migration involves
Salesforce is direct about it: Salesforce CPQ objects, custom fields, pricing rules and scripts do not map directly to the successor, so a move needs a structured migration and data transformation. Forsys goes further and says every rule, object and integration gets rebuilt, not migrated.
What gets rebuilt, from the partners’ lists:
- The product catalog, rebuilt around attributes instead of bundles.
- Configuration logic, price rules and the lookup tables behind them.
- Approval workflows and quote document generation.
- Custom code: Apex, Visualforce and the Quote Calculator Plugin scripts.
- Contracts and amendments, billing, ERP integrations and every report built on the CPQ objects.
Salesforce’s migration page lists four strategies: lift and shift, selective transformation, full rationalization, or starting the successor with a new business unit or product line. It also lists four rollouts. In the bridge rollout, new business goes to the successor while existing contracts run to renewal on Salesforce CPQ. Salesforce puts a typical migration at three to six months from discovery to go-live, and names partner tools for the data work, among them Forsys RevRamp and Prodly. Forsys adds that data quality and catalog cleanup cause more delay than the platform does.
List who understands the custom code. Advanced Communities notes that in complex setups, only one or two people know how the custom pieces fit together. Plan the rebuild around their time.
What it means for a manufacturer with complex rules
A plant that runs Salesforce CPQ today can keep running it and renewing it. No end date exists. Nothing new will arrive in it, though, so better rule handling, a new product line or a new quoting process means planning a move or picking another tool.
For manufacturers, three things deserve a close look before choosing:
- Rules outside Salesforce. Many plants keep the real configuration logic in an Excel builder or in the ERP, and Salesforce CPQ only holds the sellable bundles. Logic outside Salesforce has no import path into the successor. It has to be modeled again as attributes, constraint rules and pricing procedures.
- Engineering math. Dimensions, weights, machine time and material yield sit naturally in an Excel builder. A sales catalog has no obvious home for them, so they may need custom code or a separate service.
- Drawings. If a quote has to go out with a drawing, check how the drawing will be produced. The sources on both products describe quote documents, not engineering drawings.
Three options
| Option | Fits when | Watch for |
|---|---|---|
| Stay on Salesforce CPQ | Your setup works, and the product range and process are stable | No new features, and a rebuild that still waits for you later |
| Move to Revenue Cloud Advanced | Sales runs in Salesforce, and you want quotes, contracts, orders and billing on Salesforce’s core objects | Every rule, script and integration rebuilt; catalog redesign |
| Move the configuration rules to an app built from your own rules | The real rules live in an Excel builder or the ERP, quotes need engineering math or drawings, and Salesforce stays the CRM | A custom app to own; it has to connect to Salesforce and the ERP |
The third option is what ThriveAI builds. The rules are read from the workbook or the ERP, run in an app that is checked against the workbook’s saved results, and the finished quote can be written back to Salesforce. Converting an Excel quoting workbook into a web app describes how that is done and checked. When the rules live in an Excel builder, the first step is a free map of that workbook and its gaps.
Map the rules that live outside Salesforce
Send Derik the Excel builder that holds your real configuration rules. He sends back a free map of the logic any move would have to model again, with its gaps.
Start a conversation