By building a core competency around tenant-to-tenant (T2T) migrations, you can add a valuable new service to the offerings of your MSP business. We make the case for that in the other articles in this series. In MSP Alert: The Rise in Tenant-to-Tenant Migrations for Microsoft 365, we look at the uptick in T2T migrations overall, and how they’re supplanting Exchange-on-premises to cloud migrations as a revenue generator. In Sizing Up Your Opportunities: Tenant-to-Tenant Migrations for MSPs, we give you some tips for identifying customers who might soon be in the market for one of these projects. And in Tenant to Tenant Migration Tools: Why Third-Party Solutions? we explore why turning to a third-party tool from a migration specialist is often a better business decision than going with the “free” tools supplied by Microsoft and Google.
In this article, we’ll give you some top-line tips and best practices for delivering a smoother, maximum-fidelity migration that minimizes downtime and hassle for your clients. Read on and benefit from a wealth of practical, real-life experience from MSPs who have built successful, repeatable T2T migration practices.
Have a communication plan. Clear communication to end users is critical for avoiding calls. Be sure the help desk and other support is ready and engaged with the migration project.
Understand the limitations affecting workloads. Not all data can be migrated, for example, Yammer. Make sure all stakeholders understand which data and features are going to be available to each set of users. To minimize end-user impact, make sure the users understand which account login to use when accessing a shared resource like SharePoint, Teams or OneDrive files.
Stave off user confusion. Anticipate scenarios and have plans in place. If migrated users need access to non-migrated data, which login should they use? What about non-migrated users who need access to migrated data? When, how and where should those passwords be changed?
Be clear about the consequences and impacts that you can’t control. If migrating to a different domain, URLs previously embedded in emails or documentation won’t work. If the Source tenant still exists post-migration, stakeholders need to be aware that users will inevitably use those old links.
Have contingency plans in place. If users are missing data post-migration, they or the support team will need to navigate back to the Source tenant via a browser. If a device fails to configure for the Destination tenant, the impacted user may need to use Outlook Web Access until the issue is resolved.
Expect a level of downtime during cutover. The larger the organization and workloads, the more downtime you can expect. No matter the scenario, a zero user-impact migration is not attainable. Your aim is to minimize the pain with solid planning and preparation.
Set expectations for yourself, too. Even when using a built-for-purpose third-party tool, there will be some manual scripting or tweaking involved in pulling off an optimal migration.
Preparation and Planning
Understand how much data you have. Huge amounts of data can take a long time to migrate.
Perform a full export of the Source objects. Include all the attributes. Be alert for user name and group name conflicts.
Establish the identity design before undertaking any migration steps. Pay attention to distribution lists, shared mailboxes, rooms/resources and guest accounts. In an acquisition scenario, be on the alert for name clashes. Groups may need to be either renamed or merged.
Check licenses and quotas. Have enough target Microsoft 365 licenses of the right type, plus a buffer. OneDrive for Business quotas in the Destination need to be same as the Source or higher.
Don't use the Source domain in any mapping files. Use the *.onmicosoft.com alias instead. Otherwise, when you remove the domain, the migration tools won’t recognize the user in the Destination.
Migration, Cutover and Cleanup
Use a Licensed Global Administration account with a *.onmicosoft.com User Principal Name (UPN). Ensure that it does not have multi-factor authentication or conditional access applied for the duration of the migration.
If you’re going to pre-stage data before the cutover, keep it simple. One recommendation is to pre-stage email older than 30 days, and OneDrive or SharePoint files older than 90 days.
Have a list of key contacts on hand before the cutover. This includes administrators for Active Directory, Azure AD Connect, network/DNS, Microsoft 365 and IT security.
Make sure you have access to make DNS changes. Test this and verify before you remove the domain name from the Source tenant; otherwise, you can’t prove ownership of the tenant by adding the MX record and the email becomes stranded.
Prepare for throttling. Be aware that you might need to make a Microsoft service request to relax some throttling settings.
Don’t forget the details. Don’t overlook mailbox delegation and retention/litigation hold if required.
Avoid ongoing charges. Once the migration is complete, de-license and block end-users from accessing the Source.
Beyond Technical Skills
The mechanics of the migration itself is only one element of the project. Securing buy-in, scheduling, planning and transition management all come into play. If you’re in a merger, acquisition or divestiture scenario, you will inevitably face some political hurdles, and milestones such as public announcements or marketing needs around rebranding might have to be reflected in your timelines. Your communication and people skills will be every bit as important as your technical acumen.
That said, careful preparation and planning is the key to any migration. A built-for-purpose third-party migration tool and the support resources that come bundled with it will optimize your ability to apply these best practices to your migrations. Result? Successful projects, kept promises and valuable new sources of revenue.