Quest Tool Migrates Protected Email and Files Between Tenants

Solves the Problem of Migrating Data Protected by Sensitivity Labels

I’ve worked as an advisor with Quest for several years, but I had no indication that they would launch a product to migrate content protected by sensitivity labels from one Microsoft 365 tenant to another. That capability is now available in Quest On Demand Migration.

The tenant migration issue has existed since Microsoft introduced Azure Information Protection labels (now sensitivity labels) in 2016. The problem doesn’t arise with labels that simply mark content as being of a certain nature. It comes into play when sensitivity labels apply rights-management based encryption where usage rights define the level of access granted to individual users for protected files or messages.

The popularity of sensitivity labels has increased over time as more tenants come to understand the value of protecting their most sensitive content using the labeling features built into the Office apps. It’s true that labeling only extends to Office documents and PDFs, but that set covers most files created within Microsoft 365 tenants.

The advent of Microsoft 365 Copilot and its ability to find and use files stored in SharePoint Online and OneDrive for Business means that sensitivity labels are even more important. By themselves, sensitivity labels won’t stop apps like BizChat finding sensitive documents, but they can stop Copilot reusing content from those documents in its responses. The DLP policy for Microsoft 365 Copilot imposes a better block by stopping Copilot finding documents assigned specific sensitivity labels.

The growth in protected content creates a problem for tenant-to-tenant migration projects. Many products are available to move Exchange mailboxes and SharePoint files between tenants. However, migration products usually assume that the data they move is unprotected and that users will be able to access the content once it reaches the target tenant. That assumption doesn’t hold true when sensitivity labels protect email and files. The challenge is to move protected items from the source tenant in such a way that protection is maintained and respected by the target tenant.

Methods to Remove Sensitivity Labels from Files

Until now, the guidance for source tenants is to remove protection from content before migration to the target tenant. There are a couple of ways of doing this, starting off by assigning an account super-user privilege to allow them to remove sensitivity labels from files. Finding and processing protected files is an intensely manual process that’s prone to error. It will take a long time to prepare, move, and check any reasonable collection of labelled files, like the 5,188 items with the Public label as reported by the Purview Data Explorer (Figure 1).

The SharePoint Online PowerShell module includes the Unlock-SPOSensitivityLabelEncryptedFile cmdlet. Administrators can use the cmdlet to remove protection from files in SharePoint sites and OneDrive for Business accounts. It is possible to script the removal of labels from files, but the automation journey breaks down when the files reach the target tenant and need to be relabeled.

SharePoint also supports the assignSensitivityLabel Graph API, which can remove or assign labels to files. However, assignSensitivityLabel is a metered API, meaning that each time the API is run, Microsoft charges $0.00185 (USD) paid for through an Azure subscription. That doesn’t seem like a big fee until the need exists to process tens of thousands of documents to remove labels in the source tenant and reapply labels in the target tenant.

No Solution for Protected Exchange Messages

Note that Exchange Online is missing from the discussion. That’s because all the methods described so far don’t handle email. I don’t know how clients like Outlook and OWA apply sensitivity labels to messages (it’s likely done using APIs from the Microsoft Information Protection SDK), but no cmdlets or Graph APIs are available to remove labels from messages or apply sensitivity labels in bulk to a set of messages migrated in mailboxes moved from one tenant to another.

Migrating Protected Content Between Tenants

All of which means that Quest’s claim to migrate protected content from Exchange Online, SharePoint Online, and OneDrive for Business is very interesting. It’s the first ISV migration offering that I know of which offers such a capability.

Reading the announcement and the accompanying Quest Knowledge Base article gives some insight into how the On Demand product handles protected items. A discovery process (like running the Get-Label cmdlet) finds the set of sensitivity labels in the source tenant. The labels from the source tenant are mapped to labels in the target in some form of table. Normal migration processing moves the data, and some form of post-migration task then updates the labels from the source tenant to matching labels for the target. Quest doesn’t describe what magic is used to make sure that protected content works when it reaches the target tenant, but the knowledge base article mentions the Microsoft Information Protection SDK, so it’s likely that On Demand uses MIP SDK API calls to read and update sensitivity labels for the migrated items.

User-Defined Permissions and Keys

Although creating the capability to move protected content between tenants is a great step forward for migration projects, there are always edge cases to consider. Sensitivity labels with user-defined permissions are an example. These labels are challenging because the permissions vary from item to item. SharePoint Online only recently gained support for sensitivity labels with user-defined permissions, and it’s interesting that Quest claim support for user-defined permissions out of the box.

Quest doesn’t mention sensitivity labels with double-key encryption (DKE), nor do they explain if On Demand supports migration of sensitivity labels with encryption based on customer keys rather than Microsoft-managed keys (sometimes called bring-your-own-key or BYOK). There’s a bunch of complexity involved in moving key management between tenants and it would be surprising if Quest supported BYOK. Thankfully, most customers use Microsoft-managed keys with sensitivity labels because it simplifies operations.

Let the Competition Begin

Overall, it’s great that an ISV has taken on and solved the challenge of moving protected content between tenants. The nature of competition is that once a migration vendor introduces a new capability, their competitors respond. We might see even more interesting developments in this space over the coming months.