If the TaxonomyMigrator has been used to migrate Managed Metadata term groups and term sets and a json file with taxonomy mappings has been generated, these mappings can be imported to the Content Matrix Job Database and/or Distributed Database using PowerShell for use in future migrations.

NOTES:

·Taxonomy migration creates all the term groups and term sets that are not present in the global taxonomy mappings.

·After importing to Content Matrix, mappings will be resolved during content migration and not remigrated.

·The imported mappings are handled as global mappings and not distinguished between multiple term stores.

·The mappings are not visible on UI and can be listed only via PowerShell.

Before Importing Managed Metadata Mappings:

Open the Content Matrix Console and from the Jobs List File menu select the option for the database to which you want to copy the mappings:

·Connect to Distributed Database

OR

·Connect to Job Database

To access the PowerShell cmdlets for importing taxonomy mappings:

Open a PowerShell or PowerShell ISE session and add the PowerShell snap-ins for the application framework.

The following cmdlets are now available:

Load-GlobalTaxonomyMappings

Get-GlobalTaxonomyMappings

Clear-GlobalTaxonomyMappings

To import global taxonomy mappings to the selected database:

Select (from the PowerShell ISE Command Window) or enter Load-GlobalTaxonomyMappings and enter the path to the JSON File , then run the cmdlet.

Example script:  

Load-GlobalTaxonomyMappings –JsonFile "C:\Temp\mappings.json".

NOTE:  It will be necessary to restart the Content Matrix Console after taxonomy mappings are loaded.

To display a list of global taxonomy mappings:

Select (from the PowerShell ISE Command Window) or enter Get-GlobalTaxonomyMappings, then run the cmdlet.

A list of the unique identifiers for each source/target mapping displays.

To clear global taxonomy mappings from the selected database:

Select (from the PowerShell ISE Command Window) or enter Clear-GlobalTaxonomyMappings, then run the cmdlet.

If  you want to copy classic web parts as part of the migration, select the Classic Web Parts Options tab.

NOTE:  Modern web parts are copied as part of page metadata.

NOTE:  For special considerations when migrating classic web parts, see Classic Web Parts Migration.

To configure Classic Web Parts Options:

1.If you want to Use Import Pipeline for Webparts, check this box.

NOTE:  This option is available only if Advanced Mode is enabled and you chose to Use Import Pipeline on the List Content Options tab.  See Using the Import Pipeline to Migrate Classic Web Parts for supported web parts, requirements, and limitations.

2.If you initiated a site collection or site-level migration and want to Copy Web Parts on Landing Pages, make sure this box is checked.

NOTE:  Landing pages are usually the default.aspx pages, but these pages can also have other names. For example, starting in SharePoint 2010 these have been changed to home.aspx pages when Wiki features are enabled.  While the method to migrate these pages is the same as for other web parts, the logging may be slightly different.

3.If you want web parts to be copied on any other web part pages (aside from landing pages) or in any publishing content, make sure the Copy Web Parts on Web Part Pages and Publishing Content box is checked.

4.If you want to copy SharePoint lists or libraries that have a "view" set on them, check the Copy Web Parts on List View pages box.

NOTES:  In some cases these views have web parts added to them, which only appear within that specific view. This option preserves the addition of these web parts within the views.

In SharePoint 2010 there is an issue relating to adding web parts to a list or library "view." When a web part is added to a list or library the "view" option (or the ability to select a specific view) is no longer available for that list either next to the title, or in the ribbon. This is caused by SharePoint 2010, and not by Content Matrix.

Content Matrix does not currently support the preservation of views on SharePoint 2010 XSLT list view web parts.

5.If you  want to copy web parts that exist on a page but are no longer displayed, select Copy Closed Web Parts.

6.If you want to copy HTML content from a "Content Zone" on a page, make sure the Copy Content Zone box is checked.

NOTES:  

§A "Content Zone" is a location on a page (introduced in SharePoint 2010) where general text can be added, AND a web part can also be embedded into that same location (for example, a Wiki page/Wiki content). When selected this option will help ensure that web parts that are embedded in these "Content Zones" will appear in the correct location on the target after migration.  This option is only available when migrating from SharePoint 2010 or later.

§It is recommended that this option be enabled for most migration scenarios.

7.If you have any web parts that are on custom created "Form" pages to be migrated, make sure the Copy List Form Pages box is checked.

NOTES:  

§This option does not support any customizations of an Out Of Box (OOB) form that is  not related to web parts and is customized through the direct modification of the ASPX page (aside from adding or modifying a web part).

§This option is automatically selected if you checked the Copy Customized Form Pages box on the List Content Options tab.

8.If you are copying web parts as a post-migration task and you want to Copy Web Parts Recursively down through the content structure, check this box.

NOTE:  This  option is only available when migrating web parts as a separate action.

9.For Existing Web Part Protocol, select how you want to have Web Parts that already exist on the target handled before migration:

§Delete Existing Web Parts on Target (default)

§Close Existing Web Parts on Target

This will close, but not delete, any web parts that exist on the target, before migration.

§Preserve Existing Web Parts on Target

For users to be migrated, they must exist on the target side Active Directory (AD), so that SharePoint can authenticate them. A good rule of thumb is if the user cannot be manually authenticated in the target SharePoint instance, then Content Matrix will not be able to add them.

In cases where data was migrated and the referenced user cannot be authenticated, Content Matrix will set the migrating user account into the files metadata instead, and a warning will be listed in the logs. In these cases user mappings can be set up, to map these users to another account.

You can also migrate only users from a source to a target as a separate action.

If a migration is initiated at the site collection or site level, Content Matrix can migrate permission levels as well as permissions. This includes any default permission levels that have been modified, as well as any custom created permission levels.

Permission levels are a set of permission rights that can be assigned to a user or group as a "permission." Content Matrix can migrate these permission levels as part of a site level migration, or they can be migrated separately through the context (right-click) menu.

For example, if there is a custom permission level on the source called "Marketing Team," that is applied to a group and some users, then this permission level would not normally be migrated, unless this option is used. If this option is not used, Content Matrix will try to map the permissions over to the target, but will fail because the "Marketing Team" permission level does not exist, even if the users/groups exist, so we will try to match these permissions to the next closest match. If the copy Permission Levels option is used, the permission level will be created on the target SharePoint instance (otherwise it would have to be created manually). Once the permission level is created on the target, all the user/group permissions can be migrate and mapped over to the target SharePoint instance without issue.

NOTE:  If a site level copy is being performed, and the Copy Child Sites recursively option is enabled (in the Site Options section), all the sites, lists, folders, and items under the selected source node will be migrated, and any enabled options for permissions copying will be applied recursively down through the migration. If Copy Child Sites recursively is not enabled, only permissions for the selected (top-level) site will be copied.

If  you want to copy permissions as part of the migration, select the Permissions tab.

To configure Permissions Options:

1.If you want to Copy site permissions:

§make sure this option is selected

AND

§make sure the appropriate additional options are selected.  Use the information in the following table for guidance.

2.If you want Copy list permissions, make sure this option is selected.

NOTE:  This option is not available if you initiated a folder- or item-level migration.

3.If you want to Copy folder permissions and/or Copy item permissions, make sure each applicable option is selected.

NOTE:  Copy folder permissions is not available for an item-level migration.

4.If you want the existing permissions inheritance of the root node being migrated to be ignored and have any permissions levels and permissions migrated directly for the site, make sure the Ignore permissions inheritance for root node box is checked.

5.If you are migrating permissions as a post-migration task and want to Delete pre-existing permissions on the target, check this box.

NOTE:  If you are performing a full migration, this box will be checked and disabled, to ensure that any permissions that exist on the target, within the scope of the migration, are deleted so that no issues are encountered when the migration is run and the source permissions are migrated

6.If you want to copy permissions levels from the source to the target by matching names make sure Map permission levels by name is selected.

For example, if an "Admin" role exists on both the source target, the "Admin" permissions on the source will map over to the "Admin" role on the target, even if they use different levels of permissions. Any item, group, or user that has "Admin" permissions on it will still have "Admin" permissions, though the level of access might be slightly different (if the rights for the "Admin" role are different between the source and target servers).

NOTE:  If this option is selected and the role does not exist on the target, it will be skipped.

7.If you chose to Map groups by name and you also want to overwrite any groups on the target, make sure the Overwrite existing groups option is selected.

NOTE:  If you leave this box unchecked, users will be appended into existing groups.

8.If you want roles on the source to be mapped to different roles on the target:

a)Check the Override role mappings box.

b)Click the […] button.

c)Follow the procedure for Mapping Roles.

NOTE:  When you use this option, any other existing permissions role mapping that is set up will be overridden.

9.If you are migrating from a SharePoint 2019 source and want to Convert Sharing Links permissions to direct permissions, check this box.

NOTE: This option is disabled if the if the source is SharePoint 2016 or earlier. See "Share With" Metadata and "Sharing Links" Access Migration for details.