Preserve User Values During SharePoint Migration

Stéphanie Pelland

WRITTEN BY STÉPHANIE PELLAND

Since the publication of this article, Sharegate has updated and unified the migration interface of its Desktop Tool. The following screenshots may no longer be accurate, we are working on updating them.

We all know that employees come and go, but for many reasons you may want to keep records of their contribution even if you are moving to a new SharePoint environment. You might also want to know if moving to a new domain will require plenty more of work.

Keep SharePoint Users Values When Migrating Them

What you basically need to know is that all the users and groups will be automatically mapped with existing users or groups on the destination site with the same account name (without considering the domain). If no match is found, the mapping will be done by display name.

For example, domain1john will be automatically mapped with domain2john, since the account name is the same. Also, domain1john will be automatically mapped with domain2john-doe if both users’ display name is "John Doe". Sharegate uses the ''People Picker'' of SharePoint to search for matching users at your source and destination. You don’t have to worry if you are migrating from a classics based authentication to claim-based since for Sharegate the format of the token doesn't matter, it will ensure to find the right user (or group) whether it is:

DOMAINuser

user@domain

i:0#.w|domainuser

i:05.t|issuer name|user@domain

etc.

But there’s one important notice here, if you have two users who are called John Doe, the mapping options will be pretty relevant in your case in order to make sure Sharegate correctly resolves your users.

Map SharePoint users to the Destination Active Directory

If for instance, John Doe has left the company, obviously Sharegate won’t find him in the destination Active Directory since the user has to be activated. What happens next? By default, John Doe will be map to the user who is performing the migration and Voilà! You will also be able to find warnings within your migration report stating that John Doe could not be found at the destination, so the current user has been assigned.

What if you would like to modify this default behavior because Jonathan Perry replaced John? If so far no one could step into John Smith’s position, select a user (or even create a user at your destination Active Directory) that will be a fallback for John and any unresolved user or group to map to at the destination or simply map John for Jonathan.

In another case figure, let's say you absolutely need to keep track of John's contributions, perhaps for historical or legal reasons. There is actually a way to do it! First, create two columns ‘Single line of text’ in your destination library.