Migrate SharePoint 2010 content with managed metadata challenges - Part I use cases and issues

As we mentioned before, the Managed Metadata Service application is one of the most important and interesting new service applications in SharePoint Server 2010.  However, it’s very frustrating for SharePoint users and administrations not able to use the global and local managed metadata columns when you migrate the site collection from one farm to different farm, migrate site collection from one webapp to different webapp with same or different Managed Metadata Service applications.  The major issue after the content migration is the managed metadata column values become un-editable and terms are not available that Microsoft has not resolved!

It will become even worse if you migrate sub site from one site collection to another site collection with same or different Managed Metadata Service (MMS) application. The reason is the managed metadata column might be implemented through list column, site column, and content type. The site column and content types normally are on site collection level and will not be migrated with sub-site!

The major reason for this issue is the GUID changed and links broken as many people reported. Before you read the following sessions, you might need to review the previous post regarding the managed metadata column relationship. There are many efforts to resolve this but all of them have some limitation. We have worked with consultants and Microsoft product special service groups for a long time to provide a final solution to meet the different content migration managed metadata repair tool. In this blog, I’ll go through the major issue and most of the use cases so we could go to details how to resolve each of them in the future blogs.

Since the content migration could be on several different scopes like site collections, sub site, list, and item level, there will be many combinations of the migration if we consider the destination might have same MMS or different MMS. Here are some major use cases in our company that we try to find solution.

1. Migrate site collection(s) from one farm to another farm with same MMS
2. Migrate site collection(s) from one farm to another farm with different MMS (This can be done to combine #1 and #4)
3. Migrate site collection(s) from one webapp to another webapp with the same MMS
4. Migrate site collection(s) from one webapp to another webapp with the different MMS
5. Migrate sub site(s) from one site collection to a different site collection with the same MMS
6. Migrate sub site(s) from one site collection to a different site collection with the different MMS
7. Migrate list(s) from one site collection to a different site collection with the same MMS
8. Migrate list(s) from one site collection to a different site collection with the different MMS
9. Migrate item(s) from a list to another list in a different site collection with same MMS
10. Migrate item(s) from a list to another list in a different site collection with different MMS

Since you may link managed metadata column through list column, site column, and content type, you will have to test each use case all three implementations. To illustrate the content migration with managed metadata issue, we start with use case #1 to migrate one site collection from one farm to another. This is very common user cases we refresh all production content to one non-production environment so we could test upgrade process. This example is using managed metadata column through list column.

First we set up source site collection with url http://sbx10:3333/sites/mmd1, global terms, and local terms like in the following screen shot.

Second, we create two lists to use global terms and local terms separately. One named “Local Terms Test” using local terms and another list named as “Gobal Terms Test” using global terms. See following screen shots for details.

When you try to edit the items using global terms and local terms, you are able to change the values as in the following screen shot.

 

For migration, we demonstrated the common way for content migration that is very close to the one posted here.

1.  Site collection migration

• Back up site collection content DB from source farm
• Restore to destination farm as http://sbx08:3333/sites/mmd1

 2.  Managed metadata service migration

• Back up managed metadata service database from source farm
• Restore managed metadata service database to destination farm
• Configure managed metadata service on destination farm to use backed up managed metadata service database

After all these work, you would expect the site collection on destination farm with all the content and managed terms migrated. When you look at the destination site collection and list, it seems like all managed metadata values for both local and global terms are migrated to http://sbx08:3333/sites/mmd1 as in the following screen shot. 

However, the first issue is only global terms are available but NOT the local terms through manager terms link as in the following screen shot.

The second issue is when you try to edit either local or global terms, all of those terms are greyed out and uneditable as show in the following screen shots. One is for local terms and another one is for global terms.

 

  

Now, the migrated managed metadata are not linked to the correct term stores! We have tried several ways to fix the issues with limited success. Some methods listed below could fix the global terms but none of them could fix both global and local terms. Here is the list of the methods we tried from different blogs.

1. Backup and restore approaches suggested by Wictor and PointBeyond
   
   
2. Taxonomy APIs C# code to export and import managed metadata by Chris Khaw
   
3. Export/Import-SPMetadataWebServicePartitionData to export term store by Tajeshwar Sing and Microsoft DSE
   
4. Manually link back terms
   

We have found the global term store issues could be resolved much easier than local term store. The site collection migration is easier than sub site. The migration between same MMS is easier than different MMS.  Since there is no simple solution to cover all the test cases we discussed, we worked with Microsoft service group on building several tools to link back the migrated managed local AND global terms. I'll cover the details to each different uase case in future blogs.