In this video, Salesforce Consultant Scott Moreira highlights the 4 mistakes he sees RevOps teams making when migrating CRMs from HubSpot to Salesforce.

The major areas where Scott sees teams run into problems during migrations are:

• Project Scoping
• Data Cleaning
• Change Management and Training Plans
• Failure to Account for Issues that may Impact your Deployment Window

Read more from the CloudKettle team on when it might be time to move to Salesforce.

Transcript:

Hi there! My name is Scott Moreira. I’m a Salesforce consultant here for CloudKettle in Toronto, Ontario, and today I want to talk about four common mistakes that I see RevOps teams make as they migrate from HubSpot over into Salesforce.

Now this is a very standard migration, sort of a right of passage for a lot of SaaS SMB teams, so it doesn’t need to be overly complicated. But there is a lot of legwork you can do early on to save yourself a lot of time later in the process.

Now these four mistakes are:

• Failing to accurately scope your project
• Not thoroughly cleaning your data,
• Not having a detailed change management and training plan, and
• Failing to account for factors which could affect your deployment window.

Now the first of those – Project Scoping – is simply: what do we want Salesforce and HubSpot to look like post migration.

Whether you’re keeping HubSpot around as a marketing platform, or completely throwing it out after the migration. This also means determining who is moving into Salesforce, whether it be a subset of the sales teams or whether it be all of sales, CS, support, business intelligence, etc.

Next is: what are our Integrations doing? If we have something like ZoomInfo enriching our information in HubSpot today, is that going to continue to enrich HubSpot and then pass through to Salesforce via the integration? Or just cut HubSpot out entirely and go directly from ZoomInfo into Salesforce. Be sure to check with your integration providers about this, about what they’re able to do, and on what timeline and budget. And lastly, what automations do we need? Of the things that sales teams are using, what is a standard feature in Salesforce, things like the opportunity forecast category moving when the stage changes, and then, what will we need to buy or build? Something to buy might include Lead to Account matching from LeanData, whereas something like a flow or assignment rules or Apex classes you’ll need to build in-house.

Lastly,  when it comes to migrating data, what objects are we migrating? Four common objects to migrate are: Companies, Deals, Contacts, and Tickets. Of those objects, which records do we care to migrate? Sure we might want Deals, but do we care the for a deal that was “Closed-Lost” over eight years ago? And once we’ve moved those records over, which records are we syncing between HubSpot and Salesforce? (Again, if we’re keeping HubSpot around.)

Companies and Accounts should probably be synced, as should Contacts > Contacts or Contacts > Leads, but Deals and Opportunities probably don’t need to be, as once HubSpot has been deprecated as a sales CRM, we no longer care about having sales records like Deals in HubSpot. You also need to consider that contacts in HubSpot can be either Salesforce Contacts or Salesforce Leads, the difference being that effectively a Lead is a combination of a Contact, Company and a Deal record for a record that hasn’t been qualified by an SDR yet.

Now Leads may or may not be good for your organization, but if you are choosing to use Leads, you should decide on what qualifies something that is in HubSpot today as a Contact to be migrated as a Lead into Salesforce versus a Contact in HubSpot that should be migrated as a Contact into Salesforce. A common rule of thumb that we recommend is whether or not that HubSpot contact has ever been related to an Opportunity.

If it has – it should probably be migrated as a Contact.
If it has not – it probably can be migrated as a Lead.

But regardless of whatever you decide on this, you and all of your internal stakeholders will need to get on the same page.

Now the second mistake is failure to properly clean data. The most important factor of this is duplicate contacts and companies. HubSpot has that “manage duplicates” button, but that button goes away when you install the Salesforce integration in HubSpot, and when you connect it to the Salesforce instance. This means you want to get started now, and thoroughly clean all of these duplicates by the time that you activate that integration. But that’s only the first step, there’s also blank properties in HubSpot records – like a contact missing an email field, Orphan contacts – so any contact that does not have a related company relationship in HubSpot, and Contacts with multiple Company relationships.

In most instances of Salesforce, a Contact should only have one Account relationship. So if you have Contacts in HubSpot today with multiple Company relationships, you either need to delete those excess relationships, or speak to your implementation partner and determine a plan for how you’re going to manage those excess relationships.

The third priority is change management and training.

Now, I know that that subject elicits a lot of eye rolls from RevOps teams that may not have or necessarily believe in a super sophisticated and detailed change management and training plan. And while it doesn’t need to be overkill, it’s important to recognize that part of moving from HubSpot to Salesforce is partly maturing as a RevOps organization, and part of that maturity is having these documented processes so that regardless of who moves or leaves the company, or who needs to be held accountable to abide by the rules and the common practices of the organization, you have that in writing.

Now, important change management questions include:

• How are we gathering feedback from teams?
• Who on the RevOps teams approves new features and projects get built?
• Where do our developers and administrators build these new projects? (Whether we’re working in vs code and sandbox we have built for additions)
• And when and how do new releases get deployed?
• Are we deploying quarterly, bi-weekly, monthly?
• What’s our level of flexibility and comfort with these changes?
• For training questions – How are we training our users?
• Who is our liaison to end users?
• Are we going through a sales enablement team or simply speaking directly to sales managers?
• Where do we communicate changes to teams? whether it be Slack, Teams, email, video conferences, etc.
• And the last priority – the most important and expensive one is how do we identify absolutely anything that can affect our deployment.

This is the big one that’s going to cost you a lot of money if you get it wrong, because if you have to pay for duplicate environments, duplicate licenses, duplicate integrations, excess users, it’s going to take chunks out of your budget.

So understanding when is our HubSpot license expiring, when are our integration licenses expiring? And when are integration Partners going to allow us to move to a new environment? When’s the beginning and end of our fiscal period? Do we have an SKO or a company-wide event? Do we have vacation plans for critical team members? Are there stat holidays we need to be aware of? Busy selling seasons we need to account for?
Are our HubSpot administrators ready to become Salesforce administrators? Are our third-party Consultants able to work on timelines that match our expectations?

It’s important to ask these questions internally and early on and make sure that you forecast as accurately as possible when you want to flip HubSpot off and turn Salesforce on.

So again, in summary, the big pictures are, the big priorities are, accurately scoping your Salesforce project, thoroughly cleaning your data,
having a detailed change management and training plan, and accounting for any and all factors that can affect your deployment window.

Thanks for watching. My name is Scott Moreira. Again, feel free to connect with me on LinkedIn if you have any more questions and best of luck.