Office 365 Tenant to Tenant Migration Challenges – Sharing Links

Performing an Office 365 tenant to tenant migration is incredibly difficult for most IT teams to accomplish on time and without major issues. One reason they are so complicated is that many of these projects are the result of Mergers, Acquisitions, or Divestitures (MAD).

Many organizations undergo multiple MAD transitions in a short period of time, or in spurts, which makes the situation even more difficult from a migration standpoint. There is a multitude of problems that can and will arise, but during the tenant to tenant migration process, a major issue that we see time and again is around sharing document links from OneDrive for Business and SharePoint.

It is understood that collaboration is a key benefit to Office 365, and one of the reasons why so many organizations have adopted the platform. Not only does it increase the ability for one to collaborate within the organization, but it also enables collaboration options outside of your organization. This efficient way to work in the concert has no doubt transformed the ways in which we function.

However, this increased functionality can subsequently create many problems for the same users during and after a tenant to tenant migration. Although it may make your life a lot easier in the short-term by being able to initially share these links, unfortunately in the long-term these links will break. And for a multi-tenant migration projects, they break much more frequently.

In this article, I will cover the four main issues you’ll see around sharing links in Office 365 and what happens to them during a tenant to tenant migration. This type of link sharing includes:

• Internal Sharing
• External Sharing – Inbound
• External Sharing – Outbound
• Internal External Sharing

Common headaches with these issues

Sharing links are accompanied by common headaches that will repeatedly be encountered during tenant to tenant migrations. Regardless of the sharing type, all aspects of sharing outside of inbound anonymous links are impacts. Even if you move the domain, these links will stop working. At the end of the day, a domain move makes an account ‘look’ like the same account, but this is indeed a different object, with a different storage location, in a different tenant. This is the crux of these sharing issues. 

Let’s examine these issues in more detail:

Storage Location Change

It is important to keep in mind that sharing links point to a particular tenant. If you look at a link-sharing URL, they look like this:

When you look at the open button you will see this:  https://<TENANTNAME>-my.sharepoint.com/:w:/g/personal/<UPN>/EabDJRGcFpRFvCSCFSs9PfUBUR2teXQtvBCzALILQwSoGA?rtime=q34MX6zU10g

During the migration, the tenant/storage location is changing, and the result is these links will break and the end-user will see a ‘not found’ error message. This is the same behaviour as if we deleted an account, because that is exactly what we have done in the source environment!

Out of Date Permissions / Change-to Policy

There are two compliance issues to keep in mind here.  One is out of date permissions, and the other is a difference in sharing policies.

We often share documents, but rarely do we go back and restrict access to what has been shared.  As a result, if the policies have been loose over the years, we can have scores of out of date permissions. This has plagued Exchange administrators for years, and OneDrive/SPO sharing is not exempt from this. The ease of sharing documents does not have an easily paired activity to removing sharing.  As a result, this creates a scenario of out of date permissions. 

For some companies, this will help ensure the source tenant is now compliant with the target policy.  This really is a ‘making lemons out of lemonade’ type of answer, but for situations where the target tenant has a stricter policy, it rings very true.

I have recorded a helpful video that guides users through how to see what documents have been shared with them, and what they have shared. It is in my communication templates and can be found here:

Types of sharing & the impact post-migration:

• Internal Sharing
  • Impact: You will need to reshare post migration
  • Communication: Can be included in communications to all users
  • Other Options: Report on heavy sharing and reach out to power users

• External Sharing – Inbound
  • Impact: The external party will need to reshare post-migration
  • Communication: Guide users on how to locate this in communications to all users
  • Other Considerations: This is difficult to detect and is often overlooked. If the link was an anonymous link, it will continue to work – making communications more complex.

• External Sharing – Outbound
  • Impact: The user needs to reshare this post-migration
  • Communication: Guide users to see what active documents need to be re-shared
  • Other Considerations: Creative reporting can help detect activity and allow for targeted communications

• Internal External Sharing
  • Multi-Tenant: Get yourself a coffee, tea, chocolate, or drink of your choice, because this is where the problem gets worse and requires a long explanation…

Internal External Sharing

Since there does not seem to be a standardized term for this yet, I’ve coined the phrase ‘Internal External Sharing’. This occurs when someone has shared something external to the tenant but is, in fact, an internal user in another owned tenant.

In single tenant to tenant migration projects, this is usually someone collaborating with the target tenant pre-migration, or among themselves in the source. These situations fall into the internal sharing process above, but the user will need to use the ‘Internal’ sharing process instead of external, post migration.

However, if you have multiple tenants, this is where things become much more difficult. So, take a deep breath or a big sip, and buckle in.

Example:

1. Let’s say the target tenant is Z, so we are all trying to get to Tenant Z. Meanwhile we have Tenants A & B that need to migrate. Users in Tenant A are sharing documents with users in Tenant B and Tenant Z.
2. One weekend we migrate Tenant A to tenant Z. On Monday morning, users form Tenant A will need to reshare documents with users in Tenant B and Z. Users in Tenant B and Tenant Z will have to reshare any documents they own with the users of Tenant A, but are not in Tenant Z, and may have a new account name, if everyone took on the new branding.
3. Two weekends later we migrate Tenant B. Can you see the problem? Now on Monday morning, everyone has to reshare AGAIN!
4. Now imagine you have 20 tenants. That is a lot of sharing, resharing, communication, lost productivity, and frustration – OUCH!

To try and avoid this, it is important to scope this information as best you can. At Quadrotech, we use reporting data from our Nova Office 365 management software to scope this beforehand so our customers can prepare their email communications. 

Understanding this situation will help you minimize disruption, and keep in mind that this is where proper communications and planning comes into play. Just know that these issues are common and cannot be avoided altogether in Office 365 tenant to tenant migrations, but how you plan for and communicate them can minimize disruption and confusion.