Phase 1: Understand Your Current State

Secure Executive Sponsorship

Without visible executive sponsorship, projects tend to stall when significant decisions or trade-offs arise. Before committing to a strategy, identify a named executive sponsor who understands the scope of change, has approved resource commitment, and can engage stakeholders across sales, finance, legal, and IT.

Form the Core Team

Assign a small cross-functional team who can dedicate consistent time to the project. Avoid splitting attention across other priorities during active project phases. A typical core team includes:

• Salesforce admin: Manages configuration, sandbox orgs, and technical execution.
• Product or catalog owner: Understands the commercial product structure and has decision-making authority over catalog changes.
• Revenue operations lead or business analyst: Translates business requirements into Salesforce design decisions.
• IT or integration architect: Owns the integration landscape and custom code inventory.
• Executive sponsor: Provides visibility, removes blockers, and keeps the project aligned to business priorities.

The core team must understand the entire product-to-cash lifecycle and all the underlying technology.

Assess Your Salesforce CPQ Org

Before defining the migration scope or approach, assess your current Salesforce CPQ org. Use available migration tools, including tools from early adopters such as Forsys, IdeaHelix, or Prodly, to evaluate your Salesforce org's complexity across the dimensions most relevant to migration planning. The assessment must answer these questions.

• How many products, bundles, product rules, and attributes exist in the catalog, how many are actively used, and is the catalog rationalized?
• What pricing rules, quote calculator Apex plug-in scripts are in place, and what business logic do they contain?
• How many active subscriptions and assets exist, how many are ready for processing, and what is their data structure?
• What custom code and page layouts are in use?
• Which integrations reference CPQ objects, and what data flows through them?

Document CPQ Implementation Pain Points

Before beginning the migration, document limitations and workarounds in your current CPQ implementation. This information defines the success criteria of the project. Capture these points.

• Performance or scalability issues: Quote calculation times, page load delays, and approval bottlenecks.
• Functionality gaps: Business requirements that CPQ can’t meet, or can only meet with significant custom development.
• CPQ workarounds: Manual steps, offline spreadsheets, or shadow systems that compensate for CPQ limitations.
• Integration friction: Data that doesn't flow cleanly between CPQ and downstream systems.
• Process improvements: Processes that need to be updated or optimized before migration. Complex processes migrated as-is will remain equally complex in the new system. Use this opportunity to streamline them.

These pain points become the success criteria for the migration. Determine your success criteria before proceeding to phase 2.

Begin Data Quality Remediation

Data quality issues are more costly to resolve during migration than before it. Start remediation early, regardless of the migration strategy that you select. Focus on these areas first.

• Duplicate or retired products that are still marked as active in the catalog.
• Inconsistent attribute naming across product lines or business units.
• Review CPQ cost book data for potential duplicates. To preserve historical cost records, create a custom field for the effective end date and populate this date before migration.
• Orphaned records, such as subscriptions without parent accounts or quote lines without parent quotes.
• Create a set of subscription records that need to be migrated together. You don’t need to migrate cancelled subscriptions.
• Incomplete or inconsistent asset records that may affect the Customer Asset Lifecycle Management (CALM) migration.
• The ProductSellingModelId field on Pricebook Entry records is read-only after Pricebook Entry records are initially created. If you migrate to Revenue Management without specifying a product selling model at creation time, it will result in Pricebook Entry records that can’t be corrected post-migration without creating records. So, make sure that the product selling models are mapped correctly before migration. Contact Salesforce Customer Support if you need edit access to change the product selling model on Pricebook Entry records.
• While CPQ uses record types to identify CPQ-related records, Revenue Management uses App Usage Assignment records to identify records generated by Revenue Management. The App Usage Assignment record must be populated for all transactional records, such as quotes, orders, and assets, for asset lifecycle operations to succeed.
• In Salesforce CPQ, attributes can be directly assigned to products. In Revenue Management, attributes to be inherited through a product class. Since CPQ users won't have product classes, they need to be systematically created during migration by grouping products with identical attribute sets.
• In Salesforce CPQ, you can create multiple cost entries for each product and each currency including zero-unit cost entries. In Revenue Management, you can’t create duplicate Cost Book Entry records or the same currency ISO code. This difference causes migration errors.

Phase 1 Checklist

Before moving to Phase 2, confirm that you’ve completed these tasks.

• Executive sponsorship is in place and resource commitment is approved.
• A core team is in place with defined roles and sufficient capacity.
• A Salesforce CPQ org assessment is complete and the team understands the complexity profile.
• Pain points with the current CPQ implementation are documented and the team has a shared definition of success.
• Significant data quality issues are identified and remediation has started.
• Your Salesforce account executive is engaged, and licensing and support options are understood.

After you’ve completed all the items in phase 1, proceed to phase 2.