Should you do a tenant migration after a branding change?

/

Many businesses that use Microsoft 365 go through changes that result in the branding and company name evolving. These changes can include acquisitions, mergers, demergers as well as brands and companies changing their names.

When this happens, the tenant name chosen when setting up your original Office 365 will not be appropriate. Also, the original tenant name itself cannot be changed. This is then visible in various places (primarily URLs for OneDrive and SharePoint) to end users and contacts you share information with.

In such situations, there are three approaches:

  • To migrate to a brand-new tenant, normally using migration tools or services to take as much data as possible

  • To change the SharePoint domain name using a relatively new feature of Microsoft 365.

  • Do nothing and accept the name may not reflect the new branding.

As a very high-level summary to provide some context to the later discussion, here are the pros and cons of each.

Pros Cons
Tenant migration A “fresh start” approach with no legacy of the previous domain name. Complex and costly, with not all data types able to be migrated. All users and their data must migrate in one “big bang” event.
SharePoint domain change A relatively simple change without the upheaval of migrating data. There are some limitations and items that may impact users and a few instances where a domain change cannot be done.
Do nothing Very simple to achieve. The name seen in some places will be an old name which will not match your new branding.

The SharePoint domain name is the text that appears in the URL for SharePoint locations (e.g. TENANTNAME.sharepoint.com) and in the URLs of sharing links and OneDrive, to name a few. These are the most visible places where a user would ever see the tenant’s name.

Microsoft has some guidance on how to change your SharePoint domain name.

At first glance, that list may look intimidating and might lead the reader to believe that tenant migration is the safer option. However, there are only a small number of cases where ComputerWorld believes that to be the best option.

In almost every case, the affected items would still need to be addressed after a tenant migration. Also, for many of the scenarios affected, the data simply isn’t able to be migrated using mainstream migration tools.

If any of the points below are true for your business, then changing the domain name is not possible. A tenant migration or doing nothing would be the only possible options.

  • If your Microsoft 365 tenant is set up for “Multi-Geo” then you cannot change the SharePoint domain name. If you don’t know whether you have multi-geo, you probably don’t.

  • If your organisation uses special clouds or government clouds (GCC, GCC High, DoD, etc.), your domain name can't be changed.

  • If your SharePoint domain is, for example, teams.contoso.com (versus contoso.sharepoint.com), your domain name can't be changed.

These are some quite specific situations that mean the SharePoint domain name can’t be changed. But it wouldn’t account for many of our customers.

There are several scenarios where, if you are using certain Microsoft 365 features or services, some remedial actions would need to be completed before, during, or after the domain name change. These include:

  • Any relevant hardcoded URLs present in hub site menu items, custom apps, Project Online workflows, or Group Policy Objects; will need to be changed. Custom apps may prove a challenge.

  • Any InfoPath Forms using a SharePoint connection as a data source would need reconnecting after the change.

  • Microsoft Forms that add attachments need to be modified after the change.

  • Some of the Power Automate flows using SharePoint connections will need to be recreated.

  • Power BI reports that use SharePoint connections as a data source would need to be modified.

  • Any Project Online workflows “in flight” (i.e. being created or edited) will be orphaned.

  • Custom Excel reports in Project Online, using Project Data connections won’t work until they are reconnected.

  • SharePoint 2013 workflows will need attention.

  • SharePoint add-ins might need to be republished.

  • SharePoint hub sites need to be unregistered and reregistered as hub sites.

  • SharePoint web parts with direct URL references may need to be updated with new URLs.

  • Any relevant URLs embedded in SharePoint customisations need to be updated.

  • In Teams, any folders added, using “Add cloud storage”, pointing to an affected SharePoint site won’t work and will need to be re-added.

  • Embedded images in Wikis won’t be displayed.

  • Teams' Personal Wikis won’t work.

  • Third-party apps (including backup solutions) using absolute SharePoint URLs will need to be updated.

  • If your tenant contains old SharePoint public sites, these need to be removed.

  • Any BPOS (Business Productivity Online Suite) sites need to be removed (applicable to some very old tenants only).

  • You need to ensure that any deleted sites won’t be required. If not, restore them and delete them after the SharePoint rename is fully completed.

  • Versions of client software need to be relatively up to date. The minimum versions required are now quite generous and you’re likely already up to date.

If you are using a third-party backup solution for your SharePoint and OneDrive data, you should check for any known issues with the provider and perform a backup to ensure no failures are logged immediately after migration.

From a user experience perspective, there may be some usability quirks, including:

  • Some URLs and People Profiles can take up to 24 hours to update and become available.

  • Meeting notes can take up to 72 hours to become available again.

  • Office “recent” and “pinned” lists are updated over time and may not work as expected.

  • The local folder name in the OneDrive sync client will contain the old name until you disconnect and reconnect the app.

  • Search indexes may take a while to show the new URL.

  • There are various other quirks if the users are using the Office 365 apps at the time of the change. For this reason, we would always ensure users are notified in advance and the change takes place during a weekend or another time of low use.

  • Quick access links in OneDrive and SharePoint won’t work and must be recreated.

  • Cloud storage added in Teams that references an affected SharePoint site must be re-added, but this is an unusual scenario.

When performing a full tenant migration, Yammer, Project, Forms, and many other types of data are simply not migrated using mainstream tools. We are aware of at least one tool that migrates some items that are not directly supported by Microsoft’s APIs. However, there are concerns about future supportability and compatibility when these tools have been used.

Overall, we can see that there are several things to consider when proposing a domain name change. However, for most Microsoft 365 users, a domain name change would lead to a much simpler project, with significantly less user impact compared to tenant migration.

If you are considering either a domain rename or a full tenant migration, please speak to us here at ComputerWorld.