Updated October 2026. We'll update this page when the assistant ships.

Salesforce's CPQ Migration Assistant: What It Will and Won't Do for Your Migration

Salesforce has a tool on the way to help move CPQ to Revenue Cloud. Here's an architect's view of what it can realistically take off your plate, what it can't, and whether you should wait for it.

By Ayub Ansari, Salesforce Technical Architect at Tenetizer

Since the announcement, CPQ owners have started asking us the same question: "Should we just wait for the tool?" It's a fair question. A first-party migration tool is real news. Until now, Salesforce has pointed customers to partner-built accelerators instead.

But "a tool that moves configuration" and "a finished migration" are very different things. Here's how to think about it.

What we know so far

• It's on the roadmap, targeted for December 2026. It was presented in the Revenue keynote at Dreamforce 2026. Roadmap dates can move, and scope can change before release.
• It's aimed at the CPQ managed package, the SBQQ-based product most companies mean when they say "Salesforce CPQ."
• It's described as covering configuration, not only data. That's the interesting part, since configuration (products, bundles, pricing, rules) is where most of the effort sits.
• Details aren't public yet. Eligibility, exactly which objects and rule types it handles, and how it deals with customisations are all still unknown.

Treat anything more specific than that, including from us, as a prediction until Salesforce publishes documentation.

What a migration tool can realistically help with

Based on how CPQ and Revenue Cloud are built, here's where a tool is likely to help and where it hits a wall. This is our architect's view of the work, not a description of the tool's features.

The pattern is simple. A tool is good at translating things that have a clear equivalent. It can't make decisions. And most of the risk in a CPQ migration lives in the decisions: what to keep, what to simplify, and how to rebuild logic that works differently in Revenue Cloud. Our object and feature mapping shows where those differences are.

The trap: migrating a mess faster

Here's the risk we see coming. A tool that copies configuration makes it very easy to carry everything across: every old price rule, every bundle nobody sells anymore, every workaround from 2019. You'd end up with a Revenue Cloud org that looks a lot like your CPQ org, problems included, on a more expensive license.

That's not a problem with the tool. It's how any migration tool works: what goes in is what comes out. The teams that get the most out of it will be the ones who clean up first and decide what they actually want in Revenue Cloud, then use the tool to move that.

Should you wait for it?

It depends on where you are:

Wait to migrate, but don't wait to prepare

If you've decided on Revenue Cloud and your renewal isn't close, it's reasonable to time the actual migration after the assistant ships and you've seen what it does. Use the months in between to clean up your catalog and rules, document your pricing, and list your code and integrations. All of that makes the tool's output better.

Don't wait if your renewal is soon

If your Salesforce renewal is in the next six months, you need to know your scope, seat count and edition before that conversation, not after a tool ships. Get the assessment done now. You can still use the assistant later for the build.

Don't wait if you're already mid-project

If you've started migrating, keep going. Pausing for a roadmap item usually costs more than it saves. You can evaluate the tool for any remaining phases once it's available.

Not sure? Use the checklist

Our CPQ migration readiness checklist takes two minutes and tells you whether your timing pressure and complexity point to starting now or preparing first.

Questions to ask when it ships

When Salesforce releases the assistant, these are the questions we'll be asking, and you should too:

• Which objects and rule types does it cover? Price rules, product rules, discount schedules, QCP, approvals, templates?
• What does it do with things it can't map? Skip them, flag them, or create a rough version you then have to fix?
• How does it handle custom fields and twin fields?
• Does it migrate active subscriptions and contracts, or only configuration?
• Can it run more than once? For example, into a sandbox first, then again for the final cutover.
• Who is it available to, and is there a cost?
• What does it produce as a report? A clear list of what moved, what didn't and why is almost as valuable as the migration itself.

How we'll use it

For us, a first-party tool is good news. We'll treat it the way we treat any accelerator: run it on a cleaned-up scope in a sandbox, review everything it produces, and rebuild the parts that need real design. If it cuts the mechanical work, our clients get a faster, cheaper migration, and we'll reflect that in our fixed-price phases.

What it won't change is the need for someone who understands both products to decide how your pricing, bundles and renewals should work in Revenue Cloud. That's still the part that makes or breaks the project.

Common questions