Your CRM can either be a roadblock impeding your go-to-market team, or an engine that accelerates their efforts. While good systems can help identify high-value opportunities and reduce time-to-close, a poor system will have users spending time on manual busywork rather than on generating and closing opportunities.
For most startups, the two major CRM options are HubSpot and Salesforce. Though both have their own strengths, the typical path is for companies to start by using HubSpot Sales Hub, and migrate to Salesforce Sales Cloud when HubSpot can no longer support their growth requirements. For more information on how to decide if your company is ready to migrate from HubSpot to Salesforce, check out our article ‘Migrating from Hubspot to Salesforce’.
In this article we’ll discuss everything you need to know as a RevOps leader once you’ve decided it’s time to migrate to Salesforce. We’ll go over the differences between the systems, the stages of a migration, and post-migration plans.
Differences Between Salesforce and HubSpot
Though there are plenty of differences in features between Salesforce and HubSpot, the one most likely to cause confusion during a migration is Salesforce’s use of the Lead object.
HubSpot has recently announced the addition of Leads to their Sales Hub, but for many migrating to Salesforce the Lead object is confusing at first. Inversely, those who have only ever used Salesforce are bewildered as to how a HubSpot can function without the Lead object. Clashes between these two schools of thought make for some entertaining LinkedIn drama, but for the sake of brevity this article will simply describe what Leads are, and decisions you need to make about them.
Leads are a standard Salesforce object which act as a holding stage used to validate data during the handoff between Marketing and Sales. Leads are typically worked by teams of Sales Development Representatives (SDRs) who disqualify non-workable records, improve records with missing data or context, and ultimately qualify that the Lead represents a legitimate prospect for sales. Once the Lead is qualified as a legitimate prospect, the Lead is “converted”, which means the record is transformed into an Account, a Contact, and optionally an Opportunity record. At this time the ownership of these new records is typically transferred from the SDR who qualified the Lead, to the sales rep who will be owning that sales cycle.
Now we understand roughly what a Lead is, let’s go over the decisions about Leads you need to make for your org:
Should we use leads?
If you prospect a limited number of accounts with high data integrity (for example an ABM model targeting government departments) then you may not need Leads at all. However, if you’re integrating data from a marketing tool such as HubSpot Marketing Hub, or bulk-importing from a third-party aggregator like ZoomInfo, using Leads helps isolate unqualified data and preserve the integrity of your database.
How do we route Leads?
Whether you use Leads, or opt to just use Contacts and Accounts, you’ll need a way to assign new records as they enter the system. In HubSpot a typical routing strategy is to use Workflows to create a round-robin which cycles through team members. Salesforce doesn’t come with a native round-robin function, so you’ll have to decide which option makes the most sense for your organization. You can:
- build a custom round robin in Salesforce
- leave the relevant HubSpot workflow active and have that control the ownership of Salesforce records
- buy a third party routing tool
- manually assign new leads to reps.
The best choice for you will depend on your volume of records and your budget, but the worst plan is no plan.
When does an Opportunity get created?
Finally, you should decide at what point in the new business sales process an Opportunity is created. Salesforce Opportunities are analogous to HubSpot Deals, and by default can be created at the same time that a Lead is converted into an Account and a Contact. This default option can be turned off, as some sales teams prefer the SDR to book a meeting for the AE first, after which the AE would create the Opportunity themselves. Again, the best course of action here is whatever works best for your teams.
Stages of a Migration
Now we’ve got some plans for your Salesforce environment let’s go over the steps of a migration:
1. Requirements Gathering
Before you dive in, make sure you take time to talk to your stakeholders. Ask users and managers what they need from the new system, then document the workflows, products, reports, records, integrations and objects required to make that happen. At this point it’s typical for teams to give a laundry list of changes they want made to the sales process. But keep in mind that this project is about getting you from HubSpot to Salesforce, not about redesigning your go-to-market strategy. While some changes to existing processes will be feasible or even necessary, try to keep the scope of these conversations around what teams need to complete their job, not what they want to change about the current process. You can always add new features later.
2. Data Cleaning
Moving to a new CRM is a lot like moving houses; it’s a great opportunity to lose your old junk. Search through the records you decided will be moving over to Salesforce and look for duplicate records, Contacts with either multiple Companies or no Companies, cross-object picklists with mismatched values, legacy workflows or field values, etc. Make sure all your old processes are turned off, and all the stuff you want to keep is up-to-date and clean. While Data Cleaning is especially important prior to a migration, it is a critical habit your organization should undertake periodically to ensure a well-maintained CRM.
3. Solution Design
Now you know what Salesforce needs to accommodate, it’s time to start designing your system. Go through your requirements documentation and figure out how the pieces are going to fit together. What should be built in Salesforce, what stays in HubSpot (if you’re keeping HubSpot as a marketing automation tool), and what’s a 3rd party integration? We don’t want to start the build until we’ve got a final blueprint that documents how everyone’s needs are being met and is signed off on by each team. After that, a freeze should be enforced on any additional features to prevent scope creep. If changes to HubSpot are necessary, there should be a strict change control process to document any modifications to the HubSpot environment.
4. Build
Finally, build time! A key here is to be cognizant of what Salesforce offers as default functionality so we’re not wasting time creating redundant metadata. For example, Contacts already have a Last Activity Date field, there’s no need to make another one. If you have pieces being built in different sandboxes for this project make sure everyone is on the same page about getting their work into Production before moving on to testing. If you’re planning on keeping HubSpot as a marketing tool post-migration, this is when you should install the Salesforce integration, and set up the field mapping for the Contact and Company objects.
5. Testing
Although not the most exciting part, testing is certainly one of the most important. Unit testing of each component should be done throughout the build phase, but once everything is built your QA team should do a final smoke test with detailed test logs, followed by user acceptance testing done by end users. Make sure to identify each type of user you’ll need testing from, and book time in their calendar far in advance so there are no delays.
6. Training
A lack of training can be the downfall of any new process or system – so it’s critical to book time with each team to walk through their piece of the CRM. These training sessions are for helping users understand how their piece of the system works, and for educating them on how enablement, communication, and change-management plans will support the use and administration of Salesforce. Remember, the purpose of these sessions is not to gather feedback from the team. Any change that’s not mission-critical should be postponed until after Salesforce is live.
7. Data Migration
Before you hit the big red button to port everything into the new system, be sure to run some test batches to ensure your field mappings are working as expected and no duplicates are being created in either system. Choose a subset of data (like records owned by a certain user or in a certain region) and attempt to transfer them from HubSpot to Salesforce. Common errors include missing required data, mismatched picklist values, and loading records in the wrong order. Once you’ve confirmed that your migration strategy is working, it’s time for the big lift. Depending on how you’re choosing to migrate your data you may need to enforce a lockout period between when users stop using HubSpot and when they start using Salesforce. Be sure to consult with your implementation team about this and have a plan to use another solution like Google Sheets for the hours or days in between when HubSpot stops and Salesforce starts.
8. Deployment
Mercifully, deploying a new system is not as complicated as updating an existing one. Since we moved all the metadata into production in stage 4 and all the records in stage 7, all that’s left to do is invite your users, update your integrations, and standby for potential fires. Make sure to schedule your deployment for a time when your team is available to squash bugs quickly, and avoid times like holidays, end of quarter, or Monday mornings. Be sure to consult with your sales teams and aim to launch at a time when they’re typically less busy.
Post Migration
Congratulations! You’re all settled into your new home. If everything has gone according to plan you’ll now have a fancy new CRM, full of clean data and well-documented business processes. This is likely the most hygienic your system will ever be, so do your best to maintain it with a good change management process including thorough documentation on updates, active monitoring & feedback, a comprehensive risk management strategy, executive involvement, and periodic data cleaning. You don’t want to undo all the great work you did getting this system up and running.
If you want to keep HubSpot around as a marketing automation platform, be sure to research what types of objects are recommended to sync and how. For starters, you’d want to avoid integrating the HubSpot objects Deals, Campaigns, and Tasks with their Salesforce counterparts as that can get messy. Be sure to consult with a specialist before deciding to send data back and forth.
After any launch bugs are sorted out, you can go back to your notes from requirements gathering and see if there’s a V2.0 project you can start working on. Getting onto Salesforce is only the beginning, and business unit leaders will surely be banging on your door in no time demanding new features and udpates. But don’t worry! Your new system is more flexible, cleaner, and more powerful than any tool you’ve had before, and with enough Trialheads and caffeine, you can deliver anything your company needs to reach their goals. You got this.
Are you thinking about your own migration from HubSpot to Salesforce and looking for some guidance? Get in touch! We would love to help you.
