Tenant 2 Tenant migration presents a significant challenge for any organization. As the use of Power Platform continues to rise, it becomes imperative to include its migration in the overall strategy. Drawing from our extensive practical experience, we have outlined the following procedure for successfully migrating Power Platform within Tenant 2 Tenant scenarios.
This article covers the migration of Power Apps, Power Automate and Dataverse.
Types of Power Platform Migration
There are several ways to migrate Power Platform environments, solutions or objects. The best migration path depends on the analysis and can vary for each migration. Note that this refers to a one-time migration from one tenant to another tenant. The quantity and complexity of Power Platform components that needs to be migrated significantly influence the selection of the migration type and must be reevaluated for each migration process.
We have identified the following migration types:
Tenant 2 Tenant migration by Microsoft (1)
The Tenant 2 Tenant migration feature allows you to transfer an environment from one tenant to another. The environment doesn't move, but rather is linked to another tenant.
There are some limitations, including the need for manual migration of Power Apps. It is recommended to reevaluate this scenario before a migration. Previously, Power Automate was also not supported and required manual migration.
ALM/Pipelines (for example Azure DevOps) (2)
If pipelines exist for the current solutions, they can be expanded to perform a Tenant 2 Tenant migration directly. If not, it should be evaluated whether creating them is worthwhile for a one-time migration. It is important to note that some manual steps will also be required. Dataverse datasets can be migrated using the Power Platform CLI.
Third-party migration tools
Several third-party tools are available for Power Platform migrations. However, these third-party tools have also significant limitations. It is advisable to reevaluate this scenario before a migration, as these limitations may have been reduced recently.
Manual migration (export and import of solutions and objects) (3)
Given that this is a one-time migration and that subsequent migration types necessitate manual steps, we will also consider the possibility of performing a manual migration. This type of migration has been used for all our migrations so far, as other migration types still present certain limitations.
Power Platform solutions and objects can be exported and imported manually. Dataverse datasets can be migrated using the Power Platform CLI.
Migration Procedure
If the target tenant is entirely new, all components can be migrated on a one-to-one basis. However, if the target tenant is an existing and already used tenant, it is necessary to integrate these Power Platform components into the current Power Platform environments and strategies.
Analysis
Start by analyzing and documenting the Power Platform components to be migrated. Key considerations include:
- What environments and solutions are available, and how are they configured?
- What Power Platform objects exist?
- Which service accounts are used?
- Which Power Platform licences were used?
- Which connections are used?
- Are custom connections or on-premises gateways present, and how are they configured?
- Are there add-ons in the environment (e.g., PowerApps pay-as-you-go licenses)?
- Are there Power Platform objects outside of solutions? Do these need to be migrated as well?
- Are there any personal Power Platform objects created by business end users?
- Will any Power Platform objects, environments, or solutions in the source tenant continue to be used in the future?
- Are there Dataverse data records that need migration?
- How is the Power Platform and its individual environments configured?
- Are the service accounts and the corresponding licenses/add-ons available in the target system?
- Does a PowerPlatform governance exist? Do these need to be adopted?
- What is the PowerPlatform capacity usage of the objects being migrated?
- Is there enough PowerPlatform capacity on the target system, or is additional storage required?
- Is there an existing App registration? Do these need to be registered on the target tenant?
Preparation
The type of migration and the migration procedure are determined based on the results of the analysis. It is recommended to create a migration mapping document, specifying which Power Platform solutions and objects will be migrated from which environment to which environment, detailing the timeline and responsible parties. Additionally, all necessary technical adjustments for the Power Platform governance should be appropriately scheduled. The communication should specify if the business end user will migrate personal Power Platform objects themselves. Appropriate instructions and support contacts points should be offered.
The roadmap is crucial in this context, as we are addressing a Tenant 2 Tenant migration. Consequently, Users, Shared Mailboxes, SharePoint Sites, Teams and other components must also be migrated. Therefore, it is not feasible to perform a migration until a delta migration of the used connections (for example SharePoint Sites) within the Power Platform components was carried out.
PoC Migration
We strongly recommend performing a Proof of Concept (PoC) migration to assess risks early. During the PoC, at least one of the most complex solutions should be migrated to identify potential risks and issues in advance.
Migration, Testing and sharing
As soon as the used connection within the Power Platform components are migrated successfully, the migration can be started. The solutions are migrated individually and tested during the migration. The status should be updated centrally based on the already created mapping list. When a solution is imported, redefine environment variables and connections. Then, adjust individual objects like Power Apps and Power Automate Flows as needed. Some components, such as custom connections or Forms, may need to be migrated manually. The solution or object owner performs the acceptance and testing process. Afterward, the components can be shared and the end users can be informed accordingly.
HyperCare
After Go-Live, it is advisable to conduct monitoring to promptly identify any errors or anomalies. Additionally, implementing a HyperCare phase for a specified period can help ensure that errors are addressed quickly, minimizing their impact on daily business operations.
Cleanup
Do not delete recently migrated Power Platform components immediately. Instead, keep them accessible for a defined period (e.g., 3-6 months). If immediate deletion is necessary, retain exported components for a set time. This ensures they can be re-imported or can be used for error handling, if errors arise later.
Conclusion
Following best practices significantly facilitates Tenant 2 Tenant migration. Utilizing environment variables and solutions can greatly streamline the process. At this stage, it is also crucial to establish and implement Power Platform governance if it is not already in place. We are available to provide assistance with this process.
Should you require assistance with Tenant 2 Tenant migration, kindly reach out to us at your convenience - Need help with Tenant 2 Tenant migration?
Sources
.png?width=290&name=Federico%20(1).png)