ChatGPT
Claude
Google AI
Copilot
Every quoting migration starts as a platform conversation and ends as a pricing conversation. The platform part is tractable. The pricing part is where twelve years of exceptions live, most of them undocumented, several of them load-bearing for a customer who is up for renewal in March.
Before scoping a move off Salesforce CPQ, get answers to these eight. Not opinions, answers, with names attached.
1. How complex is the catalogue, really?
Not the product count. The complexity.
Count instead: bundles, nested bundles, option constraints, product rules, configuration attributes, and the number of products that behave differently depending on who is buying. A 400-product catalogue that is genuinely flat is a smaller job than a 60-product catalogue with four levels of bundling and region-specific option logic.
This number, more than anything else, sets the size of the project. Get it before you get a budget.
2. Which pricing rules are policy, and which are workarounds?
Open the price rules and discount schedules and sort every one into three piles:
- Policy, a real commercial rule the business would restate today.
- Workaround: something built to compensate for a limitation, a data gap, or a process nobody fixed.
- Nobody knows, it fires, it changes a number, and no one can explain it.
The migration only has to carry pile one. Piles two and three are the actual value of the project, because a migration is the only time you get organisational permission to delete pricing logic.
3. What happens to amendments, renewals and co-terms?
This is where quoting migrations go over budget, every time.
Amendments are not a feature you turn on. They are a set of commercial decisions: what happens to price when a customer adds seats mid-term, whether the added seats co-terminate, how proration is calculated, what a downgrade does to a committed minimum, and what the renewal quote inherits from the original.
If your current implementation encodes those answers in a mix of price rules, Apex and a spreadsheet finance maintains, the migration has to make all of it explicit. Model amendments and renewals in week one with real historical examples, not with a new logo deal, which is the easy case.
4. Who owns approvals, and how many levels are real?
Pull the last twelve months of approval history and count how often each level actually rejected or changed something.
Most approval matrices have levels that have never rejected anything. They exist because someone senior asked to be included in 2021. A migration is the moment to propose collapsing them, with the data in hand, which is the only way that conversation succeeds.
5. What does finance need out the other end?
Quoting exists to produce something finance can bill and report on. Ask the CFO's team, in writing:
- Which reports do they run today and where do the numbers come from?
- What is the definition of bookings, ACV and net new versus expansion in this business?
- What breaks in their month-end close if a field is renamed?
Reporting continuity is the most common reason a technically successful quoting migration is judged a failure. Nobody notices a clean cutover. Everyone notices the revenue report that no longer ties.
6. What are you doing with historical quotes?
You almost certainly do not need to migrate them. What you need is the ability to answer questions about them.
| Need | Usual answer |
|---|---|
| Look up what a customer was quoted in 2023 | Keep the records read-only in place |
| Report on historical bookings trend | Extract to the warehouse or Data 360 |
| Amend a live contract signed under the old system | Migrate only active contracts |
| Legal or audit retention | Archive with a documented retention policy |
Only the third row is genuinely a migration scope item. Sorting this properly removes a large chunk of scope that teams often carry by default.
7. What is the integration surface?
List every system that reads or writes quoting data: ERP, billing, e-signature, provisioning, the data warehouse, partner portals, the tax engine. For each, note whether it integrates at the object level (fragile, object names are changing) or through an API contract you control (survivable).
Every object-level integration is a migration task. This inventory usually surprises people; it is common to find three integrations nobody in the room owns.
8. How will you run in parallel?
The answer "we will cut over at the end of the quarter" is not a plan, it is a date.
Run both systems for at least one complete quoting cycle, including an amendment and a renewal, not just new business. Quote the same deals in both and compare the numbers line by line. Differences you find in parallel running are findings. The same differences found after cutover are incidents, and they arrive with a customer attached.
The uncomfortable part
There is a version of this project that is genuinely just a platform move: a simple catalogue, few rules, clean data, one integration. If that is you, the migration is straightforward and you should get on with it.
For everyone else, the honest framing is that you are re-implementing your commercial model on new foundations, and the platform change is the smaller half. Scoping it as a technical migration is how twelve-week projects become nine-month ones.
Answer the eight questions first. Several of them will change what you decide to build, and one or two may change whether you should start this quarter at all.
Related reading: Salesforce CPQ and Revenue Cloud Advanced capability overviews.
