Typical Migration Steps
1. Cleansing (Client)
Before carrying out any data migration, we highly recommend that you carry out a data cleansing exercise to ensure that the data being migrated is accurate and of good quality. Central to a good CRM system is good quality data, and while this exercise may be time-consuming, it is extremely beneficial in the long-term. Your partner can advise at this stage, however the aim is to de-duplicate your data and ensure data integrity. Examples of this include ensuring that only numbers are recorded in a telephone field, or that there are no spelling mistakes and data hasn’t been shoehorned into the wrong fields (e.g. company employee count is held in the phone field because the previous system had no Employee Number field).
It may be that you need to consider a way to standardise data input (for example, phone numbers all begin 01… or +44…) By carrying out this activity, not only does it mean that you begin with a new system that has accurate data and with the best start possible, it also reduces potential costs that could arise during the migration exercise from incorrect or poor data causing migration issues – or even inaccurate results and reporting when being used.
Before migrating your data, we will determine the scope of the data being migrated to outline exactly what does and does not need to be migrated to the new system. It may be that all data is to be moved, however if not all data is required, than we would work together to define a tight scope. Making a tighter data scope reduces your CRM storage, which can add up over time so only migrating the data you need will save you costs in the long-term. Again, your partner should work with you to recommend cost-effective storage methods that suit your requirements. For example, you could migrate core data to the new system but then archive older data to a much more cost-effective solution (such as Azure), so that you keep the data but pay far less for it.
This is where you (or your partner) can be clever with data rulesets and what is migrated. For example, creating rules so that ‘only data with activity in the past 2 years’ or ‘only data that contains financial information’ is migrated to the new system.
Once you have a clear picture of what data is going to be migrated, your partner will then map your data to the new system. We find that the best method for this is to actually have a half-day onsite meeting with the administrator/key stakeholder, to go through which data is being migrated and showing where the data will be mapped to and how it would look, to ensure that you are happy.
Once there is a clear data scope, cleansed data and the mapping is outlined, then the migration can occur. This is the technical activity and can involve several tools to ensure that data is collected from different sources and formats (such as Excel, CRM solutions, Access etc.) and migrated to the new system.
Migration reporting is a key stage to check what has, or has not, been migrated. As vast quantities of data may be migrated, you need to know whether this was successful or not. The reporting will outline what data is expected to be migrated, outlining quantities and details so that once the migration is complete, reports can be reviewed to ensure that the migration is a success. This will show successes, failures and any partial migrations. Failures or partial migrations could be caused by poor quality data or incorrect data (such as text in a date field), however this is unlikely to occur after data cleansing. If there are errors, then the reasons need to be listed, remediated and re-migrated.
Finally, you should review the data in the system to check that the fields all appear correct and as you wish in the UAT environment. If there are any issues, these can be addressed and re-tested before anything goes into your live (production) environment. Note: you will not need to check all data has been mapped as the reporting will pick this up.
If everyone is as it should be, then success – your data has been successfully migrated!