Salesforce CPQ reached End of Sale in March 2025 and Revenue Cloud Advanced is its successor. The two products are built on different architectures, so this is a rebuild rather than an upgrade. There is no turnkey converter, which means the work that decides whether the project goes well happens before you build anything: knowing exactly what you have.
Swantide reads both orgs through the Salesforce connection you already have. This guide is a prompt library for the discovery and design work, followed by a migration plan you can adapt.
What Swantide reads on each side
Salesforce CPQ (source) | Revenue Cloud Advanced (target) | |
Data model | Every | Standard and custom objects, fields, record types, layouts |
Your customizations | Custom fields, custom objects, validation rules and layouts added on top of the package | Custom fields and flows you add to the native model |
Custom code | Every Apex class, trigger and Flow your team wrote, with the real code body. Salesforce keeps the package's own source private, so what you see is your code, which is the code you have to rewrite | Every Apex class, trigger and Flow, with the real code body |
Pricing and rules logic | Lives as records inside the package. Swantide writes the SOQL to export it | Lives as metadata: pricing procedures, decision tables, pricing recipes. Fully readable |
Catalog content | Products, options and price points are records. Export them by query | Products, categories and attribute values are records. Export them by query |
The short version: Swantide covers the customization-and-code half of discovery, which is otherwise a manual Apex and Flow audit, and it authors the SOQL for the data half. On the Revenue Cloud side it reads the whole pricing and configuration layer directly.
Two habits make everything below work better. Run one topic per conversation so context stays focused. And confirm any number that will drive an estimate with a direct query, because a list is a strong starting point rather than a certified census.
Part 1: Prompt library
Phase 1 prompts: understand the CPQ org you are leaving
Start here. One sentence, and it frames the whole project.
What custom fields have been added on top of the standard CPQ objects in this org, specifically on the Quote, Quote Line, and Product objects? List each field with the object it is on and its type.
Returns each object's fields with your own separated from the SBQQ__ managed-package ones. That split is the migration question in miniature: your fields are rebuild decisions, the package fields disappear with the package.
Inventory the customization layer that has to be rebuilt.
I am scoping a migration off Salesforce CPQ onto Revenue Cloud Advanced and need to inventory everything we have customized on top of the standard CPQ package, because that is what we have to rebuild. Discovery only.
Cover the custom fields added to the CPQ objects and to Product2 and Pricebook, any custom objects that reference CPQ, record types and page layouts on the quote and product objects, and any custom settings or custom metadata types related to quoting and pricing.
Rank by how heavily customized each object is. Table: object, custom fields, record types, notable customizations, why it matters for the rebuild.
Find the custom code that breaks at cutover. This is the one that pays for the exercise.
Same CPQ to Revenue Cloud Advanced migration, discovery only. I need every piece of custom code and automation that is coupled to CPQ, because all of it breaks when we remove the SBQQ managed package and has to be rewritten.
Find every Apex class and trigger that references an SBQQ object, CPQ pricing or quote lines; every Flow that runs on or updates the CPQ objects; and any Apex invoked from CPQ such as custom price or calculator plugins, quote generation, or document generation callouts. For each one tell me what it does, what CPQ object or behavior it depends on, and how tightly coupled it is.
Rank by coupling. Table: component, type, what it does, CPQ dependency, coupling, rewrite effort.
Separates your code from the hundreds of managed-package classes that simply cease to exist, then reads each of yours and says what it does, which fields it hard-codes, and what it becomes in Revenue Cloud.
Recreate the declarative guardrails, not just the code.
CPQ to Revenue Cloud Advanced migration, discovery only. Inventory the declarative automation and guardrails on the CPQ and quoting objects so we can recreate the same behavior in Revenue Cloud Advanced. List the validation rules, workflow rules and record-triggered automation on Quote, Quote Line, Product2, Pricebook, Subscription and Contract.
For each one: what business rule it enforces in plain English, the object and fields it acts on, and whether it is a generic rule that recreates easily or one that depends on CPQ-specific fields. Rank by importance. Table: rule, object, what it enforces, CPQ-specific, recreate effort.
Turns a wall of formulas into plain-English business rules with a recreate-effort call on each, and catches migration-era rules that should be retired rather than ported.
Get the rule and catalog data out, with the queries written for you.
CPQ to Revenue Cloud Advanced migration, discovery only. The actual CPQ configuration, meaning the price rules, product rules, discount schedules, product options, bundle structures and configuration attributes, is stored as records in the SBQQ objects rather than as metadata. Do two things:
1. Tell me exactly which SBQQ objects hold that configuration and what each one stores, so I know what I am extracting.
2. Write me the SOQL to export each of those objects, with the fields that carry the rule logic, so I can pull the actual rules out of the org.
I will run the queries and paste the results back, and you help me interpret them into a rebuild spec for the Revenue Cloud pricing engine and product configurator.
Produces a map of which object holds which piece of your configuration, price rule conditions versus actions, discount schedules versus tiers, bundle options versus constraints, followed by ready-to-run extraction queries in dependency order. Paste the results back and it turns them into a rebuild spec.
Phase 2 prompts: build and QA the Revenue Cloud org
Document the product catalog and attribute model.
I am building out and documenting a Revenue Cloud Advanced implementation and need to understand the product catalog data model. Discovery only. Document how products are modeled here: the Product2 object and its custom fields, the product catalogs and category structure, the product selling models and their options, and the attribute framework, meaning which attributes are defined, their data types, and how they attach to products.
Focus on the schema and metadata, and note where the actual catalog content lives as records rather than metadata. Table: component, type, what it captures, metadata or records, notes.
Document the pricing engine. This is the documentation that usually exists nowhere.
Revenue Cloud Advanced org, discovery only. Document the pricing logic.
1. Search this org and name the specific components that actually exist here: the pricing procedures (ExpressionSetDefinition), the decision tables, and the pricing recipes. Give me each one by its real API name and state the total for each type. Read the full stored definition of any component you cite rather than its summary. If you cannot retrieve something, say so rather than filling the gap.
2. For each, tell me what it computes, what inputs it takes, and where it fits in the pricing flow. Distinguish the standard commerce pricing procedure from any custom or eligibility ones.
Table: component, type, what it computes, inputs, position in the pricing flow.
The numbered first step matters. Asking for pricing logic without it tends to produce a generic answer about how Revenue Cloud works; asking it to search and name components first produces your org.
Then trace how a price is actually built.
Walk me through how a line item's price is built up in this org, step by step: each stage the pricing procedure runs, which decision table or calculation it invokes at each stage, and how the price moves from list price through adjustments and tiers to a final price. Write it up so someone could reproduce or QA the pricing behavior. Discovery only.
Document the configurator and bundle structure.
Revenue Cloud Advanced org, discovery only. Document how configurable and bundled products work here. Find the bundle structure, meaning parent products and their component groups, and the product configurator logic. The configurator is built on Flow, so identify the Flows that drive guided product selection and what they do: what they present, what rules they enforce, and what they write onto the quote or order.
Note which parts are metadata and which are records. Table: component, type, what it does, metadata or records, notes.
Document the quoting, order and asset model.
Revenue Cloud Advanced org, discovery only. Document the transaction and asset side of the model: how quotes and orders are structured, how transaction line items work, and how the asset and subscription lifecycle is represented. For architectural context, call out the Revenue Cloud equivalents of the CPQ Quote, Quote Line, Subscription and Contract concepts where you can see them. Table: object, role in quote to cash, key custom fields, CPQ equivalent.
Gives you the concept mapping the rest of the plan depends on: CPQ Quote Line to Quote Line Item, CPQ Subscription to Asset plus contract line item, CPQ amendments to the asset state period model, and the places where the two look similar but behave differently. Those differences are where migration plans usually go wrong.
Health-check the new configuration before go-live.
Revenue Cloud Advanced org, discovery only. Give me a health read on the pricing and product configuration. Flag decision tables or pricing procedures that nothing appears to reference, attributes defined but not attached to any product, configurator Flows that look inactive or unfinished, and any duplication or overlap in the pricing logic. Then tell me: if I changed a given decision table, what pricing procedures and Flows would be affected? Rank findings by risk.
The fastest audit of a Revenue Cloud build we have seen it do. In one org it found an inactive pricing recipe still sharing decision tables with the active one, so any edit made to fix one path would silently change the other the moment that recipe was switched back on.
Phase 3 prompts: connect the two
Map the old model onto the new one. Run this in the Revenue Cloud org with your CPQ inventory to hand. The numbered first step is what makes it map onto your real components instead of generic Revenue Cloud concepts.
I am migrating from Salesforce CPQ onto Revenue Cloud Advanced and you are connected to my Revenue Cloud target org. Discovery only, don't change anything.
Work through this in order, and do step 1 before you look at the CPQ schema at all.
1. Search this org and name the specific Revenue Cloud components that actually exist here: the pricing procedures (ExpressionSetDefinition), the decision tables, the pricing recipes, the product configurator Flows, and the bundle and component structure objects. Give me each one by its real API name. Read the full stored definition of any component you cite rather than its summary. If you cannot retrieve something, say so rather than filling the gap.
2. Then, and only then, map my CPQ configuration below onto the specific components you just named, not onto generic Revenue Cloud concepts. For each significant CPQ object and field tell me the Revenue Cloud equivalent, whether it maps directly, maps with a transform, has no home yet, or is CPQ-specific and should be dropped.
3. Flag the dangerous cases: concepts that look similar but behave differently, and anything in my CPQ config that has no counterpart among the components you found in step 1.
Table for steps 2 and 3: CPQ object or field, Revenue Cloud equivalent (real API name from step 1), map / transform / create-new / drop, risk, notes.
Here is the CPQ source schema:
[paste your Phase 1 inventory here]
Size and sequence the data load.
For the CPQ to Revenue Cloud data migration I need to size and sequence the load. Write me the SOQL to get record counts for the CPQ configuration and transaction objects (price rules, product rules, discount schedules, product options, quotes, quote lines, subscriptions, contracts) plus Product2 and PricebookEntry. I will run it and paste the counts back. Then turn it into a load plan: what is big enough to need Bulk API, and the order to load given the Revenue Cloud object dependencies you documented. Discovery only.
Work out the match keys before you load anything twice.
When we load CPQ data into this Revenue Cloud org, products and accounts have to match up, not double. Based on the two schemas, tell me the natural match and dedup keys per object, for example ProductCode on Product2, and where there is no external ID, recommend what to add. Then write me the SOQL to check how unique and how populated those keys are so I can confirm they will work. I will run it and bring back the numbers. Discovery only.
Produce the blueprint. Run this as its own conversation with your earlier outputs pasted in, rather than as the tail of a long thread.
Consolidate the following into a CPQ to Revenue Cloud Advanced migration blueprint: the CPQ customization inventory and custom code, the object and field mapping, and the data-load sequencing and match keys.
1. A rebuild backlog: every significant item with a rewrite, recreate, re-map or drop recommendation and a rough effort.
2. Sequenced into phases in dependency order: catalog and attribute model and pricing logic first, then configurator and quoting, then port the custom code, then the data load, then cutover.
3. Called-out risks: CPQ-coupled Apex that breaks, record-resident CPQ rules with no clean equivalent, data that is hard to dedup, and the licensing step.
4. A one-paragraph executive summary of scope and effort, suitable for a stakeholder.
Anchor every Revenue Cloud recommendation to a real component name from the inventory. If something in my CPQ org has no counterpart, say so plainly rather than inventing a feature for it.
[paste your prior outputs here]
Part 2: The migration plan
The blueprint prompt above produces this shape. What matters is the dependency order rather than a calendar: several of these phases overlap in practice, and how long each one takes depends entirely on how much configuration your CPQ org has accumulated. Size them from your own inventory.
Phase 0: Revenue Cloud foundation. Nothing depends on CPQ here, and everything else depends on this. Selling models, pricebooks, product catalogs and categories, product classification. Build these before anything references them.
Phase 1: product catalog core. Products with their custom fields, attribute categories and product attributes derived from your CPQ product features and configuration attributes, pricebook entries, and component groups for bundles. This is also where the decision-table rows the pricing procedure needs get populated, without which pricing cannot execute.
Phase 2: pricing rules and adjustments. The longest phase and the one most likely to surprise you, because CPQ price rules do not map one-to-one onto anything. Each rule has to be re-expressed as a pricing procedure step, a decision table, or an adjustment schedule, and some will have no clean equivalent. Exit criterion worth holding to: for a given product, quantity, account and discount, Revenue Cloud produces the same net price CPQ did.
Phase 3: bundle and configuration layer. Component groups, component relationships, and the guided selling experience. Your CPQ option constraints and product rules land here.
Phase 4: contracts and subscriptions. The asset lifecycle. This is the phase where the model differs most from CPQ: Revenue Cloud tracks mid-term change through asset state periods rather than co-term amendments, and renewals flow from asset actions rather than a renewal quote object. Design it on its own terms rather than porting CPQ's shape.
Phase 5: custom code port. Rewrite the classes and triggers identified in Phase 1 discovery against the new objects. Usually smaller than expected: most of what looks like custom logic turns out to be package code that simply goes away.
Phase 6: transaction data load. Products, price points, then quotes, orders and assets, in dependency order, using the match keys you validated. Disable the validation rules you recreated in Phase 0 for the duration of the load and re-enable them after.
Phase 7: cutover. Parallel run, reconciliation, and the licensing step. Revenue Cloud is a separate and more expensive license than CPQ, so confirm commercial terms early rather than at the end.
Three risks worth naming at kickoff
Your CPQ rules live as data, not configuration. Price rules, product rules and discount schedules are records inside the managed package. They are exportable, which is what the Phase 1 extraction queries are for, but they are not something anyone can read off a metadata inventory. Budget time for interpreting them.
Some concepts have no equivalent. Revenue Cloud's asset state period model has no CPQ counterpart, and several CPQ constructs have no Revenue Cloud one. Identify those early: they are design decisions, not conversions.
Tax and adjustment detail moves from fields to child objects. Anything integrating with quote or order line items will need reworking, not just remapping.
Where to check your numbers
Any figure that will drive an estimate is worth confirming with a direct query before it reaches a plan. SELECT COUNT() FROM SBQQ__PriceRule__c and its siblings take seconds, and the Phase 3 sizing prompt writes them for you.