It’s Friday and time for another… What? We don’t have one? The camera was stolen? And the producer is missing? Let me start again.

It’s Friday and time for another ¡Como estas amigos! from our good friend Pablo “CRMGamified” Peralta. After reading this you’d have to agree that this walkthrough is just as good as any video. So without further ado.

Step-by-step Guide to Exporting and Importing the New Product Catalog with Configuration Migration Tool

Introduction

Situation

You’re using CRM 2015 (Onprem or Online). You’ve already created your product catalog, including all family structures and price listings. Now you wish to export it into your testing or development environment, taking it toward production.

The bad news: unlike previous versions, you can no longer export and import with Excel. If you do this, your family hierarchy will be left behind.

The good news: you can export and import the Product Catalog using a new tool introduced into the CRM SDK as from CRM 2015, called Configuration Migration Tool.

In this article, I’ll share a step-by-step guide on how to do this. These are the steps I recently followed to carry the Product Catalog from one environment to the next for a client, so I hope they work for you as well.

Prerequisites

You need to download the Dynamics CRM 2015 SDK, in case you haven’t already. Once you’ve downloaded and extracted the package, you’ll find the tool we need inside SDK\Tools\ConfigurationMigration with the file name: DataMigrationUtility.exe.

Exporting Our Catalog from its Original Environment

We then open SDK\Tools\ConfigurationMigration\DataMigrationUtility.exe.

1. Create Schema
   
2. Connect to your CRM
   
3. Select your solution (or default solution) in order to select the Currency entity (transactioncurrency) and then click on “Add Entity”.
   
4. In Tools > Configure Import Settings, we select the fields we’re going to consider as unique identifiers for the Upsert when we import. In other words, we can choose they key (one or several fields) to figure out if the destination record already exists -or not- and, in this way, determine if the application needs to insert or update.
   
   Additionally, we can choose to deactivate plugins during the import, in case any of the selected entities have associated plugins.
   
5. We validate the schema in Tools > Validate Schema
   

   

6. Save and Export. Doing this we’ll be prompted to name the file. Let’s call it “Currency”.
7. We then agree to export all data and name the data file (i.e. “Currency.zip”)
8. The end result should look like this:
   
9. We then repeat steps 1 through 8 for the Price Listing entity.
   
10. We again repeat steps 1 through 8 for the Product entity, in order to export products.
    *** IMPORTANT ***
    Products, families and sets must be Active in order to be exported. Drafts will be ignored when exporting. So make sure you individually activate all products or each family hierarchy before running.
    
    If you’re not using entitlements or sales literatures, you’ll want to remove all relationships to at least avoid alerts (do this by right-clicking on Relationships – “Remove Relationship”).
    
11. We once again repeat steps 1 through 9 for the Price Listing Element entity. This way, we can export all prices for each product in each price listing.
    
    
    

(Phew! Half way there! – t.j.)

Importing the Catalog into the Destination Environment

12. Once inside the application, go to “Import data”.
    
13. Continue
14. We log on and select the destination organization.
15. We first import Currency. We select the corresponding zip file (Currency.zip)
16. We then repeat steps 12 through 15 to import Price Listings (I had 3 in my case)
    
17. We can now import Products (repeating steps 12 through 15 for the Product zip file). It’s important to first import currency and price listings before importing our products. Why? Because if we already have price listing elements, then the first price listing associated with a product is considered its default price listing and, therefore, creates a dependent lookup.
    
18. Last but not least, we import the Price Listing Elements, which actually include the prices for each product in each listing. We should attempt to import these once currencies, price listings and products have already been imported.
    
19. That’s it – we now have our catalog up and running!
    

Troubleshooting and warnings

Not everything works this wonderfully. If we receive any errors or warnings, here’s how we can see their details:

First we must go back to the application’s home page. We can then check import logs in the Log menu:

The error in this example shows that there is not “dyn_cd_producto” field in the destination schema. Therefore, here’s a good tip: if you customized any of these entities (i.e. added new fields), then you need to make sure that you apply the corresponding solutions so that the original and destination structures are the same.

For more information on the Configuration Migration Tool, click here.

I hope this was useful! As always, let me know about your experience in the comments or leave a message in the community technical forum if you need any help.

Cheers!

Tipp Jarr’s Double Dipp

¡Ay, caramba!