Geo-to-geo migrations
We continue to open new datacenter regions for business services, and to add datacenters to existing regions.
The Geo Migration feature allows customers to move their environments in a single tenant from one region to another. There are no user-interface changes or version changes as part of this move. If the environment resides in an Microsoft 365 environment in a single tenant, moving the environment doesn't move the Microsoft 365 environment; they're separate services. Your environment still appears in your tenant alongside the Microsoft 365 environment.
Important
- Support for geo migration is limited and generally not available.
- To request a regional migration, please contact your account manager or see Technical Support.
- After making a request, expect at least 10 days for the migration to be completed.
- Geo migrations are not supported into or out of US GCC, US GCC High, or China.
- Geo migrations are restricted into or out of OCE or IND.
- There are important and critical preparation steps mentioned in the Geo-to-geo migration steps section that need to be performed for Power Apps or Power Automate prior to the geo migration. If these steps are missed, it is difficult to recover Power Apps or Power Automate solutions.
Supported environment types
| Supported | Not supported |
|---|---|
|
|
Impact of migrating
- Backups for the environment undergoing geo-to-geo migration are no longer available.
- Your organization URL is changed. Each of the regional datacenters has a unique identifier in the URL. When your organization is moved from one regional datacenter to another, this identifier changes. Learn more at New datacenter regions.
- Your environment ID is changed to a new globally, unique identifier.
Note
Organization URLs must be unique. If your organization, domain name has already been reserved in the destination datacenter, it isn't available. In the unlikely event this happens, we work with you to decide how to proceed.
Geo-to-geo migration steps
Important
As support for geo-to-geo migration is limited, many Power Platform components, Dynamics 365 applications, and environment, administration settings are impacted. It's vital for you to follow this section to retain functionality of certain features.
For environment, administration features
Before geo-to-geo migration
- Environment settings (for example, feature settings, Generative AI features, privacy and security settings) will be set back to their default values after geo-to-geo migration. Take note of any environment settings you need to reconfigure after migration.
- Managed environment status and associated settings will be lost (for example, Admin Digest, Environment Routing). Take note of the managed environment status and associated settings so that you can reapply these settings after geo-to-geo migration.
- Enterprise policy link state and associated properties will be lost (for example, customer-managed keys, Virtual Network). Take note of any enterprise policies linked to the environment so that you can relink the enterprise policies after geo-to-geo migration.
- Lockbox requests for the environment undergoing G2G will be lost or broken. If Microsoft Support needs access to your environment after geo-to-geo migration, a new Lockbox request must be created.
- Data Loss Prevention (DLP) policies that either include or exclude the environment undergoing geo-to-geo migration will no longer apply to the environment. Take note of the DLP policies that apply to the environment so that you can reapply the policies after geo-to-geo migration.
- The environment undergoing geo-to-geo migration will be removed from its environment group. Take note of the environment group that the environment is in so that you can readd the environment to the environment group after geo-to-geo migration.
- Pay-as-you-go will be lost for the environment undergoing geo-to-geo migration. Take note of any Pay-as-you-go billing policies assigned to the environment that you would like to retain after geo-to-geo migration.
- Currency allocations will be lost for the environment undergoing geo-to-geo migration. Take note of any currency allocations for the environment that you would like to retain after geo-to-geo migration.
After geo-to-geo migration
- Reconfigure environment settings as necessary.
- Reenable managed environments and resave managed environment settings as necessary.
- Relink enterprise policies to the environment as necessary. For example, virtual network, customer-managed keys
- Work with Microsoft Support to recreate Lockbox requests for the environment as necessary.
- Reapply DLP policies to the environment as necessary.
- Readd the environment to an environment group as necessary.
- Reapply Pay-as-you-go billing policies to the environment as necessary.
- Repeat currency allocations for the environment as necessary.
For components that are in solutions
Before geo-to-geo migration
- All solutions must be exported if they contain any of the following components that don't support geo-to-geo migration:
Note
Managed solutions cannot be exported, but ALM best practices ensure all managed solutions you own have an associated unmanaged solution that you can export as a managed solution.
- Canvas apps
- Custom pages
- Component libraries
- Custom connectors
- Dataflows
- Environment variables using data type "Data source"
- Connection references
- Chatbots
- Delete all canvas apps, custom pages, and component libraries in the solutions you exported in step 1.
Important
Solution-aware canvas apps, custom pages, and component libraries that you don't delete from the environment before geo-to-geo migration are left in an inoperable state after the migration completes. You can't play, edit, or export them. You must delete them to unblock any further solution updates. They are restored upon solution import after geo-to-geo migration.
After geo-to-geo migration
Complete these steps in order:
- Chatbots must be deleted. They are recreated upon solution import in the next step.
- All solutions that were exported before geo-to-geo migration must be imported.
- When prompted about Connections, make sure to Review and adjust all connections and recreate connections, as necessary.
- When prompted about Environment variables, make sure environment variables are configured correctly.
- For Power Pages sites, delete the website host then reactivate the site.
- For dataflows, depending on your connection, you may need to edit the dataflow and reconfigure the connection.
- Cloud flows must be reenabled to restore functionality.
For components that are not in solutions
In general, it's recommended to create and add all components to solutions, and many components are added to a solution, by default. However, if you still have components that aren't in a solution, many of these components can be migrated with the following steps.
Note
- On-premises gateways can't be migrated and must be manually reconfigured after geo-to-geo migration.
- Connections can't be migrated and must be manually recreated after geo-to-geo migration. However, for connections that're used by canvas apps, cloud flows, or any solution-aware components, you're prompted to reconfigure them as part of the import processes for each of these components.
Custom connectors
Custom connectors that aren't in solutions aren't supported for geo-to-geo migration. They can be downloaded as an OpenAPI JSON file, then recreated using the OpenAPI JSON file after geo-to-geo migration.
Before geo-to-geo migration
- Navigate to https://make.powerautomate.com/.
- Navigate to the Custom Connectors page.
- Select the Download button next to the custom connector you want to download. This downloads an OpenAPI JSON file to your device.
After geo-to-geo migration
- Navigate to https://make.powerautomate.com/.
- Navigate to the Custom Connectors page.
- Select New custom connector.
- Select Import an OpenAPI file and select the OpenAPI JSON file that was downloaded in the Before geo-to-geo migration section.
Canvas apps
Canvas apps can exist outside of solutions. In order to retain canvas apps, they must be exported before geo-to-geo migration, and then imported after geo-to-geo migration.
Before geo-to-geo migration
Export the canvas apps that aren't in solutions.
After geo-to-geo migration
Import the canvas apps that were exported in the Before geo-to-geo migration section.
Cloud flows
Cloud flows can exist outside of solutions. In order to retain cloud flows, they must be exported before geo-to-geo migration, and then imported after geo-to-geo migration.
Before geo-to-geo migration
Export the cloud flows that aren't in solutions.
After geo-to-geo migration
Import the cloud flows that were exported in the Before geo-to-geo migration section.
Dynamics 365 applications
If you use any of the following Dynamics 365 apps, you need to take the following actions to retain functionality after geo-to-geo migration.
Dataverse Accelerator
After geo-to-geo migration
Uninstall the app using PAC CLI with these commands:
pac solution delete --solution-name msdyn_DataverseAcceleratorApp --environment <environment URL>
pac solution delete --solution-name DataverseAccelerator --environment <environment URL>
pac solution delete --solution-name DataverseAccelerator_Anchor --environment <environment URL>
After uninstallation, reinstall the app through the Power Platform admin center.
Project for the web
After geo-to-geo migration
Project for the web is reprovisioned automatically when navigating to https://project.microsoft.com/. Your existing plans still remain intact.
Dynamics 365 marketing application (Customer Insights - Journeys)
Before geo-to-geo migration
Uninstall the Dynamics 365 marketing application using the following guide: Uninstall Dynamics 365 Marketing.
After geo-to-geo migration
Reinstall the Dynamics 365 marketing app through the Power Platform admin center.
Desktop applications
If you use any of the following Power Platform desktop applications, you need to take the following actions to retain functionality after geo-to-geo migration.
Power Automate machine runtime
After geo-to-geo migration
If you selected the environment that's being migrated as your machine environment in the Power Automate machine runtime application, you need to reselect the environment in the app after geo-to-geo migration.
How the move works
You should follow the above steps before and after geo-to-geo migration. The following table describes what Microsoft does before, during, and after the geo-to-geo migration.
| Before the move | During the move | After the move | |
|---|---|---|---|
| What Microsoft does | Notification Your support representative or Account Manager works with you to request a move and scheduling. |
Cut-over Cut-over times for each service depend on the number of users and the amount of data. This step can take 1 to 6 hours for smaller organizations, but may take up to 48 hours for large organizations. The cut-over is done during the evening or over a weekend. |
Notification and support You will be alerted by email or telephone when your environment is migrated to the new datacenter. After your environment has migrated, you can perform the post migration steps. |
We adhere to the terms of the Microsoft Online Services Service Level Agreement for all moves.