The third and final part of the Tenant to Tenant Migration series is about post-migration processing, and covers post-migration tasks that need to be done, measurement and reporting, what defines success or failure, and what things could be automated for the next tenant to tenant migration.
It does not belong directly in the closing phase, but it is certainly useful to compare the configurations of both tenants after the migration. An Open-Source project from Microsoft and the community provides a PowerShell DSC (Desired State Configuration) script for this purpose. Microsoft 365 DSC allows you to write a definition for how your Microsoft 365 tenant should be configured, automate the deployment of that configuration, and ensures the monitoring of the defined configuration, notifying and acting on detected configuration drifts. It also allows you to extract a full-fidelity configuration out of any existing Microsoft 365 tenant. The tool covers all major Microsoft 365 workloads such as Exchange Online, Teams, Power Platforms, SharePoint and Security and Compliance.
Some important points after migration that I check during my project or mostly reconfigure in the target tenant:
It ends up being difficult to decide if it is still a post-migration task or if it has already moved into the operational phase and involves configuration requests from end users. In any case, the goals and scope must be clearly defined so that there are no unanswered questions after the migration.
Reporting measures are essential to verify that users in the target tenant have access and can access data. The Microsoft 365 Admin Center inherently offers a way to monitor user behavior. However, this is not live data and is only made available after approximately between 24 and 48 hours.
Another important reporting option is Azure AD, where logins and the functionality of possible security policies can be viewed. Also, one of the most important indicators is the successful authentication including second factor.
For example, there might be duplicate license assignments, your users aren’t using certain features from the assigned license, and you probably could assign a smaller one and save money. Furthermore, there might be some users who are on maternity/paternity leave, or on sabbatical leave and maybe just need to preserve the Exchange Online mailbox data which doesn’t requires a license (Inactive Mailboxes feature).
You are either successful at doing something, or achieving some milestone, or you failed at doing something or did not achieve a milestone. It is difficult to talk about success and failure in a migration. In my opinion, the biggest success is a smooth process, with very good communication towards the project participants, but mainly towards the end users. Also, the possibility to authenticate and access the data again without much trouble. This success is shaped by the definition of what data can and cannot be migrated and how.
Failure occurs when the expectation of a migration was not clearly defined from the beginning and there was inadequate communication or no communication at all. Failure can also occur when the logon to the new tenant does not work and the users do not have any data. Likewise, business-critical applications and functions must function properly.
ISVs update their tools as often as necessary to take full advantage of the latest Graph API migration/access capabilities. To do this, they can usually incorporate various customizations and manual requests and act very flexibly. Of course, many things can be automated. Besides the Microsoft 365 DSC, there are many PowerShell or even Graph API scripts in the community that can be brought here for various functionalities and migrations. It is also important to be familiar with both modules and to script recurring work. Anything that can be automated in some way should be used. People make mistakes and a working script or program can run things infinitely without error.
Tenant to tenant migrations require a lot of planning and communication. In addition to thorough consideration and vetting of various ISVs, it is important to define the scope of the migration and prioritize the business-critical applications. Scripts and programs from the community also help to perform more specific or manual tasks and migrations in addition or on the side, for which the Graph API does not provide an interface.
While ENow is not a migration company, our software does enable IT Pros to assess their organizations' readiness for Office 365 and accelerate their migration. In particular, ENow's solution helps organizations verify appropriate network connectivity, validate hybrid components (ADFS & AAD Connect) are setup correctly, and that mail routing is functioning.
For more information on how ENow can ease your transition to Office 365, please chat with the bot in the bottom right corner.