Name: Migrate from CPQ and Reduce Technical Debt
Uploaded: 2026-11-03T18:30:55.541Z
Duration: 1 h 1 min 20 s
Description: Migrate from CPQ and Reduce Technical Debt

Transcript for "Migrate from CPQ and Reduce Technical Debt": Good morning, good evening, good afternoon, everybody, from wherever you're joining in from around the world. It's good to have you here. I'm always curious. This is what I like to do at the beginning of these sessions. It's just get you to pop in the chat where you're joining in from around the world. Number one, gets us all acquainted with the chat bar. And number two, it's always interesting to see, you know, where, where everybody's coming in from. So if you can jump in the chat and pop in where you're joining in from, and while you're in the chat as well, you'll notice, just to the right of that, there's a Q and A tab as well which I'll talk to in a second. There we go. We're seeing Barcelona, India, we've got Georgia, we've got Sweden, all over the shop, all over the shop. Have Have we got anyone else from The Pacific again in in my area, Australia, New Zealand? No. Not yet. Not yet. Everyone's sleeping. Whatever. That's alright. Thank you very much for being here today. It's gonna be a great session. We're here to talk about migration, from CPQ over to RevCloud and what that should look like. Now I did mention before the Q and A tab. So you will have questions throughout, there's no doubt. Make sure when you have questions that you'd like the team to answer at the end, you don't pop it in the chat but pop it into the Q and A tab because, it basically, it'll group all the questions together inside of there. We'll be able to highlight them at the end. As you have thoughts, don't hesitate to pop them into the chat and engage with others as well. But if you do have questions you want answered at the end, make sure you pop them in the q and a tab. And if you see some questions in there that you, you know, were similar to what you were looking to ask or that, you know, while you're in there, you think, hey, I'd really love to see the answer to that as well. Just give it a thumbs up. And that way, if we're running out of time, we need to prioritize some of the the, the the questions that more people are looking to have answered. We'll be able to do that just by, you know, going off the number of thumbs ups that we got. Beautiful. So, again, thank you very much for being here. Without further ado, I'm gonna jump in, to this session here. So, we are here today, with the Argano team, and look, you know, starting with myself. We got a lot of people here to introduce, and you've already heard enough of my voice. So I'm gonna introduce, or welcome to the stage, I should say. Sorry. Blake, Colin, and Muthu, if you guys could jump onto the stage, please, and we'd love to to introduce yourselves. Well, maybe we'll go left to right. Blake, did you did you wanna just do a quick, twenty second intro, for yourself today? Yeah. Absolutely. Thanks, Tim. And thank you, everyone. Nice to virtually meet y'all. Blake Williams. I'm the chief Salesforce architect with Argano. In my role, I work with our largest customers early stage in the define and design stages of their large programs specializing in Salesforce revenue cloud, solutions. I also lead the, innovation arm of our practice focused on defining and bringing, our innovative Salesforce revenue cloud solutions, to market and our customers. Paul? Might be on mute there, Colin. Good morning, everyone. Great to be with you today. My name is Colin Williams. I lead from Switch Spirit. I spoke with my customers across the board on to find out how that is an educate. Just, just call it. We're we're having a few issues with your your microphone. It may... You might have the wrong one selected. But that's that's alright. Thank you. Thank you. Oh, is that better? Slow better now? That's so much better. Yeah. Yeah. Do you want... Do you wanna do that one again real quick just will make sure everybody. knows it here? It's always the technical difficulties. That's it. That's it. One more time. Good morning, everyone. So, my name is Colin Pullums. I work with revenue solutions here at Argano. Similar with Blake, I partner with customers across the board with implementing revenue cloud across our tech stack. I'm really making sure that their revenue operations are strong as they're looking at Salesforce as their true system of record. Hi. Thank you. Great to be here with everyone. Nice to meet everybody. I am Uthu Murughe, and I am from Salesforce's revenue cloud product team. I have spent the last six years at Salesforce and over seventeen years in the quote to cash or product to cash space. In my role, I partner with revenue cloud customers, partners, and our internal teams to drive successful adoption of revenue cloud from go to market to product positioning to ensuring we are building what our customers actually need. Really excited to be here. Thank you. Lovely. It's great to have you all here. Thank you for for your... Introducing yourselves as well. Everybody watching, I just wanted to point something out. This will be an interactive session. You're about to see on screen now a poll come up. If you can jump on and put your response into the poll here. The question is, where is your organization in its move away from Salesforce CPQ? So you should see a little interactive buttons come up. If you can pop in your answers there, we're good to see where everybody's sort of sitting at. Here we go. Oh, the votes are coming in. So majority sitting in, a significant majority sitting in not started yet to evaluate. We got a couple, between building the business case and actively planning on mid migration, and the smallest group looks like you're already migrated. There you go. So significant significant majority have not yet started and still evaluating. Well, that's great. You're in the right place. We've got a a a team of experts here that that, will be able to shed some light on on how you should potentially approach that. There you go. That's good to see. Alrighty. With that out the way, I will pass on to Colin. Did you wanna put your slides back up on screen? Beautiful. So as we're talking today, migrating from CPQ to revenue cloud is definitely the the move that everyone's starting to do as Salesforce has released this latest technology. As you're planning for it throughout your organization, there's really two questions, though, that we found makes the decision, a really stable path as you're looking forward. So the first one being what comes with you, and then who moves and when do you do it? So we're thinking about the what as Salesforce has, released revenue cloud formerly known as Agent Force revenue management. You've been spending years on CPQ. You've developed, a lot of custom, processes for your business. You've really implemented it to work for your business and with CPQ as a technology as it was before. But that question of should you actually move all those years of CPQ configuration and customization along with you into the new revenue cloud product, is really that question that we wanna ask first. And the second part being then, how do you actually roll out that technology as you're releasing it across your business? So, ultimately, when we're thinking about, you know, what it takes to actually move the migration, as Salesforce CPQ is end of sale, meaning that you can no longer purchase licenses for it, but you can still be supported for it. You're not forced to do the migration, but it's definitely something that you wanna be thinking of of when you're gonna be moving on to the new technology. So ultimately, you know, how is that investment going to be for your organization as you're moving forward and how are you gonna time it? And then really as you're looking at, that time and and you're rolling it out, the cost for waiting does start to compound over time. And for that, Muthu, anything that you could speak to as well as we look to the transition from CPQ into Salesforce revenue cloud and the timing of it? I think, instead of looking at that from a timing perspective with... It's about thinking about how you prioritize, spending time about planning your foundation. Right? One thing I see often that is the pitfall, I would say, is actually, trying to make it like to like and see... And then plan based on that. And that could be one, that rings detected. Number two is that it is about... Okay. You... Now you're... It is going to look much more overwhelming and, less ROI for the, investment you are making. That's how I would think it. Okay. Absolutely. So, ultimately, as you're looking at making those. two decisions of your what and your when, as Argano here, we've worked with customers across the board on how they've actually gone and moved from CPQ onto revenue cloud. And as we have Blake here, who's actually worked with some customers on doing that exact transition, we're gonna have that conversation. But before that, we've got one more poll question for you. So I'm gonna stop sharing real quick and, Tim, I think we're gonna bring that up. Yes. Indeed, Colin. So the next questionnaire you'll start seeing on screen is how would you describe the technical debt in your current CPQ org? So we've got, again, you should see those buttons pop up on screen, and we'll start to see the votes coming in. Significant. Significant. So heavy Apex, and custom objects coming in there. Moderate some. That makes sense. Nobody's gone minimal yet. There you go. Not sure we haven't fully assessed that it's also quite low, but significant. That that lines up with with general trends that we're sort of seeing everywhere as, you know, everybody's got some sort of degree of technical debt. A lot of it is is, quite significant as well. So there you go. Okay. Somebody's coming in with the minimal. There we go. Good stuff. Blake, I think you were, you were up next. Is that right? I think so. Wonderful. Alright. Excellent. Yeah. So, technical debt, big topic. And that's really what we wanna dig into here today because it's really, in our experience, the crux of what drives, success in these programs and migrations. So let's start with the first decision, and that's how much of what you have today should come with you and survive. In our experience, there's four credible ways to answer it. We think of this as the four patterns. None is wrong. One is the right answer for you and your organization. One is recreate, and that's rebuilding what you have, behavior for behavior. It's the least change for the business and usually the shortest road to go live, but it isn't necessarily the least amount of engineering or development work. And that as we know, revenue cloud is a different data model, different technology, so there's no true lift and shift. Right? It can be the right answer when your CPQ and existing, tool is fairly clean, when your business model isn't changing as part of the transformation, you have a hard date that can't move, and your business, I think most importantly, maybe can't absorb both process change and a platform change at the same time. There is a cost. There's a trade off. That's a theme that you'll hear throughout this is all of these have pros and benefits and trade offs as well, and it's about making the right choices that make sense for your organization. Two is selectively transform. This is keeping the core while modernizing what matters most. In our experience, that's usually the catalog. But where the trade off there is that every decision needs to be defended, keep, or rebuild. Third is what we call rationalize, and that's really redesigning from the bottom up. Right? The commercial model from first principles, that has the most amount of value and upside while, obviously, the most amount of change happening as well. And then lastly, start somewhere new, and that's building the future model on a new product or business line first while sidestepping the existing install base. I think a couple things to point out here. One of the first places we look for accumulated technical debt is the product catalog. Right? It could be SKU sprawl, duplicate SKUs, outdated bundles, pricing that no longer matches, how you actually sell. And it's also the place where rev ops can lead the charge without being necessarily dependent on system changes and IT. I would say, lastly, rounding this out, every pattern except recreate turns, you know, one big decision into lots of small ones, item by item, going back to what you have today in your technical debt. And so the trick is you need a rule for moving through those and making those decisions, efficiently. And ours and our experience that we found is that the business truth that you have has to survive, where the tool artifacts have to earn their way forward. And often is you have many stakeholders in a room that can't agree on what that is and where the burden of proof sits on keeping what you have, not changing it. So segueing, right, how do you tell which is which? That's really getting to the linchpin of this. And moving to the next slide, the way we do that is through three questions. Right? Keep, rethink, or retire. It sounds simple. It's it's not. The hard part is knowing whether you're looking at a business requirement or just the way CPQ happened to implement it. And this is really the crux of addressing technical debt. Where keep says, does the customer or the contract require it, require it? Is it part of our commercial policy? Is it part of compliance? Then that's business truth. I think approval rules and discount thresholds are policy, so that has to come with you. Secondly, rethink. This is really the hard part. Right? Where some workarounds encode a real requirement, they just happen to do it, badly or in a nonoptimal way. Maybe because of an implementation pattern, maybe because of the way the current tool works. A good example of that could be, you know, fake products that exist only to carry a fee or a discount. The fee is needed. The product is not. And so you can't confuse the implementation with the real requirement that's underneath it that has to be carried forward. Lastly, retire. These are things like duplicate fields, obsolete automation, or workarounds that exist only because the old architecture and tool, required it. Right? So summarizing, right, keep is hard because the requirement usually isn't documented. It could often be in people's heads. It's in contract language. It's not reflected, explicitly. Rethink is hard because the people who know why it was done aren't the people who necessarily know how, and you need both in the room to sort that out. Last point on this, I think in our experience with b two b especially, a lot of revenue, and this might be, typical for you, is that a lot of revenue runs on exceptions and edge cases, right, where your biggest customers have the most negotiated terms. So when someone calls something an edge case and you have to disposition on what we're going to do about it in the future state, you also need to ask, right, is it rare by count or is it rare by revenue? And the way we'd like to do that is through evidence in the system to understand, right, not just how many of these price rules have fired, what product rules are still actually getting used, what products are in use and and and actually still sold. You actually need to understand the revenue exposure and contractual obligations before you can just call something obsolete and retire it. So this is what comes with you. And so next, we'll look at the second decision, and that is who moves when. The way we like to think about this is every rollout strategy is really a choice of boundary. So you're really deciding which transactions run on CPQ versus which run on revenue cloud and really the crux of what happens when a customer needs both. The options that we like to bring to the table, one big bang where the boundary is really time. You're trying to get to one platform the fastest. The trade off being where all the risk lands in a single cutover and release. The second is pilot where the boundary is. We think of it as capability. Right? You're running to prove the hardest cases before you commit to a broader rollout. The key there is that the pilot needs an exit decision. What you're proving, what would stop from scaling, who moves next to make sure that you're moving from the pilot into a broader rollout. Third, we call a bridge, and that's really where the boundary is contract life cycle. So it's taking the install base and figuring out when is the install base gonna move from the current tool to the new tool. The trade off there obviously is multiple paths for running the business while your install base transitions from the current state to the future state. Two paths for ARR reporting as an example. Lastly, cohort, where the boundary is a population. It could be a customer segment, a region, a business unit, and that's where you're containing change to a defined group. It looks clean until often an enterprise customer buys from multiple business units or multiple regions, for example. And so now that customer crosses your boundary, and you have to deal with that. So the... I'd say the real question isn't so which of these to pick. It's thinking about this in terms of the boundary and what boundary keeps the two revenue platforms and tools from colliding against each other. So that brings us to the next slide, which, we'll talk about what has to be true for both of the systems to actually run-in parallel. Right? If we go to a phased approach, there's a stretch where both systems run, and that's where phase migrations will either succeed or, in our experience, stall. So six things to consider and really settle as part of the effort. One, contract of record. And that's, knowing where the contract origin is going to be. One default we found is a CPQ contract stays on CPQ until, like, defined migration event, usually renewal. That's a clean boundary where you can separate, but it comes with some trade offs. The deals that cross boundary... So a customer, for example, on a multiyear CPQ contract buys a new product and wants to coturn that on their current contract, under the default cross sell, the motion you likely want on the new platform would come last. So the alternative is to make cross sell the migration event, but that then depends on obligations living in different places. Right? So nothing black or white here. The point is there's, benefits and some trade offs that need to be worked through to arrive at the right, approach and strategy for you. Rounding out some of these right open quotes, quotes in setting the explicit closeout policy where some quotes get closed out on CPQ, others get requoted in revenue cloud, and there's really good tooling and as well as accelerators that we bring to be able to do that, mechanically so that nothing is lost or dropped, when the cutover happens. Amend and renew. So the first renewal, really, that we... In our experience on migrated data is the true test of the migration. So it's all about operating on your migrated install base to prove that outcome parity, at the end of the day. And lastly, rounding this out, reporting, critically important in that when you're running two systems, you're really supporting two data models. So things like ARR, often bookings and pipeline, sit on slightly different data models. And so you need to agree on a reporting view before go live. And lastly, cut over timing. I think it's probably bears, it's kinda stating the obvious to stay away from quarter end and renewal peaks and to freeze the product catalog, during the actual cutover window. So good segue in that, I think, right underneath all of this, what's the key theme? It's really data. And so we talked about the two decisions. Right? How do you decide what moves, who moves when? I think the critical piece here is how do you prove that it all moved correctly and data really sits all underneath that? So we'll go to the next slide and talk about what really drives success in these migrations. I think of, a few principles here. One, source of truth per data domain, not necessarily system. So where Salesforce, billing, ERP, they often hold the same customer and contract data. When they disagree, it's important to understand which one wins because they often will and do, And you wanna decide that by domain. Right? Customer domain, products, pricing, contract, invoicing, revenue, and not necessarily by system. And then the other consideration is to decide how the other one gets corrected when they do disagree. Secondly, cleanse at the source or in staging. So data quality isn't something the migration load itself will fix. It's just mechanically moving data. It's remediation that has to start before the load as its own work stream and really be planned for upfront. You wanna fix that at the source where you can. With legacy systems, that could be, impractical, and so you wanna fix it in a staging layer. And you certainly don't wanna load that dirty data into the two d source system, and plan to clean it up later. Right? We all know that that is not gonna work. Validation gates. I think there's some amount of automated reconciliation on the data that can happen, right, through, validating that the data mechanically migrated and matches up. There's also business validation. That's gonna tell you, right, is the right commercial obligations, represented. Oh, over and above, just do the totals and dates match up. And it's important to rehearse that, through a full load and a full copy sandbox, and time it to size the cutover window. Lastly, we call this test outcomes, not process. Your process may be changing, and so it's not necessarily process parity because the tools also will have slightly different ways of working. But you wanna test for outcome parity, especially where you've deliberately changed products or pricing models, you wanna test against the new expected outcome, instead... And picking your, you know, most, critical deal shapes and economics and contractual, shapes and making show... Sure those are tested, throughout. So I think... Why don't we go ahead and hand it off to another poll question, to understand... I'll hand it off to you, Tim, to understand, kind of the biggest obstacles holding back, Beautiful. your few migrations. Yeah. That's that's exactly it. Yeah. So this is the... This is another poll, everybody. So you'll see the options come up on screen shortly. So what's the biggest obstacle holding back your CPQ migration today? So we can see complex pricing and product rules as the first vote. There we go. Getting some votes starting to come in. So complex pricing sits up there so far as the, the highest rated, followed closely by unclear ROI and limited internal resources or expertise. And it looks like the, the least, common option there is the fear of disrupting the sales team. There you go. Oh, common. feedback makes the week here for sure. Alright. Let's. do this. stuff. So as you're thinking through, the decision points that it takes to really get you from CPQ onto revenue cloud, there are some questions though that you can start asking today. And how we've really thought about that is seeing through transaction mix first and foremost. So, we know between Salesforce, your billing system, your ERP tools, all those other connected systems that you have that really run your revenue engine. You'll have that same customer, that same contract invoice information, but really deciding by domain, not by system itself. So for each name, the system that's gonna win. So in the instance that Salesforce might have, it shouldn't, but in the instance that Salesforce might have a different instance of your customer versus your ERP system for your, contract. Right? Which is the actual system that's gonna win when it disagrees and how it gets correct... Corrected? How are you gonna cleanse that at the source overall, as well? So when we're thinking through your cross sell volume, and your transaction mix for your amendments versus renewals versus new business, what's your boundary choice overall? You know, a lot of organizations today, you can't answer that question. You can actually find that in Salesforce by going through and counting your SVQQ quote types and actually looking at over the past twelve months, how your different transaction volumes have been. For your cross sell volume overall, how much is cross sell onto an existing contract? So that will really help you determine, while both systems are running in parallel, what do you need to do in order to understand what the mix is from CPQ versus onto revenue cloud itself? You can find that today by going into SBQQ and looking at the upgraded subscriptions. Number three is one I think that is really one to key in as you're starting to do your due diligence is really thinking through what are the customizations that actually matter. So as you think of the legacy of you built your CPQ system over the years, you've adopted a lot of customizations for either business needs, or because you needed the technology to run-in a specific way. For that second bucket where you've really customized or you've configured the tool for CPQ itself, that doesn't necessarily need to come with you when you're moving on to revenue cloud. So making sure that you're clear on what are the actual customizations that were done for business purposes versus ones that were done just for technology's sake. And then understanding what is that actual clean boundary. So when you have shared accounts, right, parent child accounts, different structures or multi business unit customers across all throughout your organization, really understanding can you actually migrate in a cohort or not is really gonna be key. So understanding where your accounts that have active contracts in more than one BU or customer or segment or region will help you understand how you're gonna segment that boundary overall. And then the fifth one really is the test one. So what is your largest deals at full size? That'll help you get an understanding of overall performance that you're gonna need and really when you're thinking of will it fit. Right? We know that there were limits, with CPQ. And as we moved into revenue cloud, Salesforce has definitely ramped up performance. But really understanding what's your largest deal, what's the most complex, combinations that you might have with products. Do you have thousands or 10 thousands and lots of different attributes? Really understanding what your deal size is is really gonna help you understand how to fit it and moving forward into the new replica cloud tool. So you can answer those internally this week, right now, as you're on this call or as you're moving forward and thinking through. And so we've looked at the framework now. I'll turn it over to Blake as well, and we'll discuss now, how it actually has happened in a real migration from one of our customers. Sounds good. Thanks, Colin. Yeah. So here's how those decisions played out on a real program. So in this case, health care technology company, multiple business units, lots of growth through acquisition. And as an early adopter of Salesforce CPQ, lots of accumulated tech debt over about seven plus years. This was about fifteen months to go live, so a longer end of the timeline. The challenge wasn't replacing CPQ. It was working out which parts of their complexity were still really needed to run the business moving forward. And so the two decisions, right, what came with us, it was selective transformation, not recreate because seven years of workarounds didn't represent the true business requirements, but not full rationalization because the commercial, commercial model was sound, and that was worth keeping. The contract required pricing and approval policy, and it was really about retiring the CPQ workarounds and duplicated automation, as well as a lot of data model debt, that came with it. On the who moves when, we rolled out by business unit because those clean lines and boundaries already existed. The different business units had different catalogs, separate approvals, separate teams, separate contractual structures, and terms. The risk of that boundary showed up where you would expect, right, where a small number of enterprise customers did business across more than one unit, and we had to handle that, deliberately. I would say highlighting kind of some of the less visible work here really is, planning for a consistent way to represent customers, products, contracted assets, and their revenue life cycle, the same way across product lines and business units. And, really, in our experience, that's about setting the foundation and getting as much leverage and ROI out of the new Salesforce revenue cloud platform capabilities, and using the software as intended, to set that foundation so that when you do roll out to one business unit, you can efficiently scale that to other parts of the business. I'd say rounding this out also, like, technical debt, I think, gets gets, like, a, a bad rap, obviously, for obvious reasons. But at the time, it's the right answer. Right? It's it's built to solve real problems using the current tools. So the way we like to think about that is it's, you know, often yesterday's decision that was rational, outliving the conditions that made it rational. And kinda coming back to really in our experience, that's the linchpin of driving success and ROI of these projects. We'll go to the next slide, and just talk about the outcomes. The big one was roughly 30% faster time to quote across the board, quote types, new business, amendments, renewals, transfers, so on and so forth, alongside a very simplified streamlined, catalog. We also retired three legacy components and systems along with CPQ. There was ERP billing and customer integration as well that connected them all together. So it was fewer systems needed to run the business, fewer, integration dependencies, and less duplicated logic across the revenue life cycle. Where that shows up, not just in time to quote, but really is in, agility and the businesses, and IT's ability to respond to new product and pricing models, especially around consumption. The other piece on the process side is, six core processes were redesigned, putting multiple business units on one foundation. Right? Foundation for product, new pricing models, without the old constraints of the existing system. So it was really about setting that, one, getting the business unit onboarded onto the two d architecture as well as setting that foundation, to be able to scale to additional business units. Lastly, I think kinda talking about lessons learned, to the next slide and kinda what we'd say we learned, and what we'd advise to you to think about before you start. One, undocumented logic. So I think that we under scoped, not just in this program, but I think primarily in this one, how long it takes to find out what years of CPQ customization, actually do, why it's actually there, how it works, what it actually, is there to serve, at the end of the day. And so I think this was, at the end of the day, under scoped. I think it has to be planned for upfront, not just, having a log of it or a documentation or a page sitting out in a SharePoint, but actually really understanding, what it's there to serve and the business requirement that's in... That it's intending to solve. That's really where you get to the decisions that have to be made to determine, does it need to survive and in what form? Data debt was a big one as well, where we found data quality problems late enough that they squeeze the testing and UAT window. And, really, the the data work has to happen early and often, and it has to be made, sort of a clear work stream with ownership, with quality gates, before the first conversion rehearsal. So really treating data quality remediation as its own work stream, that gets prioritized and runs alongside the development. The last one, just three releases a year, and it's recognizing, right, building on a platform that keeps evolving, for... In a very good way. Right? New features get released. But to also have a plan for regression testing, in an efficient automated way, your critical deal deal scenarios and running that on every release preview to avoid surprises and to be able to keep going, right, and and keep, forward progress. So that's probably a good segue. Speaking of releases on the platform side, Muthu, I'll hand it over to you to talk about where the platform's going next. Yes. Thank you, Blake. Yes. Forward looking statements. Salesforce is a publicly traded company. We are going to discuss certain roadmap items on this call. So please make all your purchasing decisions based on currently available products. Next slide, please. So one of the first things I hear in migration conversations is how much work this is going to be. Right? Part of the answer is the tooling we are investing in. It's a... It's an application. It's called migration assistant, and it is coming in December. So the migration assistant uses agents to do the heavy lifting in in four ways, really. First, it migrates your data and metadata with agents. So the agents map objects and fields from your CPQR to the target, then move the data. That's the work that usually takes weeks of spreadsheets and manual mapping. I can understand from talking to our customers and partners like Algano have shared their experience. So that is one, heavy lift area. Second, it really implements com... Complex, like, you know, complete business features, not just, like, cons. So your CPQ org has Apex triggers and configuration that make quoting work the way your business does. The migration assistant transforms that code and configuration together. So you can see it on the screenshot a little bit, wherein it goes class by class with the CPQ code on one side and the transformed version on the other. And then third, the, migration assistant itself uses cloud, but you can bring your own agents, LLMs, or MCP plugins. So if your team or your implementation partner already has tooling or a preferred model, you can plug it in. You aren't locked into one way of working in that sense. And then fourth, you move fast with humans in the loop. So every transformed class or any component that carries a status such as, you know, needs, review, or accept, or block. So you... So that your implementation partner or your team accepts, rejects, or reruns each one of those. So that's human in the loop in every step of the way. I will slide, please. say, Yeah. Yeah. move through. on this one. Thank you from Salesforce for for really focusing on this feature. As we've been implementing revenue cloud for customers across the board, we've started to ingest an a... AI in our processes to really help with the implementation, but having actually tooling from Salesforce built into the product is definitely gonna be a game changer, for a lot of customers that are looking to make the move. With this feature as well though, this is an accelerator on the technical side of the house, but there's still really that understanding and the cataloging of your business processes and why you have that customization to begin with that is so key even as you're looking at this new migration assistant. Yes. Great point, Colin. Yes. The... That domain expertise is still super valuable. This this will be an accelerator in terms of actually, accelerating your implementation time, but, but then the domain expertise is not matched with this assistant. So I just wanna call it out. Awesome. Alright. Yeah. Okay. So you are here because you are thinking about moving, from CPQ to revenue cloud advanced. So I wanna show you where are, the product is headed so you know the platform you are moving to keeps getting better after go live. Right? So three themes we generally go with that guide where, revenue cloud advanced is investing. First, easier to deploy. It is easier to deploy, manage, and use, which means faster time to value and, faster time to revenue after your migration. And then the second is voice of the customer. So product depth and flexibility shaped by your use cases. So definitely keep telling us where your business doesn't fit clearly today. I did get a lot of insights from the polls we just done today. So definitely, keep talking to us. We are all ears. And then third, AI superpowers for everyone. With Agent Force and Slack bringing personalized contextual AI to every role, that touches revenue, all inside your pricing approval on all the revenue rules. Right? Here, you are not just replacing CPQ. I think probably by this time you have understood it's a much broader scope as a revenue platform. It's it's more beyond CPQ itself. So you are moving on to the platform where this investment is happening. So I, I wanna call that out that we continue to involve the product. And also going back to this migration assistant for a little bit, we we plan to make it GA in December, but we plan to continually, improve on it, releasing enhancements as part of monthly release. K? Alright. Yeah. I will now hand it over to Colin. Perfect. K. Thanks, Muthu. So as we've. talked about, product updates and changes, customer use case, and what we've seen with migrations and even the patterns that you can go through as you're thinking of how your organization is gonna start to make that change, here's what we think you can start doing before you actually get to that point. So as you think of even actions you can take right now this week, start to answer those five questions. So if you are in RevOps, really understanding what your transaction mix is, your cross sell volume, getting an understanding of your revenue run and your data, today. If you are on the IT side of the house, really understanding what is that customization mix. Partnering with RevOps and with your business team of understanding, the whys behind some of that and getting it cataloged, really understanding the CPQ objects and what you have in your current system today. As you're moving forward in your planning process as well, even this month, it's really starting to sort those customizations. So what is based off of a business process and business demand, and what was done because of a technical reason or a technical fit for CPQ. All that doesn't need to come with you is really starting to, sort it and having that understanding of, am I gonna keep it? Am I gonna rethink it? Am I gonna retire it? Understanding that across the board, and IT having that understanding of your source of truth for each of your different data domains, products, billing information, pricing, etcetera. And then before you actually commit to making that migration from CPQ onto revenue cloud, prove it. So look at your hardest deals. Get a good understanding of, you know, five to 10 of your really complex deals, your really large deals, the ones that forced you to really flex CPQ to its limits. Actually test out the case for it. So as you're proving it in that sandbox, actually rebuild them, have an understanding of what that current release is that you're gonna be migrating from CPQ to revenue cloud is overall. So that before you commit, you can understand that this is actually gonna work for our business, and we're ready to go once we actually do flip that switch. And, ultimately, for that, if you're, you know, working through in the months and you need some help, that's where partners like us are here for. So a little bit more about Argano and Salesforce. We have moved through here. As you can see, we partnered with Salesforce across the board. We are a top level Salesforce partner. We support just about everything on the Salesforce platform. We particularly, though, really key in on revenue solutions. So our company across the board has expertise in ERP and data systems with a heavy focus on how does... We make that revenue engine run across the board. We've been working with Salesforce, for over twenty years now. As you can see, some of our credentials here, really high CSATs, part of Agent Force program. We've embedded AI throughout all of our delivery expertise and how we're actually implementing for our customers as well. So really thinking through how we are partnering with Salesforce and partnering with you on taking revenue and revenue operations to the next level. Supporting industries across the board, with a heavy focus on really those business platforms. And as you're thinking through how do you actually connect CPQ and RevenueCloud to the rest of your technologies as well, definitely look to us if you have questions. We're more than happy to help and really work through that planning process with you to make sure that you're successful in your rollouts. Alright. And with that, I think we are just on time. We're gonna move on to q and a. I've been seeing throughout our conversation, you guys have put some great questions in there. So let's start off with... Did you we'll go down to one of our earlier questions that we had here. And while I'm pulling that up, want... go ahead, Tim. Yeah. Colin, I was I was gonna say, did you want me to sort by... I... I've got a list and I can see the outposts. Did you want me to read them off based on the most popular questions and down because I know we got limited time? Yeah. Let's go ahead. Beautiful. Before we do that, I really wanted to thank you all. That was a really, beneficial session. You know, there's a lot of good takeaways in terms of the the migration and things to consider. And then layering on top of that, we do have a few questions as you've said. So the first one here is, how did you measure the 30% faster time to quote? Yeah. I can take this one. First off, the customer in this case was really good about measuring their baseline, across their roughly six core processes and defining their KPIs at the outset, the program on how they wanted those to move. So the baseline measurement, which obviously is one side of the equation and which is critical, was done. And then on the other side of that, we were very deliberate in UAT to remeasure those in the two d solution. And so it was a combination of those two things, that drove the measurement. That's an average across their six core commercial processes, right, new business, different flavors of commercial amendments, renewals, so on and so forth, migrations, transfers. Right? There's six core, and then there's different variations, each within those right across all of their use cases, right, which was, quite a bit and very, I would say, very granular. So it was really having a plan in UAT to do the remeasurement against the baseline as part of the execution. So real real consistent measurement from, you know, where you start and really getting a good baseline there and as you sort of building and iterating, continuing that measuring and testing throughout, you say? Yep. Beautiful. I love it. Good stuff. Alrighty. The, the next question we have here is, according to your migration experience, how long both... How long do both systems have to run-in parallel? Yeah. I'll start on this one, as well. It's a good question. It really depends on your longest contract. And so let's take the contract life cycle as the boundary. Right? And that you're going to let your existing contracts run out on the current tool. Let's assume it's CPQ. And on a contract event, let's call it renewal, they'll move over to Salesforce revenue cloud advanced. It really depends on how long your contracts, your longest contracts run for. Right? Do you have five plus year contracts? And, of course, there's always, I think, a business decision to make on maybe your longer contracts or your biggest customers to just go ahead and move those, separately to the new solution as well. So there's a way to look at that and to look at your entire install base and to say, again, multiyear contracts, when when do we expect these to run out? Can we go ahead and just mechanically move some of those over versus letting them migrate on renewal? That's really, I would say, the biggest consideration, because that is... And maybe reading into the question, you wanna minimize the amount of time where both systems have to run-in parallel. That becomes not impossible. We've done it. Right? But a a a solution you really have to design for, especially where multiple people are are spanning across the two tools. Yeah. I think this one is, I'm keying into the specific how long both systems have to run-in parallel. So, ultimately, that's a a business decision that we try to make with you upfront when you're planning. Some organizations want the long tail where you have CPQ and revenue cloud that may be running for a quarter or more, to that slow migration path. Some organizations, it's more about you're kind of forcing that migration. You have a date that you really wanna switch everything over to, and that's a part of the planning process. So if we know that there's a a time where you wanna have everything cut over to revenue cloud, then we'll plan, your your project and your migration over from that date. Or if you're thinking that you might do more of a long tail run ultimately because you have, you know, five year contracts or things like that or other business decisions where you don't have a forcing action, then you can plan it differently. So it will vary based off of your business, your business priorities and understanding, but it's definitely a key piece in really planning out, how your actual migration is gonna go in the Beautiful. long run. Makes a lot of sense. Alrighty. The the next question we have here, says we have a CPQ solution with a lot of contracts with subscriptions. Should we keep all of these with the CPQ rules, etcetera, until that contract gets renewed? Or should we create orders of them and force them into RCA and the asset management? What are your recommendations? Yeah. I can take that first, to give my perspective. Basically, again, this goes back to one of those business business decisions. Again, when you think about it, right, we we went with that business decision, to drive that business decision, there are two deciding factors. I think, what, Blake walked through. One is the migration path, and the second one is the implementation approach. The implementation approach is about, like, you know, are you going big tank? Are you going cohort based? When it comes to cohort based, some customers choose to, you know, do only new business in, the new world and then the renewals... Until then it was... They choose to keep it in CPQ world and so on. Right? So there are different, implementation approaches. But in order to decide which implementation approach is good for you, you had to go one step ahead in terms of thinking your migration path. Are you doing lift and shift? Are you doing partial transformation? So that will guide you to implementation approach, and that will tell you what is the best approach for you with respect to contacts and subscriptions. Yep. Similarly. It's. a good, question. I think it... go ahead, Blake. Oh, sir. Yeah. I was gonna say the other, thing you can do is is look, try to answer the five questions this week, that Colin walked us through as well. Right? And that Muthu really summarized well here in that you look at your transaction mix, right, in terms of what mix and volume of your transactions across that install base are amendments with cross sell versus renewal versus net new business. Right? That can start to give you an idea of, the volume, and then specifically cross sell volume on your, install base, right, where a lot of b to b businesses have heavy existing customer upsell cross sell, sales motion. Right? That drives, material fraction of the revenue. Third, inventory or customizations. Right? What customizations really matter? You talked about price rules, product rules. Are there customizations? Do you have quote calculator, plugins, script, write custom pricing, so on and so forth? What really matters for your business? And then the clean boundary piece. Right? How do you separate that install base? Is it by business unit? Is it across region, customer segment? Right? Is there a boundary you can draw that separates, who operates on the install base, as well? Beautiful. I'm just having a look. I can see one there that I don't think is a question. I'm gonna go to the next one there. So since you are doing many of these projects... Sorry. Since you are doing many of these projects, you're using an AI tool to help with driving some of the, conversations and considerations? Yeah. So as we've... You know, Salesforce with all the advances of AgentForce, all the advances with Cloudforce as well, the partnership with Anthropic, we and our own internal, AI investments here at Argano, we've been embedding AI across the board throughout our cycle with customers, using it, first and foremost during our discovery and design where necessary to speed that up. If you've gone through your initial CPQ project, you probably remember the old days before AI where, you know, it took weeks to months to get everything documented and mapped out. So we've been using AI from some of those fashions to help speed it up, to make sure that you can get a a faster return on rolling you out your new system. On the delivery side of the house as well, we have some AI tooling that we use to help expedite the actual configuration, as we're releasing it as well. I know Blake has just been working with our innovation center on a lot of AI tooling as we're going through the delivery cycle. On testing, we're embedding AI throughout our process. So I'd really say throughout every step of the implementations as we've been implementing, we've been thinking about how can we use AI to drive more ROI for our customers across the board. And definitely looking to partner with Salesforce's. Muthu and team are releasing more AI features as well within revenue cloud. Like, anything to add there as well from our our innovation center? Yeah. No. I think it's well said. I think, as you said, it's, really across the board throughout the delivery life cycle. Right? Whether you're looking at discovery, requirements, solicitation and definition, user story, having that, sort of tie, between right requirements, user stories, what gets built, what gets tested. Right? It's very helpful there for evidence. And then I think kinda rounding that out right as as was mentioned previously. Right? Keeping the human in the loop on that process because we all know with quote to cash, product to cash, these revenue management processes, there's a very heavy domain, kind of aspect knowledge to it. It's very important. Some like to call that taste, within AI. Right? And so it's very important to keep that human in the loop as part of this process to make sure you're making, like, the right sound decisions along the way. Yeah. Makes also lot of sense. to add one more thing here. So since revenue cloud has built API first, it becomes much more easier for agents to not only help on the sales side of things, but also during the build and deployment. Right? We have, one of my colleagues have released, something called revenue cloud foundation in the git repository. It is available publicly, which can be used during the implementation, like partners like, Argono are using that in their implementations to accelerate those implementations to bring down. I mean, typically we have seen CPQ implementations are known to take longer than many other implementations. But these are now changing. Like, you know, if we we are starting to see customers implementing half the time, compared to what they were doing earlier. So things are changing fast and, great. Yeah. That's... I'll just quickly... Yeah. Yeah. That's... I'm really glad you brought that up. We've been adopting, that Salesforce revenue cloud foundations as a public GitHub repo with, I mean, it's it's a treasure trove of skills and tools for accelerating revenue cloud, projects and implementations, testing across the board. So, yeah, highly recommend it. I'm glad you brought that up, Muthu. Revenue Cloud Foundations. There you go. Love it. This one, I think, is about the, the CPQ retirement timeline. It says, I've heard that you're only allowed to renew the license once for CPQ, and then you can't prolong it anymore. Is that correct? I would say, your Salesforce account team is the best person to talk about it. I don't want to, because it, it can be unique based on what edition you have, whatnot. Right? So I would recommend talking to your Salesforce account team. Yeah. Makes sense. Makes sense. Okay. We we have one last question here. So what are the biggest... Great question. What are the biggest gotchas when map... When mapping active legacy CPQ subscriptions and amendments into the new revenue engine? I can take a stab at it, but I'm sure Blake and Colin have more compared to, like, because they are so closer to implementations. Yeah. First one is about, like, you know, thinking about whether you are doing apples to apples. For example, it's... It really starts from the product catalog. Right? If you are... Actually, if you have transformed the product catalog, that used to be 10 SKUs in, in CPQ world to just one SKU with different attributes in the revenue cloud world. So then that propagates to quote and all the way to add, at subscriptions as well. Right? So that is, that is one of the decision factors. They took care. Am I transforming just the product catalog or what are the downstream implications around that? So you have to be, on top of all that. And then the second part of it is actually, when coming to this data migration, like subscriptions and contracts, don't think of it as like last minute item. I think Blake brought it up in the lessons learned as well. Like, in terms of not to bring it up as part of, you know, just before testing or just before, some milestone, you have to give its due, diligence in terms of enough, time to evaluate what you are moving and give, the the data migration the time it deserves. Those are two things I would say. Yeah. Just to add to that, two, I would say one big gotcha is to deliberately answer what is your source of truth for contracts and subscriptions. It may just be Salesforce CPQ. It may be an ERP and other ERPs and systems depending on the product line. Right? And so if it could be multiple systems depending on product and those... And the data can be different and disagree between those systems, that's where, in our experience, it becomes challenging. Right? Because you could think, hey. It's Salesforce CPQ, source of truth. You can mechanically migrate. Like, that is... I'll I'll kinda to quote the earlier phrase. Right? That's knowable, tractable work that can be done, and Salesforce is also releasing more tooling, to be able to do that, right, efficiently and predictably. It's when there's multiple systems of record. The data doesn't agree. It's hard to understand, like, what is this actual subscription. It's getting billed that has to be correct. Right? So it's sorting that out, and that's where it goes to having a plan for data migration that includes business validation, right, as a true work stream throughout the project that isn't just, settled on at the end. I'd I'd add that as well. Yeah. Perfect. Perfect. There's there's a lot going on. You guys make it sound so simple, but I'm sure there's still a lot more questions, that everybody has. If you do have further questions, we are out of time. I'm just going to let you know. In the chat, you can see that my colleague Simon has posted a link. Go to argonaut.com slash contact to get in touch with the team. If you do have further questions, I'm sure they'd be more than happy to help out. And, team, thank you so much for this, for this really insightful session. This has been, very, very practical. I know there's been a lot of good, takeaways as well, a lot of good engagement in the chat. So everybody's been, learning a lot. So, yeah, thank you for your time. Thank you for everybody who came along, and have a fantastic rest of your day. We'll catch you next time. Thank you all. Thank you all.