- Part 1 covers the discovery of identities, workloads, data, and security.
- Part 2 covers the migration itself, such as which workloads can be moved, what needs to be done to prepare for migration, which data can be migrated or are there any gotchas to expect, and public available PowerShell scripts that make your life a little bit easier.
- Part 3 (below) 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:
- The most important functionality is the identities. Without them, no logon to services is possible and ultimately no access to data. Azure AD sign-in logs are a good way to check if the login of the migrated users works properly, or if, for example, there was a problem with the MFA configuration, or if the (usually temporary) password to be used does not work.
- Operating processes change. Depending on whether the administrators in the target tenant are given (restricted) rights for administration again or not, the process around the helpdesk, which was planned before the migration at best, also changes in any case.
- Many things can and should be automated. Simple, recurring tasks offer a useful way to optimize operational processes with Azure Automation.
- Communication is the key to success even after migration. Often not all end users are informed which data could be migrated and which could not. They may still have a cloud-only account from the source tenant with which they can and should continue to access data. Users should always be sufficiently informed and regular enabling workshops on the changes and accesses should take place.
- Finally, all necessary configuration and policies should be created and assigned in the target tenant. This includes, for example, security & compliance policies and individual configurations outside the standard in the target tenant, such as address book segmentation.
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.
Measurement and Reporting
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).
What Defines Success And Failure
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.
More Automation, Please
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.