The Experts Conference (TEC) takes place virtually on September 1-2, 2021. It’s a free event dedicated to sharing practical information about running Microsoft cloud and on-premises services. We’ve asked each of the TEC speakers to write about a topic close to what they’ll be speaking about during this conference. This is the second article in the series. Join us at TEC to hear even more valuable information!
If you have an upcoming merger, acquisition, or divestiture and need to migrate an Office 365 tenant, this article reviews how to scope your project and choose the right tools based on the specific workloads involved.
Keys to a Successful Migration Project
Scoping and planning are instrumental for a successful migration project. Duration and cost are always key factors, with architects and administrators making crucial decisions after evaluating the choice between native vs paid tools to recommend the right approach.
This article covers where Microsoft native tools can be a good fit, and where paid tools could be the better option. More importantly, we review how to scope your project and map them to these options.
Basic scoping process
In 2021, we celebrated ten years of Office 365! As far as tenant migration options in the platform’s early history, scoping was straightforward. Looking back on some legacy materials, three key factors would enable a strong baseline for planning:
- Enabled — How many users are enabled for each service/workload?
- Data volume — How much data is in that particular workload by user or container?
- Activity — How active is the workload or pieces of that workload?
This basic process was often sufficient to answer basic scoping questions like:
- If we have 80,000 users in the source tenant, and 400 users have Yammer enabled but only 30 have recent activity – do we really need to migrate Yammer?
- Let’s say we have 5,000 SharePoint sites, and one site is massive but has very little activity. Should we migrate this site before or after all the others, so that more sensitive areas can go first?
- If we have 80,000 users but only 10,000 have OneDrive provisioned – should we do a focused communication on OneDrive instead of sending this information to everyone?
Advanced Scoping Process
A lot has changed in the past decade in both the Office 365 ecosystem and the businesses we IT pros support. While the basic scoping exercise is still worthwhile, it’s more valuable as a broad summary and for uncovering potential issues.
In the current climate, a more advanced scoping process is required, for two main reasons:
- Increased adoption — With the COVID pandemic, features that were barely used a year ago (such as Microsoft Teams) are now a significant part of a users’ everyday work. Therefore, migration projects are addressing more workloads crucial for day-to-day business.
- New APIs — Although there are legitimate complaints about the lack of APIs for migration, the situation is getting better all the time. Previously, we did not need to scope beyond the basics above because an extensive list of “stuff” simply had to be left behind. Now, more workloads can be migrated more effectively.
As a result of these changes, administrators now find themselves performing comprehensive scoping exercises that dive into which sub-features users are using, vs. simply performing a basic workload analysis.
Workload-by-Workload: Native or Paid Tools?
Here’s where the free vs. paid tool debate comes in. If the free tools are sufficient, and you have the staff to support and monitor the tools – that situation seems self-explanatory.
However, these migration scenarios are extraordinarily complex, and most will find they quickly gravitate toward the paid tool category.
After an advanced scoping process is completed (advanced, meaning a deeper dive into what sub-features users are utilizing and not just a base-workload analysis) you should have a fairly good idea as to the features required for your migration solution.
Some organizations might find that the free tools handle their needs, and also have the staff to support them. It’s important to note that using native tools can still be relatively complex as many new features remain locked away in preview programs, therefore it’s risky to rely on them in production.
Recently, I explored some of the challenges of using a feature in a preview program in a blog post about the SPO Rename feature. It’s imperative that you pay close attention to the limitations that preview programs can have, as well as the associated risks.
It’s also important to keep in mind there’s advantages to using one tool for all your migrations, vs. different tools for different workloads. Third-party tools also tend to have superior reporting and management features, which can prove to be very beneficial.
Next, let’s dive into the workloads that might be included in your tenant migration project and how to choose tooling that will meet your needs.
Of all the Office 365 workloads, Exchange is by far the closest to a native tenant-to-tenant migration solution. Microsoft demoed its first cross-tenant mailbox migration via the Mailbox Replication Service (MRS) at Microsoft Ignite 2017, and at Ignite 2020, the feature went from private preview to public preview.
MRS can be a good option if you have a small number of users without a lot of complexity. Projects where Exchange comprises the majority are great candidates. However, preview programs should only be used in limited situations. For large, sensitive, critical, or time-sensitive projects, the cross-tenant MRS preview program will not be the best fit and a third-party migration solution might be worth the investment.
One Drive for Business and SharePoint Online
In 2019, Microsoft acquired Mover. This tool is free to Office 365 tenants and allows you to migrate SharePoint between tenants. The tooling’s primary focus is migrating third-party data into Office 365; however, you can use this free tool for some tenant-to-tenant migration scenarios.
While Mover works well for basic file migrations, if you have more complex requirements, you will need to consider a third-party migration tool. At Ignite 2020 there was a demo of cross-tenant SharePoint migrations, but unfortunately, we have not seen a preview program for this process yet.
At the time of writing this article, no native tools exist for Teams migrations. Therefore, in order to have a successful migration, a third-party Teams migration tool is essential. Due to current events and the rapid adoption of Microsoft Teams globally, you can see how this is becoming a major issue.
Identity, Routing and Endpoint Configuration
There’s one more set of factors when choosing your migration tools: how you will handle identity, routing, and endpoint reconfiguration.
Your project will involve migrating identities from one tenant to another, and your choice of tool will be influenced by your answer to this question: Will you be maintaining two directories or spinning down the old directory with the migration?
- If your organization requires long-term co-existence, you will likely need a third-party product to ensure the directory stays up to date as employees come and go or change roles within your organization.
- If you anticipate a quick migration without many users, you can rely on either custom scripting or your current process to create the objects for identity creation. In this case, you may find yourself doing a lot of one-time scripts, updates and more; however, for a one-weekend project, it might be worth your time.
Routing and domain considerations
Sharing the SMTP domain across tenants is also in preview. The preview program covers only email, which might be enough for you. However, be cautious with mail routing, and because in this space, you also need to be very careful if you choose to use address re-write, which will add a hop in your email flow. Every time you add a hop, you add a potential outage point. Depending on your configuration, you may have existing solutions and if you do not, you may need to rely on a third-party option.
As with the need for an identity sync product, if you are going to migrate in one weekend, you may not need tooling to help you with your domain. You might be better off ejecting the domain in the maintenance window and just importing it into the target defined as domain cutover. Domain moves are easier said than done, but for some organizations, this is the right plan.
Microsoft provides no native functionality to force endpoint reconfiguration. As a best practice, we advise clients to revoke all logon tokens during the maintenance window, but this will not handle the complete reconfiguration of user devices.
In fact, endpoint configuration is a prime example of where third-party tools can provide high value.
, and the business will not be able to serve its customers.
Join us at TEC
Vanitha and I explore tenant-to-tenant migrations even further in our session. TEC is going to be full of practical sessions like this, so we hope you will attend!
*This blog post has contributions from both Vanitha Murugesan and Mike Weaver.