Recently, I got involved in our company’s Salesforce data migration process. We were migrating from an old CRM. It wasn’t until we (successfully) made it that I realized the biggest problem of these migrations is… well, the users.
As you’d expect, the project wasn’t about simply taking the original data and moving it to the new system. There were hurdles here and there, and I blame the users.
Of course, I am joking. To be honest, I am to blame too. I am one of them. Even more, anyone who implements a CRM system is to blame. I am, again, guilty there too.
The problem with CRMs is that they evolve over time. Yet, their evolution isn’t perfect. I bet there are only very few (if any) organizations that would meticulously clean up their data after every single change to their processes.
"From now on, we shall stop using Description field for tracking details about your appointments and you will store these as Tasks."
"We’re simplifying Opportunity life cycle stages."
"From now on, we’re introducing a custom picklist for this and that."
How many times do you hear that during the lifespan of a system? It’s natural. The processes get more refined and complicated as people mature and gradually adopt the benefits of properly using a CRM. That’s good.
However, traces of all that “history” silently build up in the data along the way. With each customization, it racks up scars and bruises.
And then, it’s on you. You’re faced with setting up a shiny new Salesforce instance with new, even more refined and more complex processes. It would be a real luxury if you also didn’t have to somehow translate the old data to match the new setup, right?
Here are a few things that I found useful. Don't expect technical details. In the end, the success of projects like these lies in the people (argh, the users again).
Before we begin: What is data migration in salesforce?
A Salesforce data migration can be defined as the process of moving Salesforce-specific data to other platforms where required. The migration is an opportunity to cleanse the data, and should keep in mind the key factors involved in a data migration.
These include:
- Complete: All necessary details should be contained for all users
- Relevant: What the information needs should be included
- Accuracy: Details contained should be accurate
- Timeliness: Data should be available when you need it
- Accessibility: Data should be accessible whenever we need it
- Validity: Correct format required
- Reliability: Data should contain authentic information
- Uniqueness: No record duplicates should exist
A data migration process requires patience and proper care to migrate heavy amounts of Salesforce data. Here are a few things to keep in mind.
Things to Keep in Mind in a Salesforce Data Migration
Discovery First
Find out what is actually in the CRM. That’s a must, otherwise you would be causing more trouble than good. Listening to people who use the system every day is a good start but surprisingly not sufficient. Even after days of interviews I guarantee you won’t have the full picture.
You will really have to go into the data. Ideally use some sort of data profiling tool that scans the entire data set and gives you a complete insight into the shape and health of the data. Finding truly everything is crucial here. People forget how things were before and it’s your job to identify all the discrepancies - evidence of how a piece of information moved from field to field, how picklists evolved and what fields are or aren’t used contrary to users’ beliefs.
Trust and Education
The former point largely influences how users and stakeholders trust you. Every mistake and omission you make will have a profound psychological effect that you must avoid. If you forget an obvious thing, how can they trust you with the hard stuff? They are not only relying on you to not make mistakes. They are mainly relying on you to discover and fix theirs.
You’ll need to be able to relay the full story the data is telling back to them. Educate them about their own data. Come up with a data migration plan. Create sample data sets, produce aggregates showing what’s important and what’s obsolete. I found myself running simple reconciliations quite often (basically checking unique value counts and finding rare outliers), showing to the group and eliminating most of them.
Data Model
Creating and maintaining a data model is tricky, isn’t it? It gets influenced by both new processes and also legacy data and the need to match those two things together.
I’m a big fan of having a data model but I’m not a fan of presenting it. Why? Presenting it is hard. To get users truly engaged and to get them thinking about fields, types, forms of interactions, validations, etc. is hard. They’re most likely not technical. So you're best showing them real page layouts. Let them play with it with their own data and only then will they come up with valuable suggestions.
Your ability to quickly remap fields and change how they’re presented will greatly increase your chances of finishing with something they’ll be happy with for a long time.
It’s great to keep mappings and definitions in a form that you can easily use in different places. You can set up Excel spreadsheets to both show and discuss fields and values with the users, as well as have the very same definitions being used by actual data loading process. Think about making changes on the fly when you’re sitting with the customer and then feeding the same definition document into some automated process, all objects and all fields at once! They can immediately see what you’re talking about.
That leads me to the biggest point.
Deliveries? Always complete!
You’ll only get meaningful feedback when you present things to people as “complete and done”. Period.
Let’s say your plan is to migrate Accounts first, then Opportunities. You tell the stakeholders to review and sign off Accounts before you all move on to the next step. This looks good on paper and people will agree to it in meetings. During the review people will be nodding and you’ll hear them saying things like “Looks good, John. Right?” - What actually is happening is that they either don’t care (yet), or you’ve lost them, or they’re simply waiting.
Eventually, they will wake up only when the entire thing comes together.
Suddenly it’s real, they’re back in their known universe. Reviewing work mid-process takes too much discipline, thinking and dedication - luxuries hard to find in their busy daily lives. Reviewing something complete is much more laid back - it’s real and often familiar and encourages people to freely poke around when they have spare time. Like hanging around a new house, trying out things, expressing your liking or distaste. Compare that to the burden of having to inspect a construction site! And your users will feel more comfortable being real people than being alert as investors.
Watch the webinar: Surviving a Data MigrationTherefore, you can bring a lot more value if you’re able to demonstrate the whole setup, with all the relationships, links, objects and dependencies in place from early beginning. Sounds silly? Well, think of it as presenting a blurry picture at first. It has everything in it, only with rough edges. Then with each iteration you bring parts of the picture to focus until everything is straightened out and crisp.
No slides, no Excels - just dump all you can into the test instance and let them play with it. You’ll be surprised how quickly you’ll get valuable feedback. You might see a parallel with agile development - you always thrive to deliver the full picture so that people can see the dots always connected.
Obviously, doing so manually with every single iteration is not feasible. Just like with agile development, the capable tools can help you orchestrate individual steps and automate repeating the process.
Even though a data migration is a “one time” thing you’ll actually get the final sign off much quicker if you’re able to repeat it often. You’ll be able to collect valuable feedback and incorporate suggestions and corrections faster with more engagement from users.
Automating deliveries will save time that you can spend talking to people instead. You won’t have to be so stringent with UATs and anxious about late change requests. If something pops up, just fix it and re-run the thing once again, with new data and quickly.
Final Thoughts
Sales, marketing and support people won’t feel easy about new CRM or migration projects. They might struggle to grasp what’s going on behind the curtain during implementation and feel put off by it.
Making it as accessible and transparent as possible, allowing them to work in a familiar environment and see work “always done” will help them communicate with you more efficiently. You’ll be able to turn around changes quickly and show them their feedback matters by quickly incorporating it into the real system.
Many of these things are about embracing best practises and facilitating communication between different people. That’s on you and your best judgement.
However, there is also a technological aspect that can support you in efforts to make it real. Our CloverDX team is doing its best to deliver a platform that enables you to remove much of the manual repetitive work and automate it instead.