Salesforce CPQ data migrations — everything you need to know

Salesforce CPQ data migrations — everything you need to know

David Runciman on

Share with

LinkedIn
Twitter

Implementing Salesforce CPQ streamlines the sales process. But implementing CPQ and migrating configuration data between environments is tricky without the right tools. In this guide, we’ll take a look at the benefits, challenges, and solutions you should be aware of, whether you’re migrating to Salesforce CPQ from a legacy system or building out a new solution in Salesforce.

The benefits of moving to Salesforce CPQ

Producing quotes can be a complicated business process because it’s affected by any number of variables such as product bundles and discounts. CPQ takes that complexity away from the sales team, with calculations handled automatically behind the scenes. Accurate quotes are generated quickly, saving precious time and shortening the sales cycle. So it’s well worth making the jump to Salesforce CPQ, with all due care and planning.

If you’re replacing a legacy system, you’ll want to migrate your existing data into Salesforce CPQ rather than starting from scratch. But that first step of migrating data will still take careful planning and time.

Gearset DevOps Summit: Developing a long-term Salesforce DevOps mindset

Find out more

CPQ migration challenges

There are two main challenges to watch out for during a CPQ data migration process:

  1. The CPQ data model is complicated. The complexity of quotes doesn’t magically disappear. It’s handled instead by the CPQ model — but that needs to be built to your exact requirements. Developers working on a new CPQ implementation will need to grasp the CPQ model and all its dependencies. Building a new solution or replacing a legacy one will take time.
  2. CPQ uses configuration data. Unlike most other parts of Salesforce which are represented with metadata, Salesforce CPQ involves configuration data. The CPQ data model itself determines how your CPQ solution works. This really matters when it comes to deploying CPQ between environments, because CPQ can’t be deployed using tools that only support Salesforce metadata.

Salesforce data migration tools for CPQ

Several tools are available that you could use to migrate CPQ data. Broadly they fall into two main categories:

  • ETL tools. Since these tools enable you to extract, transform and load data, they can often be used to take CSV files with data extracted from other platforms and load them into Salesforce. If you’re migrating from other data sources to Salesforce CPQ, a tool like Data Loader or similar will come in handy. But ETL tools don’t do anything to help you puzzle out the CPQ model, are typically slow to run, and it’s easy to make mistakes that are costly to fix.
  • Tools built on API integrations. Third-party solutions, like Gearset, use Salesforce’s APIs to help you migrate CPQ changes between environments. They’re not built to load data from CSV files, but they will help you include CPQ in a best-practice release process, often using smart functionality to make CPQ deployments much easier.

How to migrate Salesforce CPQ data

If you’re building a new CPQ solution in Salesforce and just looking to migrate changes between orgs, you can skip straight to step three below. If you’re migrating from external systems into Salesforce, there are a couple of stages to navigate first.

1. Prepare your data

Before moving over data from any legacy system to Salesforce, the first step is to clean your data and ensure data quality. It’s an obvious point, but still worth emphasizing because it’s all too easy to invest time into a migration before noticing incorrect, wrongly formatted or duplicate records are causing problems.

2. Map out the migration process

It’s essential to plan out any migration from a legacy system to Salesforce CPQ. Your CPQ implementation will be unique, so there isn’t one process that everyone can follow.

You might come across different recommendations for the CPQ migration sequence, but the truth is that you’ll need to work out:

  • What your CPQ implementation needs to accomplish
  • Which parts of CPQ are needed to deliver those objectives
  • How those CPQ objects relate to each other

It’s well worth data mapping your implementation, laying out where records are in an existing database, and where those records need to be added in Salesforce CPQ. Then you can establish the right migration sequence. Although the CPQ model has a lot of objects and dependencies, the starting point will be your Products, Opportunities and Accounts, as these are the primary objects that others are dependent on.

3. Implement in a development environment first

Whether you’re importing legacy data or building something entirely new, the key thing is to start in a development environment, such as a sandbox, then deploy changes through your release pipeline to production.

You’ll want to disable CPQ triggers during migrations. It’s common to use external record IDs to cross reference data across environments — this allows for upserting, and prevents overwriting existing data or creating duplicate records. Gearset handles external IDs for you, saving time and effort maintaining spreadsheets.

4. Deploy through your release pipeline

Getting started with CPQ is undoubtedly tricky. But the good news is that once you’ve built something in Salesforce, Gearset makes migrating CPQ configuration easy — whether that’s between Salesforce orgs and/or source control.

You can build a deployment package that includes CPQ configuration and metadata, and see all the dependencies between them. Gearset will warn you of missing dependencies when you deploy, and offer to add them to the deployment package.

Screenshot: Gearset’s comparison view shows you CPQ and metadata difference between source and target — and all dependencies

5. Test and validate your migration

Your CPQ solution needs to be tested at every stage of the release pipeline. With more manual migration flows, using tools like Data Loader, it’s always worth validating that the data you meant to migrate is in the target environment and looks correct.

With Gearset, this kind of validation isn’t really necessary because the compare and deploy workflow means that you’ll know exactly which changes you’ve migrated from the source — and which (if any) you left behind. You can run a comparison between environments to see how the configuration differs between them. Or better still, setting up Gearset’s monitoring tool automatically tracks any changes that happen in your orgs for you.

Salesforce CPQ and DevOps

Mastering CPQ migrations isn’t a one-off thing. As your business processes evolve, so too will the requirements for Salesforce CPQ. The best approach is to include CPQ in your Salesforce DevOps process, with CPQ configuration treated alongside regular Salesforce metadata in version control, CI/CD, monitoring, automated testing, backups, and more. You can do all of that with Gearset, as a complete DevOps platform for Salesforce.

Try Gearset for CPQ

To discuss your CPQ migrations and see Gearset in action, book a call with us to arrange a tailored demo. You can also try migrating your CPQ data today on a free 30-day trial of Gearset, or by getting in touch with us if you’re already a customer.

If you want to find out more about how Gearset solves the fundamental challenges of CPQ, download our free whitepaper on Salesforce CPQ deployments.

Try all of Gearset for free