Hello and welcome back to The RevOps Show! I know we keep talking about it, but if you’re watching the recording, you’ll recognize we’ve been bouncing back and forth from the new studio to the old one. Soon we’ll be fully in our new studio thanks to our good friends at ohyay.
Getting into the actual focus of today’s episode, Doug and Jess are discussing the do’s and don'ts of data migration. Buckle up for this one because there’s a lot to discuss and a lot of opinions.
Audio:
Video:
Additional Resources:
Show Notes:
When it comes to migrating data, Doug’s simple solution to the mistakes involved is to just not migrate. Just don’t migrate. (If it were that simple we wouldn’t have a need for this podcast episode.) Instead he changes to say that you can migrate, just don’t check on it because that is what causes the migration to fail.
Let’s take a step back before we get into it because two things tend to get conflated. If we’re talking about a migration, we are talking about migrating data from one system to another system, from an old system to a new system for the purposes of retiring the old system and utilizing the new system. Data cleanup is often a piece of that, but data protocols can apply whether you’re changing systems or not. So this is all in relation to changing to a new system.
What is clean data?
From Jess, clean data is the up to date data, data that is filled in fully and formatted properly. Doug would call this data protocol and he believes that this is a step, but not the entire thing.
Doug goes back to the prime directive which is that the business process needs to drive the technology. The business process needs to drive the data and the protocols, not the other way around. His question then is what system are you changing from and what system are you going to use? What’s the business reason for change? As you go through property mapping or field mapping, to some degree you’re going to clean your data by going through the protocols. Don’t measure your database by its lack of hygiene, measure it by its hygiene.
What’s the difference between bad data vs. clean data?
Bad data is wrong data. When we talk about clean data you have to prioritize what cleanliness is. For example there are records and then there are the field properties within the record. So, Jim Smith is at ABC Co, but the email address is wrong. So the email is bad. The name could be spelled wrong. Again the record is good data, but the information in the record is bad. If you’re bringing over a big database, go through an email verification and quarantine those records. Decide how much energy you want to put towards reviewing them that way you have a plan for getting more correct data in your database.
We talked in the last episode about the Adoption Flywheel. You really want to look at the data integrity as a piece of that. This whole effort that people go through to clean data in the sense of getting rid of it can make sense if there’s a reason for it. Who cares if all the data is accurate or not unless the contact is active in a cycle. If they are active in a cycle then that should be monitored through a management process, but ultimately who cares?
Is it better to migrate all of the data or is it better to migrate subsets of data?
If there is clear criteria of what Doug calls dead data, then you shouldn’t migrate that over. If you have a lot of work to do in terms of what you need and don’t need, then migrate it. If you’re spending a lot of time trying to sort through what you want and don’t want, that’s not time well spent. There’s a sales phrase that time kills all deals. Similarly, time kills all implementations. Momentum is crucial to a successful implementation.
What is the best way to migrate?
The best way is an automated integration where the two systems are connected, they’re mapped and you get a full pull of data. That doesn’t mean it’s actually the best in each situation, though. The best way is the way that gets the critical data in the fastest.
Also make sure you’re communicating what you’re bringing over and what you’re not bringing over. That’s a piece that gets missed.
What are some of the things that you notice are obvious after the fact that you don’t think people realize or account for?
Doug believes there is an obsession about old data. People make it more complicated than it needs to be. The other thing that Doug thinks is the single most important exercise that gets undervalued is field mapping.
Jess agrees on the property/field mapping piece. For her she says that a mistake people make in the process is that they are only looking at it from the lens of moving data from one system and the property map influences far more than that. People need to use the mapping to think about how they are going to use the system, the key items people will need to see, etc.
The whole reason you’re moving over to a new system isn’t because you want to clean your data. You want to get to the new system because it’s going to change a lot of things. If you’re using the change as a means to improve your data that’s a really hard thing to do.
If you’re not changing your CRM, but you have process issues, fix those first. Get that moving in the right place and that will drive the help and support to move on to your data.
Next Steps:
-
Follow Jess, Doug & Imagine on socials for updates on the show or other insights:
-
Doug Davidoff: Twitter - @dougdavidoff | LinkedIn
-
Jess Cardenas: Twitter - @JessDCardenas | LinkedIn
-
Imagine Business Development: Twitter - @DemandCreator | LinkedIn
-
-
Subscribe to the show on Spotify & Apple Podcasts
-
Check out Let's Play RevOps on Twitch for more commentary on this topic
-
Listen to the next episode: The Importance of Single Source of Truth (And How You Can Have More Than One)