SharePoint 2010 Managed Metadata - Moving/Copying MMS Instances / Term Stores between Environments

So you’re plugging along in a project and this email shows up in your mailbox from some project manager or your boss who asks something like this:

“So, you sold us on using the SharePoint Server 2010 Managed Metadata Service (MMS) for all sorts of things, and we love it and are using it religiously. That’s all fine and good but we need to make a copy of it. See, this other group is working on a new project and we need to have a copy of all the taxonomies we created in the production MMS in development. How are we supposed to move it around?”

At first you might think “oh no… I’m going to have to work with those pesky farm administrators to do a backup of the MMS instance and then get it restored in development… man I can’t stand those IT pros…” because you’re thinking like most of us think: something is running in production so in order to get it running in another environment this must be something like a disaster recovery scenario.

Thankfully this isn’t the case… it’s actually quite straightforward. SharePoint creates a single SQL Server database where it will store everything when you create a new MMS instance. When you are prompted to enter the name of a database at the time to creating a new MMS instance, if you specify an existing database, provided it has the necessary permissions configured correctly, it will use that database instead of creating a new one.

So the quick an easy steps for moving a MMS from one environment to another are as follows:

1. Get the name of the MMS instance DB in the source or master SharePoint farm (where you want to copy FROM):
   1. Central Administration » Application Management » Manage Service Applications.
   2. Select the MMS instance and click the Properties button on the ribbon.
   3. From the dialog that appears, write down the name of the database.
2. From the SQL Server that your source SharePoint farm uses and where the MMS instance DB resides, backup the database.
3. Take the backup file to your target SharePoint Farm’s SQL Server (where you want to restore it to) & restore the database.
4. Next, make sure you grant DBO rights to the service account that is configured as the identity of the application pool that will be associated with the new MMS instance.
5. Now, on the target SharePoint farm (where you want to restore the MMS instance to), go through the process of creating an MMS instance except make sure you use the name of the database that you restored.
   1. When SharePoint goes to create the MMS instance it will see a database already exists with that name so it will check to see if it is an MMS database. If so it will use that instead of recreating it.
6. Verify everything looks good by going into the management page for the new MMS instance after it was created and you should see your taxonomies. To use them just make sure that the appropriate service proxies (aka: connections) are set up with the web applications where you want to use them.

Now, there are three questions I usually get when talking about this.

• The first one is how do you refresh the development instance after a few weeks/months? Easy, just repeat the process except restore the database over the target farm’s MMS database. You don’t need to go about recreating the MMS instance. The IDs don’t change, just more terms show up.
• Next question is “well what if I deleted or changed some terms… will those changes take effect in my content?” It depends… this process is good for a source > target copy… this isn’t a synchronization routine. If you want something like that you’re looking at custom code and working with the SharePoint 2010 Taxonomy API.
• Last question I usually hear is “after I’ve restored it in development and made changes, how do I push those changes back into production?” In my mind the taxonomies should be considered content. Do you really move development content between environments? Most people don’t from my experience. At most they manually recreate it. For taxonomies I think it makes more sense to treat production as “master data” and simply do a one way sync… similar to how we treat content deployment architectures: single master (authoring environment) that does a one-way push to a read-only production. If you really want to do a sync, this is a something you’re going to code up yourself as a custom solution unfortunately.