Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
To request a geo-to-geo migration, you must enable the Advanced data residency SKU add-on on your tenant for new environments created under macro region geography.
Microsoft continues 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, contact your account manager or go to Technical Support.
- After making a request, expect at least 10 days for the migration process to complete.
- Geo migrations aren't 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's 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 is already reserved in the destination datacenter, it isn't available. In the unlikely event this happens, Microsoft works with you to decide how to proceed.
Geo-to-geo migration steps
Important
Because support for geo-to-geo migration is limited, many Power Platform components, Dynamics 365 applications, and environment administration settings are impacted. To retain functionality of certain features, follow this section.
For environment administration features
Before geo-to-geo migration
- Environment settings (for example, feature settings, Generative AI features, privacy and security settings) reset to their default values after geo-to-geo migration. Note any environment settings you need to reconfigure after migration.
- Managed environment status and associated settings are lost (for example, Admin Digest, Environment Routing). Note the managed environment status and associated settings so you can reapply these settings after geo-to-geo migration.
- Enterprise policy link state and associated properties are lost (for example, customer-managed keys, Virtual Network). Note any enterprise policies linked to the environment so you can relink the enterprise policies after geo-to-geo migration.
- Lockbox requests for the environment undergoing G2G are lost or broken. If Microsoft Support needs access to your environment after geo-to-geo migration, you must create a new Lockbox request.
- Data policies that either include or exclude the environment undergoing geo-to-geo migration no longer apply to the environment. Note the data 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 is removed from its environment group. Note the environment group so you can read the environment to the environment group after geo-to-geo migration.
- Pay-as-you-go is lost for the environment undergoing geo-to-geo migration. Note any Pay-as-you-go billing policies assigned to the environment that you want to retain after geo-to-geo migration.
- Currency allocations is lost for the environment undergoing geo-to-geo migration. Note any currency allocations for the environment that you want 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, see Set up virtual network support for Power Platform and Manage Environment's encryption.
- Work with Microsoft Support to recreate Lockbox requests for the environment as necessary.
- Reapply data policies to the environment as necessary.
- Readd the environment to an environment group as necessary.
- Reapply pay-as-you-go plan to the environment as necessary.
- Repeat currency allocations for the environment as necessary.
For components that are in solutions
Before geo-to-geo migration
- Export all solutions if they contain any of the following components that don't support geo-to-geo migration:
Note
Managed solutions aren't 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're restored upon solution import after geo-to-geo migration.
After geo-to-geo migration
Complete these steps in order:
- Delete Chatbots. They're recreated upon solution import in the next step.
- Import all solutions that you exported before geo-to-geo migration.
- When prompted about Connections, ensure to Review and adjust all connections and recreate connections, as necessary.
- When prompted about Environment variables, ensure environment variables are configured correctly.
- For Power Pages sites, delete the website host then reactivate the site.
- For dataflows, depending on your connection, you might need to edit the dataflow and reconfigure the connection.
- Cloud flows must be reenabled to restore functionality.
For components that aren't in solutions
In general, create and add all components to solutions. Many components are added to a solution by default. However, if you still have components that aren't in a solution, you can migrate many of these components by using the following steps.
Note
- You can't migrate on-premises gateways. You must manually reconfigure them after geo-to-geo migration.
- You can't migrate connections. You must manually recreate them after geo-to-geo migration. However, if canvas apps, cloud flows, or any solution-aware components use connections, the import process for each of these components prompts you to reconfigure them.
Custom connectors
Geo-to-geo migration doesn't support custom connectors that aren't in solutions. You can download these custom connectors as an OpenAPI JSON file, and then recreate them by using the OpenAPI JSON file after geo-to-geo migration.
Before geo-to-geo migration
- Open Power Automate.
- Go to the Custom Connectors page.
- Select the Download button next to the custom connector you want to download. This action downloads an OpenAPI JSON file to your device.
After geo-to-geo migration
- Open Power Automate.
- Go to the Custom Connectors page.
- Select New custom connector.
- Select Import an OpenAPI file and select the OpenAPI JSON file that you downloaded in the Before geo-to-geo migration section.
Canvas apps
Canvas apps can exist outside of solutions. To retain canvas apps, export them before geo-to-geo migration, and then import them 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 you exported in the Before geo-to-geo migration section.
Cloud flows
Cloud flows can exist outside of solutions. To retain cloud flows, export them before geo-to-geo migration, and then import them 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 you exported in the Before geo-to-geo migration section.
Dynamics 365 applications
If you use any of the following Dynamics 365 apps, take the following actions to retain functionality after geo-to-geo migration.
Dynamics 365 Contact Center
Follow the steps in Post-move updates after moving the contact center from one geo to another.
Dataverse Accelerator
Uninstall the app by 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
Project for the web reprovisions automatically when you go to Get started with Project. Your existing plans remain intact.
Dynamics 365 marketing application (Customer Insights - Journeys)
Before geo-to-geo migration, uninstall the Dynamics 365 marketing application by 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, 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, 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 schedule it. Depending on the amount of data, the move might be scheduled up to one week in advance of the cutover date and time. When the move is scheduled but yet to run, you can still access the environment. Certain environment lifecycle operations like Copy, Restore, and others might be unavailable until the migration finishes. |
Cutover Cutover 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 might take up to 48 hours for large organizations. The cutover happens during the evening or over a weekend. |
Notification and support You get alerted by email or telephone when your environment migrates to the new datacenter. After your environment migrates, you can perform the post migration steps. |
We adhere to the terms of the Microsoft Online Services Service Level Agreement for all moves.