ShareGate Migrate automatically associates users between your source and your destination during a migration. This automatic association can affect permissions and Person or Group metadata fields such as Modified by.
Tip: You can map your users and groups manually. The users and groups you do not specify in your mappings are mapped automatically. To map your users with ShareGate Migrate, see Map users and groups.
Index
How ShareGate Migrate resolves users from the source to the destination
ShareGate's migration tool extracts the following information for each user account from the source:
Account name.
Display name.
Email.
Note: Only the account name is extracted when you migrate from a file share.
Once the information is extracted, ShareGate Migrate goes through the user accounts at the destination and looks for complete matches with the properties below in the specified order. These properties are:
Exact same account name.
Same normalized account name (without claims header).
Same login and domain.
Same login.
Same login and domain (source login read from display name - this can happen when importing from file system because the account name is set as the display name).
Same login (source login read from display name - this can happen when importing from file system because the account name is set as the display name).
Same email address.
Same display name.
PrincipalType is not set or is a security group and the same display name without a domain.
The moment a matching property is found, the destination user account is considered a match and is mapped to that source user account.
If no complete match is found, an algorithm is used to look for partial matches of these properties.
Note: If you use any kind of redundant word in the account name, or if you have certain users with multiple matching names, you could get user mismatches with the algorithm. To resolve that problem, you can create a company-wide user mapping file. You can extract the user information from your Active Directory and use that data to generate a mapping file with PowerShell.
How ShareGate Migrate resolves groups from the source to the destination
SharePoint group
ShareGate Migrate searches for a SharePoint group of the same name at the destination. If a matching group is found, that group is used.
If no SharePoint group is found, ShareGate Migrate looks for an Active Directory security group of the same name. If a matching Active Directory security group is found, that group is used in the destination.
Using Copy structure and content, if no matching Active Directory security group is found, ShareGate Migrate migrates the SharePoint group with its members as long as the users are available at the destination.
Active Directory security group
ShareGate Migrate does not migrate Active Directory security groups; instead, it searches for an Active Directory security group of the same name in the destination. If a matching group is found, that group is used. ShareGate Migrate will then copy the permissions from the source group to the destination group.
If no Active Directory security group is found, ShareGate Migrate looks for a SharePoint group with the same name. If a matching SharePoint group is found, ShareGate Migrate copies the permissions from the source group to the destination group.
Note: If an Active Directory security group is already nested in a SharePoint group, the mapping option will fail because a SharePoint group cannot be added within another SharePoint group.
Considerations
Matching type
In the process of mapping your users and groups, ShareGate Migrate tries to find an entry of a matching type, such as a user, SharePoint group, or security (Active Directory) group.
If no entry of the same type is found, the app will search for a matching entry of a different type. A group can be matched to a user, and a user can be matched to a group.
Blocked sign in
If the Azure Active Directory user setting Block sign in has been applied, that user will not become a member of the destination Team or SharePoint online environment during migration. This limitation exists if the user has their sign-in blocked at either the source or the destination.
Note: The Migration report will not contain any warnings.