Absolutely horrified! That’s the reply you want to avoid at all cost when asking your customers how they feel about the data migration from their ‘old’ application to Dynamics CRM. Unfortunately, it’s a response I hear all too often when asking that exact same question.

I’m firmly convinced it doesn’t have to be that way though. During the data migration projects I have done I learnt two things are crucial to succeed in Dynamics CRM Data migration projects. Planning & Anticipation.

In this first part of my 2-episode-blog-series I’ll discuss the former in depth, the second blog post will focus on the technical implementation of the latter.

So… Planning?

Imagine this: a customer decides to bring Dynamics CRM to their company. They start by gathering the business requirements through workshops, interviews, and so on. Once they’ve got their requirements all figured out, they Fit-Gap these requirements to Dynamics CRM. Done.

Alright, let’s start customizing and developing CRM! But what about Data migration? Oops… Oh well, don’t worry, we’ll do that once the devs are ready.

[bra_divider height=’2′]

Sounds familiar, right?

It shouldn’t. A crucial mistake is to overlook the data migration or incorporate it as an additional step in the development phase. Data migration is a whole other ballgame and should not be seen as an additional item in the development track of CRM. I prefer to see the data migration as a separate track that has dedicated team members working on it. Obviously this track has inter-dependencies with the development track, but it should have it’s own, separate focus. There’s a couple of good reasons for this:

1. Data Migration requires dedicated analysis.

It needs to be clear what the scoping is, mappings between source & target have to be defined, estimates of volumes and load times have to be defined, …

2. CRM Developers are not necessarily Data migration specialists.

A CRM Developer might know the CRM Data Model and how the data should look in CRM, but that doesn’t make him a data migration guru. This is very important regarding data migration performance for example, which I’ll describe more in depth in the blog post Dynamics CRM data migration: Part 2 – The fast lane.

3. Data Migration is an agile process too.

Just like any other development process, data migration should be seen as an agile, iterative process. Scope definitions and mappings will change during the development lifecycle, bugs will occur, … If the Migration process is added to (the end of) the development lifecycle you risk not having enough time or resources to perform this process.

4. Data migration will contain bugs.

Again just like any other development process, your data migration will contain bugs. Some transformation errors will occur, scoping will be wrong, … This needs to be taken in to account.

When data migration is seen as a separate track it is possible to maintain deadlines, obtain a welldefined process and anticipate future changes and developments. Most of all, it will guarantee the quality of your data migration.

In my next blog post I will discuss how to achieve maximal performance for complex Dynamic CRM data migrations using tools like custom .NET development, Scribe or the Kingswaysoft SSIS Adapter.

I’d love to know your thoughts on the subject! How do you tackle large Data Migration projects? Do you agree or have a completely different approach? Leave a comment below and let me know!