Legacy Salesforce CPQ handled complex pricing through Price Rules, often backed by a JavaScript Quote Calculator Plugin (QCP) for anything beyond simple math. It worked. It was also fragile, hard to debug, and slow at scale.
Some orgs saw multi-second (or worse) calculation times on quotes with a few hundred line items, because the logic ran client-side, one line at a time. Revenue Cloud (Agentforce Revenue Management) doesn't extend that model. It replaces it with something structurally different: Pricing Procedures.
Price Rules + JS QCP → Pricing Procedures
Pricing Procedures are a step-by-step, fully declarative pricing engine drag-and-drop rule sequences instead of custom code, with the ability to simulate pricing logic before you ever activate it in production.
That's not a UI refresh. It's a different way of building pricing logic entirely, and it means your existing QCP script is not a migration asset. It's a rebuild spec.
Why this matters now
Two things make this urgent rather than someday-urgent.
First, calculation performance changes the ceiling on your deal complexity. A server-side, declarative pricing engine processing logic across a full quote can handle thousands of line items in the time legacy CPQ needed for a few hundred. If your sales team has ever avoided quoting complex, multi-product deals because CPQ choked on the calculation, that ceiling moves.
Second, every custom QCP script your org has accumulated represents undocumented business logic. Nobody migrates that automatically. Someone has to read the old script, understand the business rule it encodes, and rebuild it declaratively in Pricing Procedures. The more customized your legacy pricing, the bigger this project actually is and the more it needs to start with discovery, not a migration tool.
Vedsphere's take
The teams who get burned by this transition aren't the ones with simple pricing. They're the ones who assume their pricing is simple, skip the audit, and discover mid-project that three years of "quick fixes" are buried in a QCP script nobody fully documented.
Before you scope a Revenue Cloud project, inventory your pricing logic like you'd inventory a legacy codebase before a rewrite. What's a straightforward Price Rule? What's actually a custom script encoding a business exception nobody wrote down? That distinction determines your timeline more than anything else in the project plan.
What to do next
Before you scope your Revenue Cloud migration, get a straight answer to one question: how much of your current pricing logic is genuinely declarative, and how much is buried in custom scripts that need to be reverse-engineered first?
Want a clear picture before you scope the project?
Send us your current CPQ pricing setup Price Rules, QCPs, and any custom logic. We'll give you an honest read on migration complexity before you commit to a timeline.
Sourcing note: performance figures and calculation-speed comparisons vary by org configuration and data volume. Treat directional claims here as illustrative, not guaranteed outcomes, and validate against your own data volume during a proof-of-concept.