Sign up for weekly AppOps insights.

Sign up for weekly AppOps insights.

How Prodly simplifies CPQ implementations for Coastal Cloud

Tori Bealer

August 17, 2017

Coastal Cloud is a Salesforce™ Platinum Partner based in Florida, with additional development centers in Kentucky and Colorado. They help clients leverage cloud technologies like Salesforce quote-to-cash (CPQ and billing) to improve business results and deliver a superior customer experience.

Q2C implementations can be a time-consuming process due to the complexities of relational data migration. Coastal Cloud has overcome this challenge by employing Prodly Moover™.

Explore this informative Q&A with Mike Ackerman, a senior technical architect at Coastal Cloud, about how he and his team use Moover to enable efficient CPQ Salesforce implementations.

Q: Mike, what is your role at Coastal Cloud?
I am a senior technical architect at Coastal Cloud and I help our client implementation teams during the design, build and deployment phases. Internally, I focus on promoting best practices and best-of-breed tools to help our consulting teams deliver projects in the most consistent and efficient manner.

Q: Can you describe Costal Cloud’s expereince with Salesforvce Quote-to-Cash implementations?
We are a leading implementation partner of Salesforce quote-to-cash, which includes Salesforce CPQ and Salesforce Billing. We have implemented some of the largest and most complex quote-to-cash deployments to date. Coastal Cloud is on a short list of partners with deep experience in both CPQ and billing. We are a long-standing partner as we worked with SteelBrick prior to the Salesforce acquisition and that relationship continues today.

We have performed many billing and CPQ Salesforce deployments with complex configurations of products, pricing, availability, discounting, billing and revenue recognition rules.

Our quote-to-cash projects range in complexity. We have completed simple implementations for midsize companies and highly complex implementations for large enterprises. With quote-to-cash playing a central business role, we often integrate with ERP and other systems.

Q: Why is Quote-to-Cash, and CPQ in particular, so challenging from a relational data migration perspective?
The real power of CPQ software is the flexibility and configurability. You need the ability to make product catalog reference data changes quickly and easily to leverage that power. However, there’s a complex reference model working behind the scenes to enable this configurability in CPQ. Implementation teams need to treat this reference data as another important artifact to be appropriately managed across environments. When it comes to disciplined configuration management, reference data needs to be treated as a first-class citizen alongside the programmatic and declarative deliverables necessary to build and deliver the project.

Q: Why is relational data migration such a challenge?
Before we discovered Moover, our teams executed a very labor-intensive process that involved exporting reference data changes to spreadsheets and meticulously loading them back into the target environments. Due to the nature of Salesforce’s internal IDs and lookup relationships, that load process needed to account for the re-keying of relationship data. Care had to be taken to load the parent and child rows in the correct order, re-keying the child rows to point to the newly imported parent.

This is not only a concern with related objects but also rows within the same object that have a recursive relationship. You need to ensure that you are loading the rows within the same object in the right order and re-keying those child rows before they can be loaded.

Finally, when you are delivering a new set of changes to existing target of reference objects, care needs to be taken to identify each row with a unique external key so that you know if a row is being updated, inserted or deleted. As you can imagine, using export spreadsheets with a data loader can be a very labor-intensive and error-prone process.

After we discovered Moover, this became a much more automated process, saving significant amounts of effort and reducing the risk of error.

Q: How long did it take to migrate reference data without Prodly?
Many factors impact the complexity of the Salesforce CPQ and Salesforce Billing model, such as how many products are in the catalog, the number of options and features you have, and the complexity of the pricing and discounting rules. All of these factors influence the migration effort, but it can easily take a full day to do one load without effective tools. This is not a scalable process when following an agile development model.

Q: How do you integrate Prodly into your CPQ implementation process?
In an agile development environment with two-week sprints, you want to stand up and shut down feature development environments frequently. To make your developers productive, you should provide them a full copy of the product catalog from which to develop and test. And you need to reduce that full-day migration process to execute refreshes reliably and on a frequent cadence.

Let’s say we have three developers working on a two-week sprint. We start the sprint by setting up three empty dev pro orgs and use Prodly Moover to instantly populate these empty orgs with current product catalog reference data. Later, we’ll migrate that reference data to a fourth environment to support testing activities.

We also use Prodly Moover for quick, ongoing deliveries of incremental data changes for bug fixes. When the sprint is ready to be delivered to production, we save time and reduce risk by using Prodly Moover to deliver the final reference data. It’s important to note that you will reduce your production users’ outage window significantly by using Prodly Moover during the production migration.

Q: How do you avoid duplicates when you migrate relational data?
You must make sure that you have a unique surrogate identifying key on each of the rows of the product reference objects. Moover will use this key to identify whether it is an insert, update or delete action when copying the data. Hopefully, a surrogate key exists in your data set already, but a lot of times we find one does not.

For instance, you may assume the product SKU is surrogate, but in reality there may be business meaning in that SKU. Perhaps those first two letters of the SKU indicate the line of business (LOB), and the business (team) somewhere down the line may decide that they want to change that SKU during a rebranding effort. Where you thought something was a surrogate unique identifier, it may in fact change in the future, and that could break your deployment process.

Ideally, you want to start the project by identifying truly unique surrogate IDs for each row that the developers can set once and know it is never going to change. IDs should have no business meaning and can reliably identify the uniqueness of a row as it moves across environments. As Salesforce developers know, we can’t use the Salesforce ID for a surrogate key because the ID is not updatable and it changes as it moves from org to org. Surrogate IDs are an important success factor in making the reference data management process reliable.

Q: How exactly do you configure Prodly data sets to migrate CPQ reference data?
Today, this is part of the startup steps for getting a CPQ Salesforce project up and running. We install Moover in the client’s (data source) org and configure the data set for the objects we are going to ask Moover to move back and forth.

The data set represents the configuration, or instructions, on how the data will be moved. We define this initially in the production org to prepare for the copy of data from production to our development and test orgs. After changes are made in the development org, it becomes the new source so that those changes can be copied to test and later to production. In order to re-use the data set configuration already defined in production, we copy it to the development org so that it can also facilitate that org’s new role as being the source for changes.

Currently, Moover has to be installed in any org that acts as a source for copying data. We can also use Moover to push its own data set configurations to and from various source orgs so that we don’t need to re-define the data set from scratch. We are essentially creating our own template. To help clarify this, I’ve provided the following diagram:


With Moover’s new centralized deployment architecture (fall 2017 release), the pushing of data sets and installing Moover in the various source orgs will no longer be necessary, since we will be able to manage deployments from a central org. This will be another big time saver.

The centralized deployment console can even expose the possibility of offering smaller clients a shared reference data management service based on Moover.

Q: How do you hand off the reference data update process to a client once you finish your implementation?
Our standard methods and tools now include the use of Moover for managing complex reference data migrations. During our discovery phase we identify if these challenges are present. Our teams identify this risk early and ensure the project is scoped to include the appropriate tools to mitigate this risk. This helps to ensure our clients and delivery teams are set up for success. I consider Prodly Moover to be a key part of our risk mitigation tool set, along with an appropriate configuration management tool to deploy the metadata for declarative and programmatic changes.

Ideally, we want our clients to procure their own Moover licenses so that once our project is successfully delivered, the process can continue to be successfully executed by the client’s Salesforce support team. We ensure the process is well documented and train the client’s administrators on how to use the tools. We have a very robust configuration and release management process that is well documented and repeatable. Some clients choose to engage us for long-term Salesforce support, in which we continue to leverage Moover for highly efficient reference data management.

Q: Any final thoughts?
Using Moover, we have been able to dramatically improve efficiency and quality of managing our Salesforce quote-to-cash data. We have taken a day-long reference data process and now execute it in minutes and execute it reliably. Moover has improved the way we operate and increased the ROI for our Salesforce quote-to-cash clients.

Do these CPQ data migration challenges sound familiar to you? Schedule a free demo now to see how Prodly can help you solve your data migration challenges.