One of the most challenging parts about a CRM migration are the integrations, okay, the tech stack that is involved with it. So what we're gonna get into in this episode is where we talk about how these tech stacks are intertwined and what to look out for when you're doing a migration. So on top of integrations, they're involved with two other key variables. So imagine you're moving from a Salesforce software, a CRM like Salesforce, into a better software like HubSpot. And there's three variables. We've talked about data already. Integrations is this tech stack, and processes are the user stories and the day by day actions that your team does. But we're gonna dive into integrations here. And for all of this, when you're thinking of any type of migration, you always wanna think about go live because that is what you reverse engineer from. This is how we think of it at RP, an elite HubSpot partner, but there's a lot of different frameworks that go with it, but let's get into it. So at the top section, you have processes going through at this section, and we'll get into that in more detail, but you can see how many different ones are intertwined and how it's related to integrations. Data is always a part of this, but in terms of integration, you think of this integration as like the software piece of making sure all the technicalities work. But you really wanna think about the process that the end user uses on the software side. You have to think about the individual process that comes with it and each integration. K. This is why I want it it can really snowball. You have a very complex tech stack intertwined into a CRM because you have to think about the go live date with all of them and timing it all right, setting it all up to them when you flip it on for the go live. You have this as seamless transition as you can. So what are integrations? What are examples of this? On the left hand side are two examples of what you could do for a CPQ process, AKA your quoting to closing deals process. We love PandaDocs in particular, uh, but you can also use a DocuSign, Dropbox sign, lots of different options in today's world. And then from in the middle, you think of this as more like how you gather data and aggregate it across different platforms. We're a big play advocate. ZoomInfo is another example you might recognize. But this also includes if you're doing the HubSpot to Salesforce integration. Sometimes you wanna keep Salesforce and HubSpot as their own standalone softwares, and there's an integration that allows for that. And even if you're migrating from a Salesforce into a HubSpot, you can use the integration as a tool for it. We have built a playbook just for that because it's very intertwined and it's helpful. It's actually one of the best ways to migrate the data for it. So what does this look like? So we're gonna go top down on this. There's three variables you want I want you to think of, and you might notice this if you've been watching from the data slides, is you have the integration migrations. We're having Salesforce to HubSpot. If we're thinking about that, we wanna think of, yes, the objects that are in place. So you can, in that integration, migrate, uh, or in intertwine opportunities and deals. And then within the fields, within that, you have your opportunity and your opportunity type and your deal name and deal type, and you wanna make those match from different types. So we got into this. What I'm gonna call out here is when you're looking at this integration and when you're talking about these, is you might have different processes from when you're updating the deal data to deal stages to sending a quote. Sending a quote, I put stars here because that involves an integration. So you wanna look at what this process is. What are the daily actions of the users who do it? What is the different data that's involved in it? Because that will affect how the integration, uh, hands out. So what is the overall, like, schedule events of how the integration goes? So this is on a per integration, but, generally, yeah, you wanna uncover the essential integrations. You might have 10 integrations, but how many of them are essential? Essential being to close business and to keep the business operating as, like, moving. First, maybe some nice to have ones for specific data reporting that you want. You really wanna lean into what is essential scope creep very easily. And so you wanna see what type of data they'll be using. Then the build section is for each integration. You wanna set up the integration. K. Think of the different data, the API calls really get into the process of what that looks like. Measure can be a kind of a complicated one here with integrations because of how they work, right? Like in terms of you might not be able to use the integration in its daily process in multiple different CRMs. A lot of them have, like, restrictions of you can only have this integration tied to this one to one other software at a time. You can only be connected to Salesforce or HubSpot. There's different ways to play with it, and I'll get into that right after here. Delivery is this cutover period of brightness up every time because it's the hardest and most essential part is that there's this, like, moment of truth. There's this, we're migrating things over. People have to move from their daily thing in one software into another one. And so it's especially important with integrations if you can only be tied to one system. That cutover period is so, so critical. And adoption is really stress testing that integration. And because you might do some initial testing, maybe you have limited options with testing given the integration, you have to really lean into right after you do this. You're stress testing this as much as possible to mitigate interruptions in daily flow. So things to note is calling out that exact thing. You can't test all integrations. On some integrations, you can only have connected to one portal and instance. So you generally have three decisions. One is you reduce functionality for your team to give yourself some time to test some stuff, or you put additional tests on this QA cutover period when you're like, all right, well, we're not gonna test it. I think I got it set up, but we'll find out a way to mitigate this is setting up an additional account to test and confirm things. So this works well for three medium products. Sometimes they limit access to APIs and integrations through it, but generally not because they want you to get intertwined in the softwares. So then they allow that's probably been my best advice of how to do it. The other one in is to ask for help, is work with your integration partner. They want you to keep using your software even if you're moving from one CRM to another. They wanna help. So reach out to them around specific requirements. If they've done this type of integration, look up for that specific documentation. Another one is I'll give a shout out to what we do at RP is work with someone who's done this before. We've done hundreds of migrations at this point, and we've worked through some of those nuances. But even if you don't and maybe a very specific migration that you're working with integrations. Maybe there's a different service provider who's worked with your specific tech stack to help you get there. Because this is one of the hardest part and can really interrupt daily flow given the the stresses that come with the additional stress of QA that you can't do at all the QA right away. Unclear timelines for cutover dates. So, basically, if you don't have clear timelines and understand the order of operations, this is where headaches come in to be. You forget that there's a process tied with your DocuSign integration. That is what can really account for some of the biggest headaches where you're like, wait, we can't migrate. Wait, I thought go live date was this. Wait, we totally forgot about this integration or we haven't tested it at another month or two. Like that's what we're really trying to avoid. So you wanna really understand what those essential integrations are. And last call out I wanna do is your tech stack might change. Certain integrations are really built for certain CRMs. Uh, for example, I've worked with a partner where their tech stack was very built for a Salesforce and the integrations worked really great in Salesforce. But when we tried to do those in HubSpot, they didn't have the same ones. And we had recommendations for different integrations that worked even better with HubSpot. You just have to understand you have to be open to maybe a tech stack changes, and maybe you can get rid of an integration that you had. Maybe you were using a a DocuSign to do your coding process, and then you realize, well, wait, HubSpot's native quoting process is more than sufficient and it reduces our costs by X dollars. So just call out of your tech stack might change and just being open to that change for it. So in summary, integrations are your tech stack, how they intertwine. There's ways to mitigate the risk, but it is essentially a really hard one because they're very intertwined with processes, AKA the thing we'll talk about next. Till next time team. Peace.