Skip to main content

ShareGate Migrate encryption and security

Updated this week

ShareGate puts strong emphasis on data privacy and security, and this article outlines how some of your data is handled in ShareGate Migrate.

If you want to learn more about how ShareGate handles your data, please consider the following articles:

Encryption

Microsoft 365 connections are always encrypted with HTTPS and TLS 1.2, and are currently undergoing a rollout of TLS 1.3 updates.

Connections to on-premises versions of SharePoint can be configured with different versions of TLS.

While ShareGate Migrate supports TLS 1.0, 1.1, 1.2, and 1.3 for your on-premises SharePoint server connections, we strongly recommend using the latest available version of TLS and at least TLS 1.1 if it's not available.

SharePoint 2016 supports TLS 1.2 connection encryption by default, and SharePoint subscription edition supports TLS 1.3

When you connect to a SharePoint site that uses HTTPS, the data transitioning through ShareGate Migrate will be encrypted.

When you connect to Microsoft 365, your connection is always encrypted.

Important: TLS 1.0 is considered vulnerable and can cause connectivity issues. SSL 3.0 and RC4 are no longer supported. A security vulnerability was identified in the SSL 3.0 protocol that could allow an attacker to decrypt data transmitted over it. For enhanced security, some SharePoint features now turn off SSL 3.0 connection encryption by default, as well as certain encryption algorithms with known weaknesses.

Insane mode migrations to a Microsoft 365 destination

Microsoft 365 also encrypts the data that transitions to Azure when you use Insane mode for your migrations.

When your data is moved to Azure through this process, Microsoft utilizes the advanced AES CBC 256 standard encryption, which renders the data unreadable to any potential attacker.

Encryption is done on your content before the upload, on the machine running ShareGate Migrate. The encryption key is then given to the service at the destination.

Once the migration is completed and the data has been successfully uploaded to Microsoft 365, your data will be deleted in Azure within one week, as this is the default retention period for Azure storage included with your Microsoft 365 subscription.

To learn more about how your data transits to a Microsoft 365 destination in Insane mode, see our SharePoint to SharePoint migration diagram.

If you use a custom storage for this process, you must manually delete the encrypted data in your Azure storage account. For instructions on deleting content in your custom Azure storage, see Clear data in your Microsoft Azure storage account.

Access to your environments

To use ShareGate Migrate, you must connect to your environment with permissions that vary from simple member to global admin, depending on whether you are on the source or destination and the actions you want to perform.

The application operates through APIs, working on your behalf. While your network can identify these operations as an application performing actions, rather than you directly interacting with it, the application does not access more than what your signed-in account can.

To determine the permissions required for a ShareGate Migrate user, refer to the Administrative Permissions documentation.

Connections

ShareGate Migrate requires that you connect to your environment when you start running operations in the desktop app.

When connecting with the Other user connection method, an encrypted version of your credentials is stored. For the other connection methods, ShareGate preserves the authentication cookies locally. ShareGate Migrate will not save the credentials themselves.

For more information, see Connect to SharePoint and Microsoft 365.

Server extension

To improve performance, it is recommended to install the server extension on your on-premises SharePoint servers. Like any web service, it is executed by an authorized user in ShareGate Migrate.

Did this answer your question?