Max Rudman (00:01)

All right, hi, welcome everyone to this re-recording of the session that we did at Dreamforce 24 about migrating from Salesforce CPQ to the Revenue Cloud. And we're doing this re-recording so that you all who are unable to attend in person can have access to this material. And obviously we're here to answer any questions you may have, so feel free to reach out as a follow-up after the presentation.

So a little bit about me. My name is Max Rudman. I'm the CEO at Prodly, the leading DevOps platform for low-code Salesforce applications like CPQ, billing, and now Revenue Cloud. Previously, I was the founder and CEO of a company called Steelbrick, which of course built a native CPQ solution on top of Salesforce platform and was ultimately acquired by Salesforce in 2016 and became Salesforce CPQ and Salesforce Billing that we're going to talk about migrating from. So I know a thing or two about at least a source piece of this equation.

What's the Difference Between CPQ and Revenue Cloud?

So before we get into this, I wanted to just kind of call out a little bit about the terminology. There's been some confusion about what this new product from Salesforce is called and there's been a few iterations on it. So it is called a revenue cloud and you might ask yourself, might ask the question, well, the revenue cloud has already existed. Well, not quite. There’s been the sort this umbrella of a revenue cloud at Salesforce, but the products themselves, the SKUs were CPQ and Billing. And so now there is an actual SKU called Revenue Cloud, which is what this new product formerly called as RLM, Revenue Lifecycle Management is now called. All so now that we got the naming out of the way, what's the difference?

So first and foremost, CPQ, formerly known as Steelbrick, is a managed package built on platform. Revenue Cloud has been built in core, so it's been built in platform. And really what that means is the data model is now standard objects versus custom objects. And also the processing logic, all the logic of the application, the engine is now running on the same infrastructure using the same technology as the rest of the sales cloud and every other application that Salesforce delivers. And so there are significant performance and reliability and security benefits of being built in platform as opposed to on it.

The second big difference is the data model. The revenue cloud has a much more robust, but also more complex data model. So it's a more enterprise-like data model with lots of different levels of overrides, which allows you to manage large, say, product catalogs and scale, but also introduces some complexity that needs to be managed, which we'll talk through a little bit later in the presentation.

Difference number three is the APIs. Revenue Cloud has been built from the ground up to be API first. Again, these APIs are running on the same infrastructure as your regular Salesforce APIs with the same level of reliability and performance, whereas in CPQ APIs have been added later and because of it being built on platform as opposed to in platform and the limitations, the governors that come with that, know, APIs were actually built kind of calling out to Roku and, and, know, which creates both complexity, but more importantly creates significant latency, which made it unusable for use cases like embedding CPQ in, in e-commerce sites, for example, or, or customer service portals, or your channel partner portals. So the e-commerce use case was very difficult.

And last but not least, Revenue Cloud has been built with this Omnichannel use case and vision in mind, where CPQ had really been built for direct sales. And it's a little bit of a variant on my previous point, right? So what does Omnichannel mean? It's being able to reuse the same product, the same pricing across every channel that you sell, whether it's direct sales, know, internal sales reps or selling through channel through partners or enabling your customers to self-serve themselves through a through a customer portal or an e-commerce site.

What Does It Take to Achieve a Successful Migration?

So what does it take to achieve a successful migration from CPQ to Revenue Cloud? Well, it's this migration trifecta of the market leading data migration platform from Bradley, a purpose-built custom app, this migration tool that we've been building for the past several months, working closely with Salesforce that is built on top of our platform but addresses the specific use case of CPQ to revenue cloud migration. And last but not least and very important piece is the advisory services, the design and implementation services delivered by the trusted revenue cloud as size that you've been working with. And if you don't have one, we're happy to recommend some really great partners that we've been working with who can help you think through the new products architecture and really fully take advantage of the new functionality that is now available. And as we go through different functional areas of CPQ and how they map to revenue cloud, you'll understand why you'll need some advisory services. And again, you use external partners or if you have in-house capabilities for that, that's also fine. But the point is, you know, there really is no one click migration from CPQ to revenue cloud. It's a different product, different architecture. There's definitely some similarities and certain concepts translate pretty well, but others do not. And even for the concepts that do translate well, again, to take full advantage of a more robust data model and the capabilities in the product, you really should do some refactoring and some redesign of your product catalog, your pricing, et cetera.

Migration Framework

So I wanna talk a little bit about the migration framework that we sort of put in place. And when we think about migration, it's kind of like breaking in different functional areas into these three buckets, into these three categories of migration. So one is automated, right? Which is a complete or near complete migration. You'll see some examples of that, but product catalog, the bundles is a good example of that. Yeah, you can take a CPQ bundle and pretty well translate it into a revenue cloud bundle. Will it take advantage of all the new functionality that exists in revenue cloud? Right now, it's the lowest common denominator migration, but that's where your internal or external resources solution architects come in.

Bucket number two is what we call assisted migration. So this is where some automation is possible, but manual intervention is required either before and or post-migration. And the last bucket is what we call manual, which is either there is no equivalent functionality, maybe yet, maybe never, or there is an equivalent functionality, but it's architected so differently that there really is no way to migrate from CPQ to revenue cloud for that area and price rules is a great example of that.

Migration Process

All right, so now that we have the migration framework set, let's talk about the migration process really quickly, and then we'll kind of dive into each of these steps, and I'll talk in more detail about what each of them entails and show you some screenshots of the tool we've been building to help you walk through this process.

So the migration process is that when we think about migration process, it's kind of like these six steps, right? So step one is analysis. Do you wanna take a stock of your CPQ implementation to understand what's going on? What does the configuration data look like in there? And do you have any problems that, any issues with the configuration data that could be problems during the migration process?

So step two is migrating product catalog, right? So it's options, features, product bundles and CPQ, product rules, and everything has to do with the product catalog.

So step three is migrating pricing. Step four is transactions. Spoiler alert, not a lot to migrate there, but we'll cover that in that step. And then step five is the install base, which is your contract subscriptions and assets and CPQ. And of course, very important step six is quality assurance, right? You want to test, make sure everything is working as you intended.

‍

Step One: Analysis

So we've built a purpose-built dashboard in this tool that I mentioned that basically runs a bunch of queries on your CPQ configuration data to identify any gaps or flag any functionality that you're using in CPQ that could be problematic when migrating to Revenue Cloud. And so some examples you can see here. CPQ data model allows you to have orphan options, right? You can have an option that does not belong to any bundle. Of course, it's not really being used, right? Because it's not on any bundles. So it's kind of like dead wood, if you will. But Revenue Cloud data model does not allow that. So if you're trying to grab all the options and migrate them to Revenue Cloud, you're going to get an error on these records that are orphan. And so we'll flag that for you and our migration will actually exclude them by default. But this is a useful piece of information for you to know that you have some dead wood around your CPQ implementation. And if nothing else, you should probably go clean that up. And there's a bunch of areas like this. There's orphan features. There's also flagged for you some of the functionality that we'll cover later on that is not doesn't really have a place in revenue cloud and that you need to redesign or do manual configuration often in revenue cloud. So it's just a really great view to quickly get sort of a, call it a health check of your CPQ implementation.

Step Two: Product Catalog Migration

All right, so now we get into the product catalog. So there's four major functional areas in the product catalog. So one is features and options, i.e. your bundles, configuration attributes, product attributes, configuration slash product rules, and dynamic bundles. As you can see in for the first two, our tool will migrate them. It will take your options and features and migrate them into a revenue cloud bundle. This is really important for you to understand that this is really the lowest common denominator. It's not taking advantage of the new functionality in revenue cloud. And so there's work that needs to be done to think through how do I want to redesign my product catalog in revenue cloud. And there’s also certain functionality, as you can see, that is available in CPQ but does not exist in revenue cloud at least in its current iteration. So you're gonna have to do some manual rework for that.

So next step is pricing, which is another major functional area, right? So there are some things that migrate pretty cleanly, but then there are others that you really need to be thinking about how you want to re-architect your pricing in the revenue cloud.

Step Three: Pricing Migration

So the biggest thing to take into account is, is that revenue cloud works differently. There's more granularity, you have a price book, for example. In CPQ, you could create one-off discount schedules or pricing adjustments that you would apply on a one-off basis to specific quotes. You can't really do that in revenue cloud, right? So if you had those one-off discount schedules, you're going to have to think about how to either have a new discount schedule or just re-architect how you're pricing overall.

Also things like price rules. Price rules don’t exist in Revenue Cloud. So you're going to have to come up with some custom solution there.

Step Four: Transactions

So when we think about transactions, there's not a lot to migrate there, right? You can think about the existing quotes and orders that exist in your current CPQ implementation. There are really two reasons you might want to migrate that data, which is that you want to maintain visibility into your historical data or you want to maintain visibility into your active subscriptions. But the reality is, there’s no need to migrate every historical transaction. So our recommendation is to keep the data for reference, to maybe reference those historical transactions, but focus on active transactions. So a couple of tips here. You want to think about archiving historical transactions outside of revenue cloud to save yourself time and effort. You want to work with your internal resources or your external partners to help you design how you will manage your transaction data in the future.

Step Five: Install Base

Now step five is around your install base. So this is the data that exists in the contracts, subscriptions, and assets. And for this, there's some migration effort that needs to happen there because revenue cloud does allow for transitioning your contracts and subscriptions, and, and assets. You do want to make sure that your pricing, the billing schedules and all that are working.

Step Six: Quality Assurance

So last but not least is quality assurance. You want to make sure you do your thorough testing once the migration is complete. So regression testing, user acceptance testing, and so on. This is crucial, especially because revenue cloud is much more complex and a more robust product.

Key Takeaways

So in summary, there's a lot of opportunity here with revenue cloud, right? It is built for the modern enterprise. You have much more powerful data models, APIs, and architecture, and new functionality available to you. But it also means that there is a lot of work required to migrate over and to take full advantage of the product.

1. Refactor Your Product Catalog: Don’t just take your existing product catalog and try to jam it into revenue cloud. Instead, take advantage of the new features and design your catalog from the ground up.
2. Reimagine Pricing: Pricing is different in revenue cloud and may require a redesign.
3. Avoid Migrating Past Transactions: Focus on the current transactions you need, and archive historical transactions for reference later.

So thanks everyone for joining! If you have any questions, feel free to connect with me on LinkedIn. You can find me under Max Rudman, and you can also visit us at Prodly.co. We’re happy to discuss how we can help you in your migration to revenue cloud or streamline your Salesforce DevOps processes.

‍

‍

‍