Notes SharePoint Blog

In Part 1 we talked about what the new Managed Metadata fields are good for, especially when migrating a Notes application.  Today we will look at how to configure them in a SharePoint 2010 list or library and how to use Notes Migrator for SharePoint 5.3.3 to migrate to them.

Defining your managed metadata field in SharePoint

First you need to define a column in your target SharePoint list or library that will hold your migrated data.  Unfortunately, Notes Migrator for SharePoint cannot provision this type of column for you as it can with most other column types, so you have to define it using the SharePoint user interface or with SharePoint Designer.

When adding a new column to your list, you can now specify a column type of Managed Metadata.

Next, specify what term store and term set you want to use.  Recall that the term set is the list of all the legal choices for the column (similar to the source view in a lookup column). 

To define a new ad hoc term set just for use with this application, select Customize your term set.  The new term set will be scoped to your site collection.  You can add terms and sub-terms immediately by using the built in editor, or click Edit using Term Set Manager for a more advanced editing experience.  (More about populating your term sets later.)

Alternatively, you can choose an existing term set – either an “Enterprise” term set from one of the shared term stores configured for your SharePoint farm, or a term set that was previously created for this particular site collection.

Note that the above screen shots highlight some additional options you have when defining your Managed Metadata column.  You can specify whether or not the field is required, what the default value is, whether or not the field is multi-valued, and whether or not the user is allowed to add terms not already in the term set.  These are all self-explanatory but are all important decisions to make as you design the ideal experience for your end users.  And, of course, they impact the choices you make when migrating things.

Before going any further, I suggest trying out your new column.  Manually add a few new test documents and make sure the column behaves the way you expect it to.

Adding a managed metadata field to your migration job

Now for the good part…  migrating some Notes data to our new managed metadata column.  In the Notes Migrator for SharePoint client, edit your Target Data Definition and go to the Data Fields tab.  If you are connected to your target SharePoint lists, the easiest way to add a field definition will be to press the trusty “Load From SharePoint List” button.  This will inspect the list and add a new field with many of the properties already set to reasonable defaults.  Alternatively you can press the Add button and manually specify the Name and a Target Type of “Managed Metadata”.

One of the trickier bits of this process is describing how you want your Notes terms to match up to your SharePoint term set terms.  This is especially interesting if your Notes terms and/or your SharePoint terms are hierarchical.  Notes applications typically store hierarchical categories and keywords using slashes or backslashes, for example “Trees\Oak”.

On the SharePoint side, you may or may not have defined a similar hierarchy of terms and sub terms.  In this example we have a term called “Trees” and under that a term called “Oak”.

Notes Migrator for SharePoint gives you several options for dealing with this.  Set the Hierarchy Options property to “Map As Hierarchy” if you want precise matching up of the full term path (all the terms and sub-terms).  For a more forgiving mapping, select “Map Last Leaf Only”, which would allow “Trees\Oak” to match any term named “Oak”, regardless of hierarchy.  Finally, you can select “Not a Hierarchy” which would not treat slashes as special and would simply map “Trees\Oak” to a term with the flat string “Trees\Oak”.

The Match on Alias property allows you to discover terms based on aliases (including internationalized versions of terms).  This way, if some of your old Notes documents has “Oaks” instead of “Oak” you can set up an alias in SharePoint to capture that.  (Tip:  you can safely remove the aliases in SharePoint after your migration is done.)  You can also specify a particular language to use for term matching using the Default Language LCID property.

The Add Missing Terms to Term Store option allows you to populate new terms in your term store as you go.  This is an important migration option as it allows you to migrate all the term values found in your historic Notes data.  If this option is turned on, Notes Migrator for SharePoint will first attempt to locate an existing term (using the options described above) and add it if no match is found.

Finally, back on the Notes Migrator for SharePoint mapping tab, you should map a Notes source column to your new target field, just like you would with any other field you want to migrate.

When you migrate, you can see any term mapping errors, etc., in your log file.  Turn on Verbose logging in the tool Options for maximum debugging detail (but remember not to leave it that way for your entire migration project!)

As a final note, remember that Notes Migrator for SharePoint always gives you option to use formulas in your source fields.  This can be extremely helpful if you do not have a one-to-one mapping of term strings but need to do lookups or otherwise massage the data along the way.