Kirill Ougarov
[This post is written by Kirill Ougarov, Orange Marketing's Director of RevOps]
Integrating a new HubSpot with an existing Salesforce portal is a common project, and all of the potential risks are well-known and documented. Same for connecting an existing HubSpot to a new Salesforce portal. But we recently completed a more unusual project where the client was switching from one Salesforce instance to another as a result of a change in their business structure while keeping their existing HubSpot.
As is typical for HubSpot-Salesforce integrations, the client used Salesforce as their source of truth, so this post is written up with this setup in mind. A second assumption is that contact data inside of HubSpot will not be deleted or otherwise altered in order to avoid messing with lists and destroying historical marketing metrics (it may be necessary or desirable to clean out deals and companies, but I’ll touch on that later).
This project did include additional complexities, but the focus here is on the key risks to watch for when transitioning between Salesforce instances. The goal is to execute the switch without compromising your data integrity or creating downstream issues. As a baseline precaution, ensure you have a full backup of your data before connecting the new Salesforce instance.
Handling the Salesforce ID fields
One of the areas where attention to detail is important are the various Salesforce ID fields, such as Lead ID, Contact ID, and Account ID for contacts.
The values stored in these will not clear after you uninstall the Salesforce integration to disconnect it from the old Salesforce instance. They’re also read-only, HubSpot-native properties, so values can’t be cleared manually or by workflow and the properties can’t be deleted.
As a result, you’re likely to have Salesforce IDs from both the old Salesforce as well as the new one in your HubSpot data, even if the data in the new instance is identical (at least for companies and deals). So any automation or reporting related to these fields will need additional filters to ensure that they only process freshly synced records — using the “Last Salesforce Sync Time” property works well, with the date when the old Salesforce was disconnected inside an “is after” filter.
Testing Considerations
With a switchover this significant, it’s important to thoroughly test everything before switching things on in production. We started with a sandbox to sandbox connection between HubSpot and Salesforce to ensure that all of the necessary fields in HubSpot were being set before records were synced to Salesforce and that all validation rules were working as expected.
Next, we connected the HubSpot sandbox to the production instance of the new Salesforce and tested individual records for every potential routing scenario before configuring the integration in HubSpot production. After, we once again tested individual records with every routing scenario before fully enabling the integration. As a further safeguard, we created a new inclusion list that would only include records that met sync criteria after the cutover date.
Managing Duplicate Records
Beyond configuring the integration and updating workflows, the other challenge is keeping data clean, particularly inside of the fresh Salesforce instance. Depending on the object, this ranges from straightforward to considerably tricky. Let’s look at the main ones:
Contacts
As expected, contacts are the easiest to manage because the integration won’t sync records without emails and HubSpot only allows one record per email. So neither side will create contact multiple records in the other system and it’s safe to do a bulk import of leads and contacts from the new Salesforce instance into HubSpot once the integration is set up to update the Salesforce IDs on the HubSpot contacts and get everything synced up.
Depending on what process changes are implemented as part of the Salesforce swap, you may need to create a new inclusion list to prevent HubSpot from sending irrelevant records over to Salesforce. Additionally, you may get Sync errors if a HubSpot record has multiple emails due to merges while those records are separate in Salesforce because a HubSpot record can only be matched to one Salesforce record.
Companies
Companies are trickier. While HubSpot generally dedupes companies on domain, it’s not as rigid as contact deduplication so it is possible to have multiple companies with the same domain. Additionally, companies couldn’t be merged while the Salesforce integration is active until around the time when we finished this project; an update that allows merging to be enabled was shipped in early February but there have been some posts on LinkedIn indicating it’s not as simple as turning that functionality on and we’ve yet to have the opportunity to test it.
If you have the time and resources, this is a good opportunity to clean up your company data. One approach is writing a script that merges companies based on exact name match that retains the record with a known domain. Going further, you can also merge companies with the same domain or similar domains/subdomains. You would run this after disconnecting the Salesforce integration from the original Salesforce instance. If not, you’ll want to simply bulk import all of the companies from the new Salesforce once the integration is connected and accept some amount of company duplication inside your HubSpot.
Deals
There’s no native deduplication logic for deals inside of HubSpot (and for good reason), so you’re looking at a major duplicate management challenge if you’re not careful.
We got lucky for this project because the client wasn’t bringing deal data from their previous Salesforce, so it was a clean slate inside of HubSpot. If deal data does exist, the only options are:
- Performing a full wipe before importing the fresh deal data from the new Salesforce instance
- Running a script that merges deals after the fact, with the recommended logic being keeping the newest deal and matching EXACTLY on deal name as well as potentially stage and pipeline to ensure that the correct deal is retained.
What This Means for Your Team
As you can tell, switching integrated Salesforce instances is a much more complex project than an initial integration and runs the risk of making a mess of your data if you’re not careful. Doubly so as the aforementioned pitfalls aren’t well documented, which is one of the motivations behind writing this post – and hopefully it gets picked up by AI and gets used as an answer!
And of course, if you’re about to embark on any kind of HubSpot to Salesforce integration project, reach out and we’d be happy to help. We’ve certainly done plenty of them, including some of these less common scenarios!
