In the IT world, few phrases put a damper on a conversation as effectively as “CRM Data Migration”.
These innocuous words all too often cause even the most hardened and seasoned IT professionals to break out in a sweat and rapidly change the subject to something else.
Or, perhaps even more unhelpfully for those that have never been involved in a CRM migration before, a colleague may pull a grimaced expression on hearing those words, then swiftly exit stage left with an ominous “good luck!”. But why is this the case, and is fear of data migration justified?
CRM data migration is perceived as scary because it often catches people out.
Many can see it simply as a case of moving data from A to B, which essentially it is. However, the preparation required to achieve a smooth migration is often underestimated, and data is not forgiving.
There isn’t much room for error – the migrated data is either correct or not.
The ever-increasing volumes of data that need to be migrated don’t make the task any easier. Also, the regulatory responsibilities placed on administrators by GDPR only adds to the pressure.
A further challenge is that there are often many unknowns. Your data may appear one way in the user interface, but behind the scenes, in the underlying database from which the migration will read the data, the data can be stored and even named entirely differently.
In the UI, an “Account” form may suggest the data is from one underlying table, but it could be a composite of many different tables. And a field with a friendly UI display name, such as “Territory”, may have a database schema name that is different and obscure, such as “UD_Text1”!
So, one of the first tasks is to identify which fields you need to migrate from the UI. Then ascertain and document where these are located in the database. Often clients are not in a position to do this alone, especially if the system is bespoke, old or both.
The analysis must be a team effort. The Client, is the Data Owner, responsible for clarifying what the data is, what needs to be migrated and how it links together in the UI. The IT partner provides support to translate that to the database.
4 Pillars of CRM Data Migration.
Due to the variations in the source and target systems – and the types and quantities of data to be migrated – each data migration can feel like a first.
But rather than focusing on the differences, it is more constructive to focus on the constants. What factors or steps will always be the same? This approach can lead to quicker progress and help break the project into manageable tasks.
1. Access The Data
A seemingly obvious requirement, which often causes delay, is that analysing and migrating data requires access to it.
Whether your data is in a spreadsheet, an on-premise database or cloud-based system, an IT partner will need read-only access. Allow sufficient time to provision the appropriate credentials, VPN access etc.
2. What Data to Take
As the data owner, only you can determine what data is needed for your business. This includes determining what data can legitimately and legally be retained and what, if any, can safely be left behind in the legacy system.
The earlier internal conversations can be had to prepare answers for these questions, the better.
Also, striving for a “minimum viable” dataset nearly always yields the most successful migrations. It is too easy to say “take it all”, often through fear of leaving anything useful behind.
Your data migration is a prime opportunity to “clean house” and populate your target system with only the best and most useful data that follows the principles of your data retention policies.
What’s that, you haven’t formalised data retention policies, yet?
This is the perfect opportunity to do so. Not only to ensure your new CRM is populated appropriately but also so that measures can be put in place to keep the data compliant.
3. Where To Find It
Having determined what data is required, the next task is to identify where to find it.
This could be columns in a spreadsheet or fields on the source system. For the latter, initially identify and document where the required data can be located in the front end. Assistance may then be required to map out where the data is behind the scenes in the underlying database.
4. Where To Put It
The final piece of the puzzle is to identify, in the target system, where all the data needs to go.
Most data might be migrated 1:1, but some entities may need to be split or merged, some option-set values changed or re-mapped. Possibly, some data may need transforming or cleaned. For example, capitalising the first letter of name fields or removing any text from phone numbers.
With these four elements completed, it should be possible to build a “Mapping Schema”. This will identify exactly:
- What data needs to be migrated,
- Where from,
- Where it needs to be put
- If (and how) it needs to be transformed
This is the formula for successful data migration and the key to a process that doesn’t need to be feared!