During any system implementation, the biggest unknown is always data migration. System architects can design and map out to the very last detail how a system should be set up, configured, what the training plan will be, how the roll out will happen, etc. The biggest caveat is always getting data from legacy systems and sources in to the new one. There are several reasons for this.

1. Data is stored all over.

A lot of times, when we are implementing a system like Dynamics 365, it is a total line of business application that is replacing several systems and sources. For instance, we may implement Business Central (ERP) and the Dynamics 365 Project Service Automation, Sales, and Customer Service apps. This is really one system that makes up four essential facets of a business. Due to this, the legacy data is often stored in old, outdated systems, excel spreadsheets, email systems (yikes), old file servers, etc. This makes it extremely difficult to gather all the data, get it in a usable format and correctly migrate it to Dynamics 365.

2. Customers want to migrate everything.

If you have been using a system for a long time, chances are you have accumulated a lot of data. The truth is, its not all relevant. If you have been using a CRM system since the early 2000s, do you really need note records on a contact you haven’t spoken with in 10 years? Some people feel very passionately that the answer to this is “yes” and are insistent that all this information comes over to the new Dynamics 365 implementation. Similarly, during an ERP migration, customers often think they need to bring over all historical information when just summary data will do.

This is a complicated situation. There is nothing wrong with wanting to keep all your data, just like there is nothing wrong with wanting to keep every greeting card you have ever received. The problem is, it makes for a lot of clutter and makes moving more complicated. I encourage customers to use a migration as a type of purge and an opportunity to start fresh.

3. Data Migration is never 1:1.

When you are looking at implementing a new system it is because you are needing more functionality or features that your current one doesn’t offer. It would be unrealistic to do this and assume that data would map over perfectly. If it did, what did you really change, automate, or gain from this process? Master records generally come over well: these would be something like Customer, Vendor, Opportunities, etc. However, support records like notes, attachments, activities, etc. can be trickier. It’s not impossible to bring them over, quite the contrary, but it can make migration more complex.

How can you avoid a data migration disaster?

Let’s look at an example of migrating from Salesforce.com to Dynamics 365 Sales. These are two customer relationship management systems. Both of them are well respected in the industry, have a large following, and have hundreds of add-on tools. They do what they do very well, but they do it very differently. At KTL, we have done several migrations from Salesforce.com to Dynamics 365, with different levels of data migration. Here are some things you can do in a similar situation, or really any type of data migration.

1. Be choosey on the data.

Like I said before, some people feel passionately about hoarding their data. Often, we hear “Well I may need to look at that one day”. Chances are, if you haven’t utilized that data in the last 3 years you aren’t going to. Part of being choosey is to involve key players from the organization when discussing this. Do not ask everyone who works in the company what their opinion is or you will absolutely end up with all data coming over. It is good to involve one key person from each department/sector to make sure you aren’t glossing over something that they use every day. For instance, maybe sales does not want to bring over contacts that haven’t touched in five years because they deem them to be cold/dead. However, its possible the marketing department is running targeted campaigns at these dead contacts to reintroduce and bring them back in to the sales cycle. This is an important conversation to be had. You cannot always assume that the left hand knows what the right hand is doing.

2. Understand that some things are not going to be automatic.

Sometimes you have to make a decision on what needs to be keyed in and what can be mapped in a data migration. It is important to speak with your partner and determine the level of effort data mapping will take versus the cost of hiring a temporary person or having administrative staff key in some data. I am a huge proponent on integration and automation, but sometimes it is more cost effective to have someone hand key it in.

3. Use a third party tool.

There are tons of third party tools out there that can be used in data migration projects. In the Microsoft Dynamics world you will often come across Scribe Software, eOne SmartConnect, Kingsway Soft, and a few others. These ETL (Extract, Transform, Load) tools can pull data from one system, manipulate it to the desired format, and push it to the new system. Often, they do this much easier and cleaner than building custom tools and manually passing excel files.

Customers are often wary because of the cost associated to purchasing an ETL tool, however the headaches it will save you in time, effort, and bad data will more than pay for itself. Say you are moving data from Salesforce.com to Dynamics 365 Sales. Salesforce.com doesn’t play nicely with other systems or really play nicely on the Microsoft platform (this has gotten better in the past few years but still stands to be mostly true). It would be a huge undertaking to manally move master records and subrecords over. Using a tool like eOne SmartConnect will pull the necessary data from Salesforce.com and allow you to map it to CRM using a friendly “no code” interface. SmartConnect also has an excel interface that can be used over and over for data importing and other integration projects.

Any data migration project is going to have its ups and downs and not one ever goes completely according to plan. Setting expectations, planning for issues, and taking the above in to consideration will greatly improve your odds of a successful migration. If you are looking to migrate from a legacy system to a Microsoft Dynamics platform I would suggest doing some research on the user group forums, creating a migration plan internally and with your partner, and checking out some of the third party tools listed.

KTL Solutions Can Help You Move

With a background in IT integration, application customization, and risk mitigation, there’s no better managed service provider to have on your side when it comes to moving data. KTL’s team has decades of consulting experience and a background with Fortune 100 companies. If you’re ready to move your data and take your business to the next level, get ready for a no-pressure conversation with us. Don’t wait, talk to us today.