You’ve spent years getting your CPQ configuration right — product rules, price rules, bundle logic, approval flows, all tuned to how your team actually sells. Now Revenue Cloud is the direction Salesforce is pushing, and the obvious question comes up in a Trailblazer Community thread almost every week: can you just turn Revenue Cloud on alongside CPQ, keep what you’ve built, and migrate at your own pace? An admin asked exactly this recently — can the two coexist, and do products, configurations, and orders carry over or does it all start from scratch. The honest answer is that there’s no “Easy Button” for a CPQ to Revenue Cloud migration, and understanding exactly what does and doesn’t survive the move is what separates a clean transition from a rebuild you didn’t budget for.
Quick Answer: CPQ and Revenue Cloud can technically coexist in the same org, but they cannot — and should not — be used on the same Opportunity at the same time. On migration, some assets carry over with light rework: Products, Price Books, and Price Book Entries are generally reusable. Configuration reuse depends on whether the logic is platform-based or CPQ-specific — CPQ-specific product rules and configuration attributes typically don’t map cleanly. Bundle structures will almost certainly need to be rebuilt from scratch on Revenue Cloud’s data model. There is no automated migration tool that moves a CPQ implementation into Revenue Cloud wholesale — every migration involves selective reuse plus real rebuild work, which is exactly why this decision benefits from an experienced partner rather than a self-serve toggle.
Can CPQ and Revenue Cloud Run in Parallel?
At the org level, yes — CPQ and Revenue Cloud’s Advanced Revenue Management can both be active in the same Salesforce org during a transition period. What they can’t do is share an Opportunity. Once an Opportunity is quoting through one system, it needs to stay in that system through to close; you can’t hand a single deal back and forth between CPQ and Revenue Cloud mid-quote. In practice, this means a transition period where new Opportunities route to Revenue Cloud while existing open pipeline finishes out on CPQ — an object-level split, not a feature toggle you flip for everyone at once.
What Actually Carries Over: Products, Price Books, Price Book Entries
The core commerce data model is the part most likely to survive the move with light rework. Products, Price Books, and Price Book Entries are standard Salesforce objects that both CPQ and Revenue Cloud build on top of, so this data generally reuses cleanly rather than needing to be recreated from scratch. This is the part of a migration that tends to go smoothly — and the part that gives teams false confidence that the rest of the move will be just as easy.
What Almost Never Carries Over Cleanly: CPQ-Specific Configuration
Configuration is where “it depends” actually means something. Platform-based configuration — logic built on standard Salesforce automation like Flow — has a real chance of transferring or being adapted with moderate effort. CPQ-specific configuration — product rules, configuration attributes, and pricing rules built inside CPQ’s own object model — generally doesn’t map onto Revenue Cloud’s architecture, because Revenue Cloud represents pricing and configuration logic differently at the data level. Teams that assume “configuration is configuration” tend to discover this gap mid-project rather than during planning, which is the expensive way to find out.
Bundle Structures Will Need to Be Rebuilt
Product bundles are the single most consistent rebuild item in a CPQ to Revenue Cloud migration. Bundle structures — the parent-child product relationships, nested options, and bundle-level pricing logic — are modeled differently enough in Revenue Cloud that reuse isn’t realistic. Budget bundle rebuild as a first-class work item in the project plan, not a detail to sort out during testing. For a fuller breakdown of the overall migration timeline and phases once you’ve scoped the rebuild work, see our post on Salesforce CPQ vs Revenue Cloud, which covers the four-phase migration path end to end.
Orders and Historical Quote Data: What Stays, What Gets Archived
Historical Orders and closed quotes generally don’t need to migrate at all — they represent completed transactions, not active configuration, and can stay in CPQ as historical reference even after new deals move to Revenue Cloud. The practical pattern most teams land on: keep CPQ in read-only mode for historical quote and order lookup, and treat Revenue Cloud as the system of record only for anything created after cutover. Trying to force historical Orders into Revenue Cloud’s data model is rarely worth the effort relative to the value of that data.
The “Can We Do This Ourselves” Decision Checklist
Four questions predict whether a CPQ to Revenue Cloud migration is realistic to self-serve versus needs outside help:
- How many active bundle structures does your CPQ implementation have? A handful of simple bundles is a manageable rebuild. Dozens of nested, conditional bundles is a project that benefits from someone who’s done this migration before.
- How much of your configuration logic is CPQ-specific versus platform-based? The more CPQ-specific product rules and configuration attributes you have, the more of your logic needs to be redesigned rather than ported.
- Do you have a clean way to run new-deal and existing-pipeline quoting in parallel without confusing your sales team? If reps can’t clearly tell which system a given Opportunity lives in, adoption breaks down fast.
- Does your team have bandwidth to rebuild and test bundle logic without pausing active deal flow? Migrations that get squeezed into “whenever we have spare time” tend to stall indefinitely.
Answering “no” to more than one of these is a strong signal this is the kind of project where a Cloud Nexus Revenue Cloud consulting practice pays for itself in avoided rework, rather than something to sort out through trial and error inside a live sales pipeline.
Quick Reference: What Migrates vs. What Gets Rebuilt
Frequently Asked Questions
Can I run CPQ and Revenue Cloud in the same Salesforce org?
Yes, at the org level both can be active during a transition period. The restriction is at the Opportunity level — a single Opportunity needs to quote through one system or the other, not both. Most teams handle this by routing new Opportunities to Revenue Cloud while letting existing open pipeline finish out on CPQ.
Is there an automated tool to migrate CPQ configuration to Revenue Cloud?
No. There is no wholesale automated migration path that moves a CPQ implementation into Revenue Cloud. Some data — Products, Price Books, Price Book Entries — is reusable with light rework, but configuration logic, product rules, and especially bundle structures typically need to be manually rebuilt on Revenue Cloud’s data model.
Do I need to migrate historical Orders and closed quotes to Revenue Cloud?
Usually not. Historical Orders and closed quotes represent completed transactions rather than active configuration, and most teams leave them in CPQ as read-only historical reference rather than porting them into Revenue Cloud. The migration effort is better spent on active bundle and configuration logic that new deals will actually depend on.
How do I know if my bundle structures will be hard to rebuild?
Complexity scales with how many nested options, conditional logic branches, and bundle-level pricing rules a bundle has. A small number of simple, flat bundles is a manageable rebuild for an in-house admin. Dozens of deeply nested, conditional bundles is the kind of scope where an experienced Revenue Cloud partner meaningfully reduces both timeline and risk of introducing pricing errors.
Scoping a CPQ to Revenue Cloud Migration?
Book a free 90-minute Salesforce Org Review with the Cloud Nexus team. We’ll assess your current CPQ configuration, flag exactly which bundles and rules will need to be rebuilt, and give you a realistic migration plan before you commit a timeline to the business.
Book Your Free Org Review →
