Eight questions to answer before you move off Salesforce CPQ

The migration usually enters the room already named. Somebody says we need to move off CPQ, and the conversation starts at how rather than at why, because the why feels settled: quoting is painful. It is. That is not a finding.

Painful quoting is compatible with a catalogue nobody maintains, an approval matrix that routes to people on leave, a pricing policy that was never written down, and a product that genuinely cannot express what you sell. Only the last of those is fixed by changing product. The others arrive on the new platform intact, with a fresh implementation partner and a larger invoice.

What follows are the questions that separate those explanations. Each has a good answer and a bad answer, and the difference between them is rarely the amount of detail offered. It is whether the answer names something specific: a person, a count, a document, a date. Bad answers at this stage are general, and generality is what turns into scope later.

None of this covers how to run the migration. If the decision is genuinely settled, sequencing is a separate discipline and is set out in the migration itself. This is the part before that.

#First, check what is driving the urgency

Quite often the reason this is being discussed now rather than next year is a date somebody read in a blog post. Handle that before anything else, because urgency shapes every other answer in the room.

Salesforce continues to publish material on both Salesforce CPQ and its revenue lifecycle platform, and its own CPQ page does not state an end of sale. A good deal of third-party writing asserts one anyway, confidently and without a source. We are not going to repeat it. If the case for moving rests on a retirement date, get the status of the product you actually hold confirmed in writing by Salesforce or your account team before it reaches a business case.

Urgency that survives that check is real and worth acting on. Urgency that does not survive it was never the reason, which means the actual reason is still unexamined.

#The eight, and what a bad answer signals

#1. What problem is this meant to solve, and is it a product problem at all?

The question is not what is wrong with Salesforce CPQ. It is what specifically goes wrong, to whom, how often, and at which step.

A good answer sounds like quoting a mid-term change takes over a week because nobody can tell a rep what the customer is currently contracted to, it happened on most amendments last quarter, and here is the count. That is specific enough to test a product against, and specific enough that you would notice if the new product did not fix it.

A bad answer sounds like the system is old, sales are frustrated, and the platform is where the vendor is investing. Every clause may be true. None describes a problem, so none can be checked later, and a programme with no checkable claim cannot be judged to have succeeded.

Then ask the uncomfortable half: is it a product problem at all. Unowned pricing policy, an unmaintained catalogue and a process nobody agreed all present as quoting pain, and all three follow you across.

#2. Who owns pricing, and is that settled?

A quoting system is an expression of pricing policy. Where nobody owns the policy, the system becomes the policy by default, and the migration turns into a negotiation between everyone who has ever held an opinion about a discount, conducted against a delivery date.

The question is not who approves discounts. It is who can change a pricing rule and have it stay changed without a committee.

A good answer sounds like a named person in commercial or finance who has refused something in the last six months, and whose sign-off the current discount structure rests on.

A bad answer sounds like pricing is a shared responsibility across sales, finance and product. That means nobody, and it means each of the several hundred decisions the migration surfaces gets escalated to a forum that meets fortnightly.

There is a version that looks settled and is not: pricing owned by the person who built the current rules and is the only one who understands them. That is ownership of an implementation rather than of a policy, and the migration removes it.

#3. How much of the current configuration is genuinely used?

Scope is usually estimated from the size of the existing system. That is the wrong denominator, because a large part of any mature configuration is dormant.

Three counts are worth having before an estimate exists: which products have been quoted in the last two years, which price and product rules have actually fired, and which approval levels have ever rejected or materially changed a deal. All three come out of data you already hold, and all three usually return smaller than the room expects.

The rules count matters most. Sort every rule into three piles. Policy, a commercial rule the business would restate today. Workaround, something built to compensate for a limitation, a data gap or a process nobody fixed. Unexplained, it fires, it changes a number, and no one can say why. Only the first pile is a requirement. The other two are most of the value of doing this at all, because a migration is the only moment an organisation grants itself permission to delete pricing logic.

A good answer sounds like three counts with a date range attached, produced from the org rather than from memory, and somebody prepared to defend which rules sit in which pile.

A bad answer sounds like it is all still in use. That is almost never true, and believing it converts a scoping exercise into a like-for-like rebuild of everything anyone ever asked for.

#4. Can you state your amendment and renewal policy today?

Amendments are not a feature you switch on. They are a set of commercial answers: what happens to price when a customer adds quantity mid-term, whether the addition co-terminates, how proration is calculated, what a downgrade does to a committed minimum, and what a renewal inherits from the original deal. Salesforce treats this as a body of work in its own right, which the asset lifecycle material gives some sense of.

Ask for those five answers in a room containing sales, finance and whoever maintains the current rules. If the three groups give three answers, you have found the real scope of the project, and it is not a platform scope.

A good answer sounds like a written policy, or one person who can give all five from memory and be contradicted by nobody present.

A bad answer sounds like the system handles it. That describes where the answer currently lives rather than what it is, and somebody will have to state it in plain English before anyone can configure anything.

This question has a short second half. Whenever the old system is eventually frozen, there will be quotes half approved, amendments part processed and contracts mid-change. The handling does not need deciding now. What needs establishing now is who is entitled to decide it, and whether that person can be got into a room, because a programme that cannot answer that at decision stage does not acquire the ability later.

#5. What does the quote-to-cash process do outside Salesforce?

Draw the whole chain rather than the part inside the org: where the price comes from, where an accepted quote goes, what raises the invoice, what recognises the revenue, and what each step in between actually runs on. Include the spreadsheets. Especially the spreadsheets.

Two things usually fall out. The first is an integration inventory, normally longer than the room believed, with two or three entries nobody owns. The second is more useful: the discovery that part of the difficulty being blamed on the quoting platform happens after the quote, in a hand-off that will be exactly as manual afterwards unless scope deliberately includes it.

A good answer sounds like a diagram somebody drew this month, with system names, the direction of each hand-off, and a person against each one.

A bad answer sounds like it all goes into the ERP. That sentence conceals the mechanism, and the mechanism is the thing the migration has to reproduce.

Where the difficulty genuinely sits after the quote rather than inside it, the decision in front of you is about scope rather than product, which is a different comparison: Revenue Cloud and CPQ across the whole lifecycle.

#6. What does finance need out the other end, and what happens to the history?

Quoting exists to produce something the business can bill and report on, and reporting continuity is the most common reason a technically clean quoting migration is judged a failure. Nobody notices a smooth cutover. Everybody notices a revenue report that no longer ties.

Ask the financial controller in writing: which reports they run and where the numbers come from, what bookings and expansion mean in this business, and what breaks at month end if a field is renamed.

Then separate history, which is a different question wearing the same clothes. What is wanted from old quotes is the ability to answer questions about them, and each kind of question has a different home.

Only the third row is migration scope. Sorting this at decision stage rather than during delivery removes a large block of assumed cost from the estimate, and it is usually the block making the business case look unaffordable.

A good answer sounds like a named finance stakeholder, a list of reports, and a decision already taken about how long the old records stay reachable and who pays for that.

A bad answer sounds like we will migrate everything. That is not a requirement. It is the absence of one.

#7. Will the data survive the move?

The previous question was about what you want to keep. This one is about whether what you keep will still mean anything.

Quote and contract records depend on what they point at: a product, a price book entry, a discount structure, a bundle, a term. Where the destination expresses those differently, a record can migrate perfectly and still be wrong, because the thing that gave it meaning did not come with it.

The test worth running before committing is small. Take a handful of your most awkward live contracts, the amended and co-termed ones rather than the clean ones, and ask whoever is proposing the migration to describe how each would be represented afterwards. Not to build it. To describe it.

A good answer sounds like a specific account of each, including the parts that do not map, and an explicit statement of what is lost.

A bad answer sounds like the tooling handles it. Tooling moves rows. Whether a row still means what it meant is a modelling question, and people answer that.

Ordinary data quality belongs here too. If account, contract or product data is known to be unreliable today, the migration inherits it and gives it a new name.

#8. What is the licence position, actually?

This is a question of fact and it is routinely answered from memory. What do you hold, on what term, with what anniversary, co-termed with what, and what happens commercially if two arrangements run alongside each other for a period.

A good answer sounds like somebody has read the order form and can state the dates.

A bad answer sounds like we will sort the licences out with the account team later. Later is after the leverage has gone, and leverage here is highest before you have committed publicly to moving.

#What doing nothing actually looks like

All eight answers are measured against an alternative, and the alternative is usually left unstated, which flatters the migration.

State it. Doing nothing means keeping what you have, and that carries a real and compounding cost. Exceptions accumulate. The person who understands the rules eventually leaves. The catalogue freezes because nobody can predict what a change breaks, and the workarounds migrate into manual quoting where nobody can see them at all. That is a serious argument for moving, and a stronger one than the urgency arguments people usually reach for first.

But there is a version of doing nothing that is simply better. If questions two, three and four came back as unowned pricing, dormant configuration and undocumented amendment policy, then those are the problem, they are cheaper to fix where you stand, and they have to be fixed either way. An organisation that does that work first reaches the platform decision with a smaller catalogue, a written pricing policy and a named owner, which is a materially cheaper migration than the one being scoped today.

A good answer sounds like a stated cost of staying and a stated first-year cost of moving, produced by different people.

A bad answer sounds like we cannot stay on this forever. Probably true. Not a reason to move this quarter.

#What to do with the answers

Read the eight as a set, because the pattern across them says more than any single answer. Specific answers throughout mean the problem is understood and the migration can be scoped against something. General answers throughout mean the decision rests on a shared feeling that the present system is difficult, which is true almost everywhere and predicts nothing.

If the answers are good, the next discipline is sequencing, and that is the migration itself. If they are not, the useful outcome is not a delayed migration. It is a shorter list of things that were about to be blamed on the platform and turn out to belong to you either way.

Related reading: our Salesforce CPQ and Revenue Cloud capability overviews.