Insights

Data migration is a key stage for any CRM project. Ongoing CRM success relies on clean, high-quality data that brings values to users and staff — and by ensuring a successful data migration, you know that your new systems has a stronger likelihood of retaining high data quality.

Over time, data quality can easily diminish in CRM systems. This could be due to duplicates, incorrect usage of fields, spelling mistakes, inconsistent formatting and more. Simply ‘lifting and shifting’ this data into a new system will cause headaches, incorrect reporting, errors and it will mean that your new system – no matter how well designed and built – will already be off to a poor start. Instead, it is far better to put use the data migration stage as a time to improve data quality before moving it to your new system to ensure long-lasting data integrity.

Depending on how your project is being carried out, this tends to be a collaborative process with your CRM partner. They will understand the intricacies and possibilities of the CRM platform, while you will understand your data and which information is important to your organisation.

While you need to consider your data sources, fields and other factors, we’ve outlined a best-practices approach and the steps and actions involved that could typically happen during data migration. While we specialise in migration to Microsoft Dynamics 365, the following steps are relevant for data migration into any system.

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.

2. Scope

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.

3. Mapping

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.

4. Migrate

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.

5. Reporting

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.

6. UAT

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!