Tenant-to-tenant migrations are increasingly common. Some are necessitated by business changes like mergers, acquisitions, and divestitures, while others are driven by the desire to clean up or consolidate the IT infrastructure to facilitate business processes and reduce administrative overhead.
How can you ensure your tenant-to-tenant migration is successful? As with any migration, the key is proper planning. There are lots of detailed materials that can help you get started. In particular, Microsoft provides guidance about architecture approaches for common business scenarios, and a blog post I published on Practical 365 has advice about scoping your project and choosing appropriate tools based on the workloads involved.
Today, however, I’m going to go broad rather than deep, and offer my top seven tips for planning your next tenant-to-tenant migration.
Tip #1. Choose what’s right for your environment: a batched migration or a cutover migration.
One of the most fundamental decisions for any tenant-to-tenant migration project is whether to choose a batched migration or a cutover migration:
- A batched (phased) migration involves migrating the tenant in multiple pieces over a longer period, often several months. You group your users by department, business unit or geographical location, and migrate those groups one at a time.
- A cutover migration means migrating the entire tenant over in a single go, usually over one long weekend.
In deciding on your best approach, you have to consider your organization, the size of your migration, the workloads you will be moving, whether your organization will be able to continue to communicate and collaborate as usual throughout the project, and the amount of risk you are willing to absorb.
Batched (phased) migration
By splitting your migration project into manageable batches, you can spread out the workload impact on the project team and support staff and tailor processes and communications for each group as you go. Coexistence is key in order for your users to continue to operate as usual throughout the project — it’ll give them the sense of being part of one cohesive environment even though they’re actually operating in two or more different environments. For example, you need to make sure everyone can continue to access their mail and schedule meetings with other users, regardless of anyone’s migration status.
If your migration involves many users, this will be the way to go. You just need to be sure you’re using a migration tool that will make coexistence as simple and seamless as possible.
Cutover migration
If your organization doesn’t adhere to a rigid department hierarchy, it can sometimes be difficult to come up with logical groups for batched migration — users may wear so many hats and serve on so many project teams that it can be nearly impossible to map out who belongs in which migration group. A cutover migration can also eliminate the need to address coexistence considerations.
If this is the way you’re leaning, be aware that the APIs for migrating cloud workloads like SharePoint Online and Teams have limitations in place to protect service availability. This makes the cutover option less feasible in tenant-to-tenant migration projects, especially for today’s larger and more complex tenants.
Tip #2. Calculate the true total cost of ownership for tooling.
Both native and third-party tools and services are available to help with tenant-to-tenant migrations. Microsoft provides this nice summary of the available migration capabilities for various workloads:
Native tools can be very effective in some scenarios. However, many of them are still in preview, so they have limited support. Moreover, keep in mind that they are not free of all costs; they can actually be very expensive when you add everything up. At a minimum, you need to calculate the cost of the time that your scarce IT pros will have to invest. In addition, carefully consider all the add-ons you have to put around the native tools. And even though risk can be hard to quantify, be sure to factor it in as well.
Take the time to investigate paid tools, making sure to perform the same due diligence. While there will be licensing costs, the time savings can be considerable. In addition, replacing manual procedures with automated processes that have been proven to work at other organizations can dramatically reduce the risk of migration failures and business disruptions.
Tip #3. Understand the staffing needs of all your projects.
Tenant-to-tenant migrations are often complex, so it’s important to know what else is going on around the organization. Start by identifying any other migration projects that might be happening, such as firewall, desktop, server and other infrastructure changes. Coordinate with those teams on migration timing and strategies for minimizing effort and risk. By working together, you can help ensure you’re not stepping on each other’s toes and that you have sufficient technical and support resources in place.
Look for other IT initiatives beyond migrations as well. For example, is HR switching to a new management system? Will the infrastructure team be implementing new firewall restrictions? Then go even broader, since business changes can also affect your project. For example, you probably want to avoid scheduling your migration during a period when the company is shuffling employees to different office spaces or releasing a major new product or service.
Getting a broad picture of projects around the organization is especially important if you’re opting for a batched migration. As noted above, maintaining two environments and ensuring seamless coexistence between them takes time and effort, so you need to ensure you have adequate staffing. One option is to bring in consultants to help with either the migration or other IT tasks.
Tip #4. For large and complex projects, you need a program plan.
For a large and complex tenant-to-tenant migration, you don’t need a project plan — you need a program plan. For example, migrating Exchange, SharePoint and Teams workloads can each be considered their own project, and you need a program plan that coordinates them all.
Bringing in an experienced resource to set up, coordinate and run the program can be a wise choice. The right person can make sure the program is effective and nothing is overlooked, maximizing your chances of success.
Tip #5. Don’t undervalue user interviews.
As you plan your tenant-to-tenant migration, be sure to talk to users. Understanding how they are using your services is vital to delivering an optimal target environment. For example, when you spot something interesting or unusual in a log or your auditing tool, reach out to the people involved to determine what they were doing and why, so you can preserve important business functions during the migration project. User interviews can be hard to do at scale, but they will save you a lot of headaches. Dividing them up among the technical team will spread out the workload and also help ensure everyone keeps user needs firmly in mind during migration planning and execution.
Tip #6. Consider advanced reporting tools, especially for large or recurring projects.
Third-party reporting tools can be extremely valuable, especially if your project is large or you perform tenant-to-tenant migrations on a regular basis. With native tools, large projects require you to write a lot of scripts — and test and revise them to accurately scope your migration project and uncover potential issues. Similarly, if your organization regularly acquires other companies, having to maintain your scripts and update and expand them for each new migration project can be a real pain for your IT teams, who probably already have their hands full. Plus, native reporting tools are in preview programs, so they are constantly changing and have little support.
Advanced reporting tools can dramatically reduce stress and headaches because they include prebuilt reports that anticipate common needs. Often, tailoring a report to meet your needs is as simple as applying a few filters or changing the sort order. In addition, the list of reports can help you expand your thinking and avoid overlooking important issues during the planning phase.
Tip #7. Consider the benefits of having a single migration tool or service.
My final tip is basically a simple reality check. A tenant-to-tenant migration is complicated, with multiple workloads to scope and plan for and lots of moving parts. Really consider whether you can reasonably expect your teams to juggle multiple disparate native tools and manual processes on top of the inherent complexity of the migration itself. Often, one of the key benefits of a paid tool or service is the simplicity of having everything in one place. Indeed, having a single consistent interface and unified controls can dramatically reduce the risk of migration delays, costly mistakes, and outright failure.
Conclusion
I hope these seven tips will help your next tenant-to-tenant migration — and all the ones that follow — be a resounding success.
