You are here:
Determine Your Deployment Model and Org Strategy
Where you deploy Revenue Management is part of the broader Salesforce platform strategy of your company, not just a migration decision. Many companies run multiple Salesforce clouds, including Sales Cloud, Service Cloud, Experience Cloud, and Field Service. Determine the Salesforce org in which you want Revenue Management to deploy within that wider context rather than in isolation. If your company has a defined Salesforce org strategy, such as a plan to consolidate clouds into a single org or a deliberate multi-org model by region or business unit, align the Revenue Management deployment decision to that strategy. Involve your Salesforce account executive and platform architect early in this conversation, as the decision has implications beyond the migration from CPQ to Revenue Management.
Deploying Revenue Management in a New Salesforce Org
Some companies use the migration from CPQ to Revenue Management as an opportunity to establish a new Salesforce org, whether as part of a broader org consolidation plan, a regional or legal entity separation, or to start with a clean architecture. If you are considering this approach, make the decision as part of your overall Salesforce org strategy rather than as a migration-specific choice. Deploying Revenue Management in a different org affects every Salesforce cloud your business runs. Integrations, user management, data sharing, reporting, and licensing all need to be evaluated together.
If your Salesforce strategy requires Revenue Management to live in a new org or an existing org that already hosts other Salesforce clouds, keep these considerations in mind.
- Redesign your product catalog and pricing in Revenue Management. If you prefer to retain your existing CPQ data, migrate this data, including the product catalog, pricing, assets, and subscriptions, from the source CPQ org to the target org. See Migrate Product Data and Migrate Asset Data.
- Integrations, users, profiles, and org-level configuration must either be rebuilt in the target org or migrated from the source to the target org.
- Standard objects such as Account, Contact, and Product2 should be present in the target org. Decide whether to migrate these from the CPQ org, source them from another Salesforce org, or set them up afresh.
- If the target org already hosts other Salesforce clouds such as Sales Cloud or Service Cloud, assess how Revenue Management data and processes will interact with those existing deployments, particularly shared objects, reporting, and user experience.
Engage your Salesforce account executive before committing to this approach. They can help assess whether a separate org aligns with Salesforce's recommended architecture for your cloud portfolio and connect you with the right platform and solution architects to support the design.
Deploying Revenue Management in an Existing Salesforce Org
For most companies, deploying Revenue Management in an existing Salesforce org is the most straightforward approach. CPQ and Revenue Management coexist in the same Salesforce org during the transition, and shared standard objects such as Product2, PricebookEntry, and Account are immediately available to both systems without migration.
- Integrations, users, profiles, and permission sets are already in place and do not need to be rebuilt.
- Shared standard objects require a clear governance model during the coexistence period. For more details, see the Plan for Operating Across Two Systems section of this topic.
- This approach works best for companies where the existing org is well-governed, integrations are stable, and the broader Salesforce platform strategy does not require restructuring of the org.
We don’t recommend deploying Revenue Management in an existing org that carries technical debt because it impacts performance, usability, and other aspects.
Sandbox Approach by Deployment Model
Follow the relevant sandbox approach based on your deployment model.
- Same org: Enable Revenue Management permission set licenses within a full-copy sandbox of the existing org. This approach supports coexistence testing with real data and confirms how shared objects behave with both the systems active.
- Different org: Create a sandbox of the target org for configuration and User Acceptance Testing (UAT). Use a sandbox of the source CPQ org as the data source for migration testing. Run migrations from the CPQ sandbox into the Revenue Management sandbox to validate the end-to-end process before any production activity.
