Overview
By Default, permissions in SharePoint are inherited from the parent site. However, you can break the inheritance if you wish to create unique permissions that will affect an object whether it is a subsite, a list, a library, a folder or any other object within your site. The key element to remember is that permissions are linked to objects.
In sum, when permissions are inherited, all the permissions are located at the top level. This allows you to manage the security easily since it is centralized. In some cases, you might need to micromanage the permissions of a specific object perhaps because it contains sensible information so you break the inheritance. Consequently, you will be able to either copy the permissions from the parent to the object so it allows you to make changes to them directly or start from scratch without affecting the rest of the site. In other words, this will ensure that the parent permissions will not affect the ones of the specific objects and vice versa.
IMPORTANT: The way permissions are assigned will influence the migration process.
Example 1
| Source | Destination | |
| Site A | merged with | Site B |
| Subsite 1 (inherits from A) | Subsite 1 (Inherits from B) |
In this scenario, ShareGate Desktop will migrate the Site A permissions to Site B, therefore you will have the same permissions at the destination as you had at the source. The destination subsite will inherit from the top level site as it is the case at the source.
Example 2
| Source | Destination | |
| Site A |
|
Site B |
| Subsite 1 (inherits from A) | migrated to | Subsite 1 (Inherits from B) |
In this scenario, it is important to first think about which permissions are needed at the destination. Since if Sub1 (that inherits the permissions from Site A) is migrated directly then it will result in a "Subsite 1" that inherits all its permissions from Site B. In other words, all the Site B users will have access to the "Subsite 1" subsite even though they did not have access to it at the source.
This happens because the actual site that had unique permissions was not migrated but only its subsite that inherited the permissions from it. ShareGate Desktop's behavior in this case is to simply let the site inherit its permissions from its parent, as it did at the source. Since the new parent site at my destination does not have the same permissions as the old parent site, the subsite now has different permissions. If those are not the desired permissions, you can either break the permission inheritance in the source site in order to have unique permissions prior to the copy, or define the permissions at the destination after the copy so that only the desired users have access to Sub1.
Example 3
| Source | Destination | |
| Site A |
|
Site B |
| Subsite 1 (unique) | migrated to | Subsite 1 (Inherits from B) |
In this scenario, "Subsite 1" is migrated as a subsite of Site B as above but in this case "Subsite 1" has unique permissions. The best practice in this case is to first migrate the groups in order to make sure that they are available and up-to-date at the destination. Once the groups are migrated, the next step is simply to migrate the subsite and its custom permissions will be migrated along with it.
Finally, if you have already made changes to the permissions at the destination and you would like to preserve them but you still need to migrate your site, you simply need to deselect the custom permissions option. If the custom permissions option is unchecked, the destination permissions will be preserved.