Request Assessment
August 9, 2021

How to Plan for a Migration

Prior to starting any migration project, you need to know why you’re making the change. Some people feel like once they reach a certain growth stage they need to switch up their tech stack. While that can be a good reason if your software can’t support your scaling, a migration is a resource-intensive technical process that can create problems for your business because you’re going to have to learn a new software. So, there is a bit of a “If it’s not broke don’t fix it” mentality.

If you need a platform that can better support a larger team of users, your current system is antiquated and can’t accomplish everything your business needs it to or you want specialized advanced functionality, those are all good reasons to migrate to a new software. Knowing those reasons in advance can also help you ensure the migration process sets you up for success.

How to Plan for a Migration

Determine what core processes of your business are vital to your migration

Think through your “nice to have” and “need to have” capabilities.

What’s part of live campaigns? What has historical data? What do you need so your team can use the new system fully from day one? What can be built later? What integrations need to be accounted for?

Time is money, so you really only want to transfer over essential assets. You could have years worth of assets existing within your platform, but if those assets don’t have important data attached and aren’t used anymore, it might not be worth transferring over or recreating in your new software.

Migrations can be a great opportunity to do data cleanup and leave behind some of the excess information and assets that have amassed in your old platform.

​​Whether you are asking an agency for help or managing the process yourself, you will need to be very literal with what is or isn't included in the migration.

It's best to start thinking on the process by pulling together a spreadsheet where you can link to assets and confirm what items will be moved over and how.

Understand how automation and systems in your current platform translate 

Some things system to system are going to be slightly different and some functionality might be unique to just one platform. You need to understand what functionality can be replicated in the new platform and what can’t.

For example, Pardot has two systems for lead qualification, one for grading and one for scoring. HubSpot only has one default lead score property. In order to get a similar functionality as Pardot, you’d need to make a custom property to represent the second score. So, it’s possible, but requires extra work and won’t be exactly the same.

Leverage this free checklist to start aligning your marketing, sales and  service operations.

On the other hand, if you were migrating off of HubSpot to Pardot, you’d be losing some of the visibility into the entirety of the buyer’s journey that you gain by having your marketing automation platform, CRM, website and sales enablement tool be the same platform. You can replicate some of the data exchange through integrations, but it won’t be as seamless.

Identify what you want to specifically pass over to the new system

Depending on what type of system you’re migrating, the specific assets and data that will need to transfer will vary. For a CRM, it can include contacts, companies and deals. For a marketing automation platform, it can be automation, email templates, advertising campaigns, etc. 

Within those broader categories, you still might not want to transfer everything into the new system. If you have 100 thousand contacts but have only engaged with 30 thousand in the past year, you might not want to import all one hundred thousand.

Similarly with assets, if you have 12 email templates but only use three, it might not be worth trying to transfer over or recreate all of them in the new platform. 

Know your timeline

When is the end date of your current software contract? You’re going to want some overlap between the two platforms so that you have time to transfer assets and information from your old software into your new one and QA.

We recommend giving yourself at least a one-month buffer period between what the estimated completion date for your migration is and when your old contract actually ends, that way you can identify errors or information you need and forgot to account for while you still have access to both systems.

The migration process itself takes on average one to two months, though the specifics of the platforms and the scope of what’s being transferred can impact that, so if you’re hiring a partner to help you with the project, you should start about four months before your current contract ends so you also have time to go through the sales process.

The Takeaway

In order to make your migration process as seamless as possible, you need to understand why you’re migrating, understand what the most essential automations are and how they’re capable in other systems and identify what specifically needs to be moved into your new platform.

It’s also important to make sure you have a clear understanding of what can’t be moved. For example, if you’re migrating between HubSpot and Salesforce, contact attachments (like tracked emails) might not always be able to be transferred over. So that’s something you’d need to be aware of at the start of the project.

Finally, keep in mind that your new system will not be identical to your old one. So, make sure you’re able to speak to what the differences are so you can enable your team to get everything they need from your new platform.

New call-to-action

Wyatt Borchetta-Platt

Wyatt is a Revenue Operation Specialist at New Breed. He works to implement Marketing and Sales automation to align both departments with a strategy for combined success.


Ready to jumpstart your acquisition, retention and expansion efforts?

Request Assessment