Chat now with support
Chat with Support

Metalogix Content Matrix 8.8 - SharePoint Edition User Guide

Introduction Entering the License Key Content Matrix Console End User Interface Enabling Advanced Mode Connecting to SharePoint Preparing for a Migration How Content Matrix Handles Various SharePoint Components Initiating a Migration Configuring Copying Options Saving or Running a Migration Action Copying SharePoint Objects as a Separate Action Self-Service Migration Incremental Migration Log Files Using PowerShell with Content Matrix
Configuring PowerShell for Use with Content Matrix
Registering Metalogix Command DLL Files Adding PowerShell Snap-Ins for the Application Framework Content Matrix PowerShell Commandlet List
Metalogix.System.Commands Metalogix.SharePoint.Commands Metalogix.Jobs.Reporting.Commands Metalogix.SharePoint.Migration.Commands
Modifying Content Matrix Configuration and Settings Configuring Content Matrix for Distributed and Self-Service Migration Frequently Asked Questions
DB_Owner Permission Migrating with the Fabulous 40 Templates Item Count Discrepancies Keyboard Shortcuts License Key Troubleshooting Determining the Status of a Migration Running in the Background MySite and User Profile Migration Issues Optimal Setup for Best Performance Using Proxies, Load Balancing or Alternate Access Mappings Troubleshooting the Extensions Web Service Installing the Extensions Web Service on Specific Systems Extensions Web Service Installation Files Using Older Versions of the Extensions Web Service Preserving IDs when Migrating a Custom List as a Folder Migrating JavaScript Migrating Site Variations Migrating with SharePoint 2010/2013/2016 Document IDs Changing a Job Configuration for Multiple Files SharePoint 2003 Version Migration Limitations SharePoint 2013 and 2016 Site Collection Creation Issue Job List Database fails to Load After Upgrade Customized Wiki Page Web Part Zones Not Being Migrated Preserving SharePoint List Item IDs with a CSOM Connection Type Retrying Failed Document Copies to O365 CSOM Connections Migrating Content When the Source Custom List Template is Missing Are SharePoint Online Migrations Throttled? What to Expect when Migrating with StoragePoint on the Target Migration Error Message 'There was an Error Reading from the Pipe: The Pipe has been Ended (109, 0xd6)' How do I Remove Items from My Azure Blob Storage Account? Azure Batches Getting Stuck Supported Nintex Actions for SPO Migration "Insufficient Credentials" Message Connecting to Modern Team Site Using Web Browser Authentication Error Making a Browser-Based Connection with PowerShell Console Open
About Us

How SharePoint 2003 Portal Listings are Migrated

Metalogix Content Matrix can migrate SharePoint 2003 portal listings into SharePoint 2007 and SharePoint 2010. Since portal listings do not exist in SharePoint 2007 and 2010 instances, they are migrated to the target by copying them into links lists.

There are three basic types of portal listings in SharePoint 2003. They are:

·Links that point to content - These are the most common type of portal listing, and they are links that redirect users to other content.

·Person listings - When selected, these links will open a new e-mail to contact the named person.

Note: When migrating Person portal listings, User Mappings must be made/run first, in order to properly link correct the users from the source to the target.

·Listings that have their own HTML content (not just links to other content).

NOTE:  For listings that have their own HTML content, a listing will be created in the Portal Listings links list (the same as all other types of portal listings), but the HTML content itself will be added in a separate document library called Portal Listings Data, which is created to hold this additional data. Inside the Portal Listings Data document library a web part page with a single content editor web part is created and added to display the HTML content.

All three of these portal listing types can be migrated when using Metalogix Content Matrix, and all three can be done in a single step. However, there are some limitations when migrating portal listings. These limitations mainly come into play if using a Native Web Service (NWS) connection to the SharePoint 2003 source, instead of using a Database (DB) connection.

Connection icon

If the NWS connection is used to the source it will not be able to fetch the Last Modified By value for the data. The last modified date would be copied, but not the last modified user. The NWS connection would also run this type of migration much slower, as it can only fetch the listing IDs (and some other metadata) one file at a time, and cannot fetch them in bulk. And lastly, if using the NWS connection on the source there is a group field that Metalogix Content Matrix cannot fetch the values for, so if any customizations have been made to this field, they will not be preserved.


NOTE: When this option is selected as part of a site level migration the Link Correction and Comprehensive Link Correction options under the General Options tab are both checked and disabled because they are required for migrating portal listings.

How Site Features Are Migrated

Metalogix Content Matrix can copy over site features and activate them as a part of a site level migration. Metalogix Content Matrix does not actually copy over the feature itself, it only adds the feature to the target site and activates it.

In order for the feature to be added to the target site it must first be manually installed and available on the target server. If the features from the source do not exist on the target, the migration of features will fail, but the remaining content will continue to copy over.

How Managed Metadata, Terms, and Term Stores are Migrated

Metalogix Content Matrix can copy managed metadata values for items and copy and map term stores from a SharePoint 2010, 2013, 2016, or Office 365 environment into a target SharePoint 2010, 2013, 2016, or Office 365 environment (when an Office 365 Tenant connection type is used).

Managed Metadata term stores are created through SharePoint Central Administration, and consist of the following managed metadata: Groups, Term Sets, and Terms. Term stores cannot be created by Metalogix Content Matrix, which means that the target side term store must be manually created before any content is migrated. After a term store is created on the target, all the managed metadata and term hierarchy structure from the source can be migrated.

Connection icon

You can migrate Managed Metadata using any of the following connection types:

·Object Model (OM) Connection - This is either a Local or Remote (Extensions Web Service) connection type and can be used for SharePoint 2010, 2013, and 2016 source/target environments.

NOTE:  You can also use either of these connections to migrate managed metatada using GUID Mappings, which may significantly improve performance over choosing to Resolve by Name and Hierarchy, which requires Metalogix Content Matrix to crawl through the entire term store.

·Office 365 Tenant Connection - This is a server level connection to an Office 365 Tenant environment. If using an Office 365 Tenant environment as a source, this is the only connection that can be used. If using any other environment as a source, this connection type can only be used as a target.

·Client Side Object Model (CSOM) connections  This connection type can only be used by Office 365 environments, and can be used for either a source or target connection.

·Database Connections - This connection is only supported as a source connection for the migration of metadata using GUID Mapping . There are prerequisite actions to be performed before using this connection type.


You cannot migrate managed metadata when the source connection is NWS, because neither term store migration nor GUID Mapping is supported.

How Users and Permissions are Migrated

Metalogix Content Matrix can migrate SharePoint permissions. Permission migration is broken down into two pieces: permission levels, and user/group permissions. This section will review how to migrate permissions for users/groups.  Metalogix Content Matrix can migrate site, list and item level permissions from one SharePoint instance to another.

There are two methods of migrating permissions. The first method is to copy permissions as a part of a migration action by selecting them in the Copy Options dialog, and the second method is to copy them to a target node using the context (right-click) menu as a separate action.

When talking about permissions in SharePoint it is important to keep in mind that there are three different aspects of permissions to be considered when doing a migration. They are as follows:

·Roles - These are also known as permission levels, and are a collection of rights that can be assigned. In SharePoint, it is possible to create custom permission levels (or custom roles). Content can migrate any custom Roles.

NOTE: Custom permission levels (Roles) cannot be migrated to target SharePoint 2010 environments if the target is using a Native Web Service (NWS) connection type.

·Securable Objects - These are basically permissions or rights that can be assigned to an object in SharePoint. Only users or groups that have the same level of permissions or higher can access the content holding these permissions. Metalogix Content Matrix can migrate permissions on securable objects at the SharePoint site, list, folder, and item levels.

·Principals - These are permission roles that are assigned to a user or group. In order for a user or group to have access to a secured object, they would need to have the same or higher permission rights as the permissions on the object. Users can also have access to a secured object if they are a part of a group that has access through its assigned permission level.

When permissions are migrated, an algorithm is used to find the best matching permission level (role) on the target, as compared to the source. For example, if a permissions level exists on a source SharePoint environment, and permissions are migrated to the target, Metalogix Content Matrix will look on the target for the closest matching role. Whatever the closest permission level is (by included permissions) will be the permission level that is used on the target. In the case that permission levels (roles) are also migrated, these migrated permission levels will be used, because these created roles will have the closest matching permissions when compared to the existing permissions on the target. If permission levels are not copied, the closest matching permission level will be used instead.

NOTE : Whenever Metalogix Content Matrix copies content, it will migrate the user groups that are associated with the migrating content, provided they have not already been copied to the target server.

Related Documents