Data Migration Manager and Configuration Workflows…

Go together like cold Negra Modelo and fresh Guacamole!

I recently visited Mexico City, and had the good fortune to stay in a hotel (the Fiesta Inn, in case you ever visit the Santa Fe district) that served the best guacamole I’ve ever tasted. It was even better if consumed with a couple cold Negra Modelos. As I enjoyed that particular combination, I also learned to enjoy another one: the Dynamics CRM 4.0 Data Migration Manager and automatic workflows to configure the account records I was migrating.

I recorded a video on the topic (the DMM and account configuration workflows, that is), and if you’d like to simply jump in and watch it, here’s the link:

Using the Data Migration Manager and Automatically Configuring Account Records

Background

Until recently, I’d had limited experience with the Dynamics CRM 4.0 Data Migration Manager (henceforth, DMM). Mainly I’d used it to migrate the sample data set you can download here. You’d expect it to work well with a sample data set designed for the purpose, and it does. A few weeks back I needed to use it for a real customer engagement…so I finally had to actually learn it. My impression from a recent meeting of the Dynamics CRM User Group is that not many people are using it, perhaps assuming that tools like the ones offered by Scribe Software are a practical requirement to migrate real data. I might have thought that before I learned how to use it but I don’t anymore. If you need to migrate data into Dynamics CRM 4 I encourage you to consider the DMM. Certainly it has the advantage of being free, and while there are plenty of things Scribe can do that the DMM cannot (e.g., real-time data integration applications), my guess is that for a wide class of data migration scenarios the DMM will do just fine.

Dynamics CRM 4.0 Data Migration Manager

The DMM is a standalone application. You run it on a PC with an Internet connection (or at least, with a connection to your CRM server), and you must be a system administrator to run it. It’s worthwhile comparing it to the Import Data Wizard, which is exposed from within the CRM interface, and can be used by any CRM user with sufficient permissions. Here’s a quick summary of the things the DMM can do that the Import Wizard cannot:

Feature Data Migration Manager Data Import Wizard
Import multiple file, relational data sets Yes No
Maintain owners of imported records Yes No
Maintain the historical value of dates records were created Yes No
Can import status and status reason values Yes No
Can create custom entities during import Yes No

 

These five features are important, and with the exception of the last one (which is a nice-to-have but maybe not a must), come pretty close to defining a baseline required feature set for an enterprise-capable data migration tool.

Here are the features I illustrate in the video:

  • Migrate a complex, relational data set. I show a data migration of Accounts, Contacts and activity (phone call) records. These are related to each other, and as you’ll see if you watch the video, the DMM is excellent at migrating complex data sets like this.
  • Maintain actual historical values of “created date” for migrated records. Unless you want to lose the dates records were created, this is a must-have feature, and the DMM handles it nicely.
  • Can create custom entities on the fly. As I said above, this might not be a must-have feature, but it sure is convenient!

 In some other videos I’ll focus more on some of the other important features.

Account Configuration Workflows

OK, what does any of this have to do with account configuration workflows? Well, strictly speaking, not much. But just as my favorite guacamole is better with Negra Modelo, my argument is that the DMM is better with one of these. The key thing is that if you have a published workflow triggered by “create record” for account (any entity, for that matter, but these are generally more valuable for account records), it doesn’t matter how a record is created – the workflow will always run.

In the example I show, the imported account records have values for the country they’re located in, and the U.S. records contain zip codes. I’ve got territories defined (using the out of the box CRM Territory entity) of these values: International, East, Central, West. My organization’s base currency is the U.S. dollar, and I’ve got additional currencies (Mexican Peso, Canadian dollar, and the Euro). Here’s the heuristic structure and logic of the workflow:

  • First, update any information that should be shared by all account records
  • Next, check to see if country=US
    • If so, check zip code value
      • If starts with 1,2,3 or 4, set Territory=”East”
      • If starts with 5 or 6, set Territory=”Central”
      • If starts with 7,8 or 9, set Territory=”West”
  • If country value <> US
    • Set Territory=”International”
    • Check country value
      • If MX, set default currency = Peso
      • If CA, set default currency = Canadian dollar
      • If GE, FR, EN, set default currency = Euro

As I said, it’s a relatively simple workflow, but it improves my account data a lot! After migrating the data, in the video I show how easy it is to create a graphical view of how your data are distributed across various categories. I show a pie chart of how my new accounts are distributed across territories, but I could just as easily do it for countries, currencies, or any other piece of data stored on the account records.

For more information…

At the Dynamics CRM User Group Meeting on June 25th, 2009, I’m going to give a more thorough presentation on the topic of the Data Migration Manager, so if you’re interested, please join us: register here.

Also: I’ve got a whole book on workflows, chock-full of examples, explanations, and tips & tricks. It’s available in print, downloadable, and even a cool new e-Book version for you Kindle readers. You can buy it from my lulu.com storefront, at http://stores.lulu.com/richardknudson 

Or if you prefer, you can get it on Amazon for the same price.

Cheers -

Richard – richardk@imginc.com

4 Comments »

  1. sander Said,

    June 22, 2009 @ 12:10 am

    Hello,

    I watched the video and I think there’s a mistake in your description.. When you get that error with the first import, at phone calls, you suggest that the phone call was a duplicate and its good not to be imported, but what I think it says is that it found 2 accounts that are duplicated, so that the engine didn’t know for which to assign the phone call to.

    Other than that, really cool presentation; I liked your idea when using that counter to be able to create charts.

    Cheers,

  2. Richard Knudson Said,

    June 22, 2009 @ 7:37 am

    Hi Sander,

    Good catch; I remember wondering about that just as soon as I made that comment. :-)

    I’ve got a couple more recordings I’m going to post on the DMM on some other topics you might be interested in. Have you migrated data with the DMM? I’ve been using it a fair amount recently but I haven’t migrated a large data set and I’m wondering what performance is like for large files.

    Glad you liked that counter trick. I use it all the time.

    Cheers —

    Richard — richardk@imginc.com

  3. sander Said,

    June 23, 2009 @ 10:16 pm

    Hi again :)

    Yea, I’ve been using DMM a lot lately and, actually, right now I have to import around 8000 accounts, 20000 contacts, 60000 phonecalls and 20000 records of a custom entity. Still working on the relations, atm, but I’m really curious as well to see how fast the migration will run.

    There’s one thing I’d like to ask.. I noticed that if I want to assign a phone call to a contact (I have the fullname for it) and at the same time I’m migrating the contact (using first and last name), the engine does not always recognize it.. so that I tried using the GUID. Do you have any idea if I can force the guid (also from CRM) onto this new database?

    Regards,

  4. sander Said,

    June 24, 2009 @ 2:08 am

    Well.. you can scratch that last comment/question. I managed to import everything but the phone call. Having Problems filling the recipient and regarding fields, since I’m not able to, somehow, map the objecttypecode. Ever managed to import this kind of entity (having a regarding with multiple relation types) using DMM?

    Regards,

Leave a Comment