The 5-Steps to Data Migration Success

In a previous article, I highlighted the three major pitfalls in CRM data migration you need to know. If you’ve not read that article yet, I highly recommend you start there. In this article, I’m going to cover the 5 steps to data migration success that will ensure you can switch your old system off with confidence.

Why is it important to switch off your old system?

The whole purpose of implementing a new system is to achieve some form of business improvement. However, people can be slow and even resistant to change. The more you give them a chance to go back to their old ways, the more likely they are to do so. Also, if you leave the old system running, you’re going to experience increased operational costs, security risks, and data integrity concerns.

On the other hand, upon successful migration, you should have:

  • Happy users with no desire to go back to the old system.
  • Productive users - within the first week or two, users should be as productive as they were with the previous system(s).
  • Any data held in legacy spreadsheets and other data stores migrated across to the CRM.

The route to data migration success

So, how do you go about successfully migrating your data? The 5 steps below will take you sequentially through what you need to do.  


5 Steps to Data Migration Success

Step 1. Plan the Data Migration

Data migration is a one-off exercise at the start of the project. One should therefore spend the right amount of time doing this, and no more. It helps having experience in doing this as without which, it is common to start off using a simple technique that later proves inadequate. For example, using vlookups in a spreadsheet to identify and associate data could initially seem a great solution, but if there are gaps in the dataset, the outputs might be incorrect. Having experience helps you spot deficiencies early, and switch to other proven methods such as using a comprehensive set of queries in a SQL server database.

Early stage planning consists of a few trial runs to identify the approach. This could include:

  1.  Identifying the different record types to be imported
  2. Identifying the relationships between records
  3. Identifying the IDs that are linking record types, for example: 
    • Employee.EmployerID = Organisation.ID
    • Opportunity.CustomerID = Organisation.ID
    • Opportunity.PrimaryContactID = Person.ID

Step 2. Map the data fields

In order to import data, the record types firstly need to be mapped. For example, a sales lead in the new system may come from a different record type in the old system, built on an older-style marketing stage classification.

Once you have record types mapped, fields then need to be mapped. This includes the data type of each field, for example:

  • Integer
  • Text
  • Currency
  • Decimal
  • Percentage
  • Picklist
  • … and more

Step 3. Create the data fields

Once the fields are mapped they need to be created in the new system. This may sound obvious, but there are a few further things to consider:

  1. ALL fields containing data in the old system will need an equivalent field in the new system. Don’t skip any fields as you may find you need them later. You can always hide fields from display in the new system so they don’t clutter the user interface.
  2. Make sure the field’s data type in the new system is suitable for the data about to be imported. For example, importing decimal values into an integer field will cause truncation; importing text values into a decimal field will cause errors during import.
  3. Take care to ensure field names align with the data map created in step 2. This is crucial to the next step - creating a robust and repeatable import process.

Step 4. Define the data migration process

Importing data is an iterative process for a number of reasons:

  1. You are unlikely to get the mapping 100% right first time. Field names in the old system may be ambiguous and it is only when you test early iterations by viewing, say, a ‘person record’, that you’ll notice that ‘title’ really means ‘job title’.
  2. The import process will likely throw up errors and warnings where data does not match. For example, as mentioned above, integer and decimal mismatches; date fields in the wrong formats, or text values in the source data; a text field assumed to be max 255 characters turns out to be much bigger, causing truncation – a common issue. It typically takes between 4 to 8 iterations to get the data migration process right - which means robust and repeatable. The important thing is to refine the data migration model and document the steps. The data should be exported in the same format each time, with the right column headings. And transformation steps – for instance changing a date format to dd/mm/yyyy – will need to be executed in a specific sequence.
  3. You may have records that need to be fixed manually. Inconsistencies in source system data often require some manual intervention. Typically, this should be no more than 1%-2% of total data. To make the migration process robust, ensure these records can be separated out, fixed, and re-imported using the same migration model.

Step 5. Minimise down-time

Here’s the problem: While you’re doing your data migration, the business still needs to operate. That means using the old system, and adding and changing records. You can seldom expect users to down-tools one day, and start working with a new system the next. They need to be trained, which of course takes careful planning and time. is needed to prevent downtime and missing data when switching to the new system.

Fortunately, most databases, including ACT! And GoldMine, have ‘created on’ and ‘modified on’ fields on all record types. This helps with the migration model, in the sense that you can extract the data now, record the date and time of the export, and the next time, query the data added or modified since the last export.

At CRM Insights, we follow a process where we test the model thoroughly by exposing key users to it at an early stage. Once everyone is happy with the data, core processes are documented using videos and other training materials. Training is then planned to conclude towards the end of a week. The final data migration is then done over the weekend, and the new system goes live on a Monday. This way downtime is minimised and data doesn’t get missed during the transition between old and new systems.


So there you have it – the 5-steps to data migration success. As I said at the beginning, if you haven’t yet read it, do take a look at the preceding blog article on the three major pitfalls in CRM data migration you need to know


Do you need advice on your data migration project ?

If you’re looking to implement or change your existing CRM system and would like further advice and guidance on data migration, then feel free to schedule a free call with an expert by clicking or tapping on the button below.