6 tips for a smooth Microsoft tenant migration

1. Clarify all areas of responsibility in advance

Before the actual migration starts, you should clarify who is responsible for what as a team. This may sound trivial, but in practice it is unfortunately all too often only done in part or not at all. The consequence: there are delays during the migration process because responsibilities are only in the process of being clarified. In the worst case, it is only at this moment that you realize that you are lacking important skills within the team. We therefore recommend that you create a migration concept in which you define all the roles and areas of responsibility.

Questions that can help you to draw up the migration concept are:

• Who is primarily responsible for the entire migration?
• Which teams are responsible for the Microsoft tenants concerned and who is the main contact person for each team?
• Who makes decisions about the target environment, e.g. if the tenants concerned have different security configurations or concepts?
• What other roles need to be assigned, e.g. for project management, people responsible for communication, the legal department, IT support, additional developers for (partial) automation, etc.?
• Where might the cloud provider need to be consulted? Who takes care of this?
• Who informs other stakeholders such as compliance and data protection officers, the works council, specialist departments and, last but not least, the users?

2. Be clear about the scope of migration

What exactly should be migrated? Does an entire tenant have to be moved to another tenant or only selected content and data? The latter can significantly reduce the amount of time and effort involved in the migration. Sit down at a table with everyone involved in the project.

Think about it together:

• Which subscriptions & Azure resources must be moved?
• Which ones are important for archiving reasons, for example, but are not in constant use and can be moved in a second migration phase?
• Which products, resources or environments can be retired completely and are therefore not relevant for the migration? These could be development or test environments, for example, or software products that already exist in the other tenant and do not require duplication.
• What happens to the “residual waste”? Does this have to be archived or deleted in accordance with the EU GDPR?

3. Consider hidden dependencies

Once you know which content is to be migrated, the next step is to look at its dependencies on other content. This also allows you to verify whether content that you have already sorted through needs to be migrated.

So, ask yourself:

• What needs to be moved apart from subscriptions, including their resources (e.g. virtual machines or storage accounts)?
• Do new subscriptions need to be created? If so, for which content?
• Which (external) dependencies need to be adjusted? These include app registrations, Azure DevOps organizations and Azure policies. Who is responsible for the new installation in this case?
• Who is authorized to carry out such new installations in the target environment? Does this have to be done via a central process or do those responsible for subscriptions (in some cases) have the necessary rights themselves?
• Where do the newly created dependencies have to be updated? For example, there may be a need to adapt the source code or its configurations. Automated processes such as infrastructure as code or CI/CD pipelines may also need to be updated.
• Which processes and services depend on the migrated subscriptions and Azure resources? Are there any relevant service interruptions or restrictions? Is there a requirement for further configuration after the migration, e.g. because the tenant ID has been changed or because other accounts are being used?
• Are there processes that synchronize data or objects into the tenant? Should these processes be synchronized in the new target tenant after the migration or are they superfluous following the migration?
• Which resources are interdependent and need to be migrated together?

4. Take technical restrictions into account

Some types of resources in Azure cannot be directly migrated, as this function is not technically intended or supported. This includes Microsoft Entra Domain Services and the Azure Kubernetes Service, for example, where moving between two tenants is not supported at all. While migration is possible for many other resource types, it is associated with several restrictions or additional work. The creation or reconfiguration of such resources can affect operation and must be prepared appropriately in order to keep costs to a minimum.

Think before you migrate:

• Which resource types are included in the migration scope? Please be aware that some resources are automatically created by Azure and are hidden by default.
• Which resource types are subject to restrictions and how many of these resources need to be moved? Certain resource configurations, for example, may mean that they cannot be migrated at all or only with considerable effort.
• Is it possible to reduce existing restrictions by involving the cloud provider or can the cloud provider enable migration on request?
• How much effort is involved in a new installation?
• In which cases does this effort have to be applied immediately?
• Where can you schedule the new installation for a later date?

5. Plan communication with the users

Users and those with technical oversight of Azure resources and subscriptions in their own company, as well as business partners and, where applicable, customers must be informed about the migration and its effects as early as possible.

The following questions can help you with communication:

• Who is affected by migration? Who will be affected by the changes?
• If downtimes are unavoidable, at what times are users least affected?
• How significant are the changes resulting from the migration, e.g. changes to security measures?
• How can you best prepare users for these adjustments and make the transition easier for them?
• Who is the primary contact partner when it comes to questions and user support? What feedback channels are available?

6. Allow sufficient time & personnel resources for the migration

There is nothing more fatal than a rushed migration. In the worst-case scenario, employees and partners will only be able to perform their tasks partially or not at all. This can cost a company not only money but also impact its image. It is therefore important to draw up a realistic schedule in advance. It is also crucial to ensure that the people responsible have sufficient capacity.

Questions that will help you plan the migration are:

• How much time is needed for technical preparation, e.g. creating help scripts and backups, how much time is needed for measures or adjustments in the tenants, setting up and carrying out test migrations for difficult or critical cases, and how much time must be planned for setting up new dependencies?
• In which phases and at what point exactly should the actual migration take place?
• What other tasks does the migration team have in their everyday operations?
• Do external resources need to be called in for the migration period?
• What time buffers do you plan for unforeseen difficulties?
• What contingency plan is in place if team members are absent unexpectedly, e.g. due to illness?

All in all, individual planning and a thoroughly thought-out concept are indispensable for every migration. It is also advisable to carry out a review after the migration to find out what worked well and where you see potential for improvement in the next migration.

If you are interested in the topic of migration and are looking for a sparring partner for your approach or support with conception and implementation, please contact Manuel Warcholik and his colleagues. You can contact them here.