Salesforce CPQ is end-of-sale and in maintenance mode. The official path forward is a large scale re-implementation to Agentforce Revenue Management. Cadence's path is a tooled, reviewable, analysis and conversion of your CPQ configuration into modern tooling.
Read-only analysis · Systematic review and mapping · Sandbox-only
Book a migration assessmentSalesforce CPQ hasnt been updated in years and it's your most expensive license. Let's change that.
One package, licensed per user. No separate calculation-service fee, no billing SKU, no per-API-call charge, and no premium tier that unlocks the features you need. Because the configuration is records your admins maintain with skills they already have, the implementation and every change after it cost a fraction of a CPQ project.
Pricing logic is data. Rules, rollups, lookups, and discount schedules are records you can query, export, diff, and deploy like any other configuration. There is no calculator JavaScript in a text field and no black-box price rule. Every calculation leaves a log, and the regression suite proves a change was safe before a rep ever sees it.
Cadence lives on the standard Quote and QuoteLineItem objects, with Lightning Web Components for the quote grid, configurator, and ramp builder. Calculations run inside your org and refresh in place, so reps are not waiting on page reloads or an external service. Every action is also a Flow action, a REST endpoint, and an MCP tool, so automation and AI agents use the same surface your reps do.
The main objection to a CPQ replacement is the migration itself. The rest of this page is the typical migration plan: what the tooling does, how the review works, and what you have to decide.
Every phase is run by a tool and produces a deliverable and action item.
Read-only. No writes anywhere.
A read-only inventory of your org: every price rule, discount schedule, bundle with its features, options, and constraints, summary variable, MDQ dimension, quote template, and custom field on the quote objects. Usage data shows what is live versus dead, so you migrate what you actually use. Custom calculator scripts are inventoried with the fields they read.
Deterministic. Every proposal tiered.
A rules engine converts each item to its Cadence equivalent and stamps it AUTO, ASSISTED, or MANUAL. The engine encodes the semantics that trip up hand migrations: exclusive discount-tier bounds become inclusive, calculator events map to engine stages, blank-check wrappers unwrap into only-if-blank actions, and lookup operators map one to one. Bundle graphs are pre-checked against the depth cap and for cycles, and every field a rule references lands in the field-gap register.
Systematic. One shared workspace.
We walk every ASSISTED and MANUAL proposal with your pricing owner in a review workspace, one screen per object. Each custom field gets an explicit decision: create it on the standard objects with a spec prefilled from your org, map it to an existing field, or skip it consciously. Consolidation suggestions (four or more same-shape formula rules become one lookup table) and dead-config exclusions are accepted or overridden here too. Decisions are versioned and feed straight back into a re-map, so a changed field decision updates every rule, formula, and lookup key that depends on it.
The sign-off gate.
When generation runs, it produces idempotent load scripts in dependency order, metadata for the new fields plus a permission set that grants them, and a checksummed manifest. Alongside the artifacts you get a human-readable migration plan: what moves, what consolidates, what stays behind and why. Nothing proceeds until you sign it.
Sandbox only. Never production.
The runner checks the target org and refuses anything but a sandbox, scratch, trial, or Developer Edition org, and refuses the org that was analyzed. The result is a sandbox with your catalog, bundles, pricing configuration, and ramp schedules in place.
Empirical. Side by side.
Re-price ten to twenty representative real quotes in the sandbox and diff line totals against the originals. Where they differ, the per-line price trace shows exactly which rule or lookup produced the number. Fixes go through the same map, review, and generate loop and re-run idempotently. Once totals match, those quotes become regression baselines, and your reps do acceptance testing on the grid, the configurator, and the approval flow.
Standard Salesforce deployment tooling.
The validated sandbox configuration moves to production through standard Salesforce deployment tooling. A hypercare window follows, with a decommission plan that keeps legacy Salesforce CPQ quotes readable for reporting.
Most Salesforce CPQ orgs move from assessment to sandbox validation in weeks, not quarters. The exact scope, including how much custom calculator code has to be re-expressed as rules, is quoted after phase one, and you see it before you commit to anything.
Anything that cannot be converted is flagged and entered in the gap register with a rebuild recommendation.
| Your Salesforce CPQ configuration | What happens |
|---|---|
| Product features and options, including min/max, required, and quantity scaling | Converted, with option graphs pre-checked against the bundle depth cap and for cycles |
| Discount schedules and tiers | Converted, including the bound math (their upper bounds are exclusive; ours are inclusive) |
| Formula price rules | Converted to rules and actions, with calculator events mapped to engine stages and blank-check wrappers unwrapped into only-if-blank actions |
| Lookup price rules | Converted to lookup tables. Operators map one to one, and anonymous Field1–Field4 lookup data becomes purpose-built named objects |
| Summary variables referenced by pricing | Converted to rollups plus a quote rollup field |
| MDQ yearly dimensions | Converted to shared ramp schedules |
| Your default quote template's line columns | Generated as a grid view, so the new quote grid matches the document your team already knows |
| Custom calculator JavaScript (QCP) | Flagged as a blocker. Arbitrary calculator code is re-expressed by hand as rules, rollups, and lookups, with the script's declared field reads inventoried for you |
| Product rules, templates and document generation, guided selling, approvals | Entered in the gap register with rebuild recommendations: Cadence's approvals extension, your existing document-generation and e-signature tools, and Flow |
Four things, none of them a project on their own.
A recently refreshed sandbox to migrate into, and a production user with read access for the analysis. Authentication is OAuth through the Salesforce CLI.
One person who can make judgment calls: usually a RevOps lead or the CPQ admin. Plan on a few working sessions in the review workspace, and one sitting to read and sign the migration plan.
Real quotes spanning bundles, ramps, discounts, amendments, and renewals. They are the validation set in phase six and become your regression baselines after go-live.
Document generation, e-signature, approvals, billing hand-offs, and any integration or report that reads Salesforce CPQ objects. The gap register and the cutover plan cover them only if we know they exist.
The analysis is read-only and it produces something useful whether or not you pick Cadence: a complete, usage-annotated inventory of the CPQ configuration you are running today, and an honest list of what would have to be rebuilt to move anywhere.
Book a migration assessment