Part 2: What Workloads Can Be Migrated

What (Common) Workloads Can Be Moved

The most commonly used workloads might be Exchange Online, Teams, SharePoint Online, and OneDrive for Business. As in the Microsoft cosmos, the Exchange Mailbox should always be the first workload for migration because several other features rely on the mailbox itself. Also, email was the first workload that could have been migrated to Microsoft 365 and it is still the biggest one. Teams’ one-to-one chats are stored in the mailbox itself; documents and files will be stored in SharePoint Online. OneDrive for Business is a storage within the personal SharePoint Online site, so all of them work closely together.

Note that the complete content of a workload cannot always be migrated. You might already be familiar with some migrations and for example, if you simply move a file from your on-premises file server to SharePoint Online, permissions and sharing flags will not be preserved. The same is valid for third-party migration tools where you clearly have to define your business needs as mentioned in Part 1 of this series. Furthermore, almost every workload can be “moved” but this doesn’t mean all data and configuration from the source will be completely identical in the target.

Before we continue, let’s first divide the migration challenges into three parts: 1) Microsoft native migration capabilities, 2) independent software vendors (ISVs), and 3) manually with the help of PowerShell, Graph API, and other free tools.

Microsoft Native Migration Capabilities

As of April 2021, Microsoft has no built-in solution (which is generally available) on how to migrate data between one or multiple Microsoft 365 tenants. Although Microsoft is still working on some migration features, the only available public preview is the cross-tenant mailbox migration capability. Microsoft is also working on SharePoint Online and OneDrive for Business cross-tenant migrations, which was announced at Ignite 2020 and is still in a private preview (https://aka.ms/SPOMnAPreview).  More information about the plans from Microsoft regarding cross-tenant migrations can be found here.

Independent Software Vendors (ISVs)

ISVs provide organizations with software to help accomplish their individual goals with features and services that run on on-premises hardware or as SaaS in the cloud. For migration related software, they often rely on the Microsoft management API capabilities to move data from one Microsoft 365 tenant to another. There are many vendors in the wild and each of them provide (more or less) workloads that can be migrated. I can’t stress enough that you should write down all your organization and business needs and then do a feature-comparison with at least three different ISVs and verify what works best for you and your users. Another important basis for decision-making is how the ISV will migrate your data, for example if they provide a managed migration service or if you must use the tool. I really like the managed migration service approach – even if it might cost a bit more – no one in your IT department should be deeply familiar with migration tools, which means it could take a while until all involved people are able to use the tool properly and how they should proceed in case of issues and errors.

Even if manufacturers use the same APIs, there are significant differences in the migration process. ISVs can often map additional processes as well without manually observing or changing the sequence. For example, in a Teams migration, guests are read from the old tenant and automatically invited into the new tenant and added back into the migrated Team. Of course, software vendors don't just want to bring the migration itself to the customer, because migrations are often one-time activities, which also means one-time income. SaaS applications or continuous, monthly revenue (based on a licensing model or similar) are obviously better from an economic point of view. That's why some migration tools are also a combination or only available in combination with other services.

Further, compliance regulations are important to understand and distinguish. Do manufacturers use their own cloud to temporarily store migration data if necessary, or do they use the customer's cloud? Does data leave the site or country during migration and how long is data possibly cached? All these things are important to clarify and understand, so transparent communication is essential.

Manual, PowerShell, Graph API, and Other Tools

Even if no API for export and import is provided by Microsoft, it does not mean that the data cannot be "migrated" from Tenant A to Tenant B. In this case, our own PowerShell scripts or already developed scripts from the community help us.

Note: ISVs cannot respond to all individual customer wishes, because then every software product sold would be an individual solution. After more than 50 tenant to tenant migrations, I can say that not one of them had an identical pattern or treated all data the same. The following list provides my personal script repository

The following list is an overview of my most used migration scripts from the community:

Planner Tenant To Tenant Migration by Alexander Holmset

- Lots of great content in Tony Redmond’s GitHub script repository “Office365itpros”. For example, use Find Old Guest Users by Tony Redmond which can be used in the target tenant to invite and add your guests back to the Groups and Teams.
- Michel de Rooij provides also great GitHub content, like the Clear-AutoComplete script which allows you to clear one or more locations where recipient information is cached.

There are more great PowerShell scripts out in the wild. I do not want to and cannot respond to all of them. PowerShell knowledge must be present in any case, for example to customize the UPN for all users, export mailbox permissions, etc.

Azure Workloads

Keeping track of the Azure part at all already seems like a very difficult task. The related parts in Microsoft 365 are - in most cases - mainly policies and configurations. For example, Conditional Access, Azure Automation, Risk Detections, Enterprise Applications, etc., are part of it. In addition to these Microsoft 365 parts, however, there are countless other services and applications in Azure that provide enterprise data.

The entire Azure part would exceed the scope of this blog entry. But think of the possibilities to migrate the data from Azure in the same way as you migrated it from on-premises to Azure: lift-and-shift for virtual machines using Azure Migrate, re-innovate or rearchitect the PaaS applications (e. g. an application in an Azure Kubernetes cluster, which can basically be repackaged into a Docker image, can be uploaded, and deployed to the new tenant). However, Azure also includes a large part of networking, possibly Azure Express Route, firewall, application gateway, etc. and from my point of view these different Azure services and subscriptions need to be considered differentially. For Azure, a company will have to operate several tenants in any case - at least at the beginning.

Summary

ISVs not only migrate data from A to B, but they also help with planning, communication and - due to the immense experience of previous migration projects - usually know most, if not all, of the pitfalls. Until Microsoft fully releases the tenant to tenant migration (and we don't know yet in which feature set it will be released), I can personally highly recommend the help of ISVs. Automating the most used workloads for migration is a huge help, especially for managed migration services. For all individual requirements PowerShell is the agony of choice and due to the numerous scripts from the community almost without exception all data from a Microsoft 365 tenant can be migrated.

---