Migrating to Salesforce CPQ requires importing Orders and mapping them to many Salesforce objects (aka “Tables”) in a particular sequence. Fortunately, much of the heavy lifting can be managed using a data pipeline approach.
There are many objects in the Salesforce CPQ data model, but only 16 objects are essential for a basic data migration. Of the 16 objects, 8 are automatically provisioned by CPQ triggers.
The migration process is executed in sequential stages. Each stage must be executed and completed in it's entirety before executing the next stage. Some stages are executed by an external ETL process (Extract, Transform, Load). Other stages are executed directly in Salesforce utilizing Batch or Queueueble Apex.
During the course of configuring the data migration pipeline, adjustments may only need to be applied to a single stage, thus avoiding a complete re-import of all successive stages.
Each stage is idempotent, meaning the process can be executed multiple times without changing the result beyond the initial application. Each stage is guaranteed not to create duplicate records when re-run. This is accomplished by leveraging Salesforce's UPSERT capabilities with unique external ID fields on each object.
Concurrent processing is utilized whenever possible to reduce overall stage execution time. Some stages must be executed serially to avoid potential record locking issues.
Details for each stage are provided in the section below “Data Pipeline Stages”.
A “successful” CPQ migration is defined as both existing and new systems reconciling and having 0 discrepancies. If a customer is being billed $1,000 USD dollars per month today, they should continue to be invoiced $1,000 USD per month post-migration.
Discrepancy reporting typically first occurs after stage 12 in the data pipeline, when the CPQ pricing engine has an opportunity summarize all the line items to each Order. The TCV (Total Contract Value) from the originating system is compared to the TCV calculated by the CPQ pricing engine.
Common sources of discrepancies:
- Omission of one-time charges, discounts, taxes, or shipping charges during migration.
- Rounding errors. Decimal point resolution.
Whenever possible, discrepancies are resolved “upstream” by modifying previous stages that ultimately feed the “downstream” CPQ pricing calculation engine. Migrated orders should never be reconciled manually, as that would break the idempotent integrity of the overall process. Future executions of the migration process would overwrite any manual changes.
Discrepancy reporting is also commonly done in stage 17. Prior to sending invoices to customers, sample runs are compared to existing invoices to ensure they are consistent.
The Cubic Compass solution provides a means for automatically exporting discrepancy reports to CSV format for use in Excel reconciliation.
Cubic Compass has successfully implemented and evolved this migration framework since Dec 2015.
Two example case studies:
Customer A: $30M ARR Financial SaaS company.
Customer B: $100M ARR Internet Security company.
Both customers are primarily subscription-based companies with monthly and annual recurring revenue business models.
Customer A Case Study
- Customer A migrated from standard Salesforce Opportunities and Quotes to Steelbrick CPQ (now Salesforce CPQ).
- The Salesforce org contained over 10 years of customizations.
- There were several custom triggers and non-deterministic dependencies.
- Over 5M Lead records. Several not matched to existing Accounts.
- Limited visibility into MRR when forecasting.
- Order amendments required creating new Orders.
- Hyper growth. Doubling in size every 18 months.
- CFO needed to implement pre-IPO controls for revenue forecasting and recognition
- Provision new production and sandbox orgs.
- Establish Salesforce Lightning as the default user experience.
- Migrate legacy Opportunities to Salesforce CPQ Quotes.
- Use of CPQ Co-Termed Contracts for Upsell Orders
- Implement a MRR-driven subscription sales model
- Implement Account based sales process utilizing data.com clean
- SOX compliance controls. Accurate MRR reporting.
- Total project time: 6-9 months
Customer B Case Study
- Zuora customer. Needed to migrate from Zuora Subscriptions to Salesforce CPQ.
- Telco usage-based-billing (UBB) not aligned with SaaS hosting model.
- Complex pricing for multiple partner channels.
- Implement a Zuora connector.
- Migrate Zuora Subscriptions to Salesforce CPQ Quotes and Orders.
- Establish a legacy pricebook based on active subscriptions.
- Implement CPQ pricebooks and bundles for partners.
Data Pipeline Stages
- Salesforce data source
- Zuora 360, Zuora
- Any JDBC data source
- Any data source with a SOAP or REST API
Stage 2: Target Salesforce Org
The migration is initially configured using a Salesforce Sandbox. Then 1-2 weeks prior to launch, the migration scripts are “replayed” to execute the same stages in a Salesforce production org.
Stage 3: Account Migration
Accounts are required for billing and are imported using the bulk API. It's common to conduct data cleansing processes in source system prior to migration. Recommend use of data.com and Salesforce Clean utilities.
Hierarchical Account migration is supported. For Salesforce-to-Salesforce migrations, the bulk migration stage automatically resolves parent Account IDs to their new record IDs.
Stage 4: Contact Migration
Billing contacts are required for invoicing. For Salesforce-to-Salesforce migrations, the bulk migration stage automatically resolves parent Account IDs to their new record IDs.
Stage 5: Pricebooks
This stage automatically creates a pricebook named “Legacy”.
Stage 6: Products
Instances of products on existing line items are imported as Salesforce Products. For migration projects that are implementing new product catalogs, this stage can optionally be extended to transform and map legacy products to new products.
Stage 7: Pricebook Entries
Migrate Products are automatically associated with Legacy and Standard pricebooks at this stage. If multi-currency is enabled, a pricebook entry is created per currency.
Stage 8: Opportunities
Active subscriptions and orders are imported to Salesforce as Closed-Won Opportunities. “In flight” open Opportunities may also be migrated.
Stage 9-10: “As Is” Quotes
These stages migrate existing subscriptions and order as Salesforce CPQ Quotes. To provision Contracts and Orders in Salesforce requires a historical reference to their corresponding Quote. These Quotes are the cornerstone for provisioning downstream CPQ objects in Salesforce.
Stage 11: “To Be” Quote
Optional transformation stage for organizations that are converting past and active orders to a new pricebook and product catalog. This is a custom batch Apex stage.
Stage 12: CPQ Pricing Engine Stage
The CPQ pricing engine summarizes all line items to produce a total amount on the Quote. Migration simply provides the raw Quantity, List Price, Term, and Discount amounts. The termed rollup is calculated by CPQ trigger processes.
Discrepancy reports and reconciliation typically starts after this stage is achieved. The Cubic Compass module for this stage has the ability to export CSV files at this stage for use in Excel.
Stage 13: Primary Quote Sync Stage
Migrated quotes are flagged as “Primary”, which synchronizes the Quote with a standard Salesforce Opportunity and Product Lines.
Stage 14: Contracts
Salesforce standard Contracts are provisioned at this stage, along with related lists of Subscription and Asset records associated with the Contract.
Contract start date, renewal date, and total amount are critical fields to evaluate post-migration.
Stage 15: Renewal Opportunities
Renewal Opportunities can optionally be provisioned at this stage, allowing for MRR/ARR custom forecasting in Salesforce.
Stage 16: Orders
Salesforce standard Orders and Line Items are 1:1 generated from CPQ Quotes at this stage.
Stage 17: Billing and Invoicing
Invoice Schedules and runs may be manually or automatically created at this stage. If credit cards will be used for processing payment, then payment gateway and payment method configuration may be required.
Stage 18: Post-Migration Tasks
Upon a successful migration, many “scaffolding” Apex classes and records may removed or inactivated. Typically a batch Apex class is maintained to conduct post-migration tasks.