Move Azure Machine Learning workspaces between subscriptions (preview)
As the requirements of your machine learning application change, you may need to move your workspace to a different Azure subscription. For example, you may need to move the workspace in the following situations:
- Promote workspace from test subscription to production subscription.
- Change the design and architecture of your application.
- Move workspace to a subscription with more available quota.
- Move workspace to a subscription with different cost center.
Moving the workspace enables you to migrate the workspace and its contents as a single, automated step. The following table describes the workspace contents that are moved:
Workspace contents | Moved with workspace |
---|---|
Datastores | Yes |
Datasets | No |
Experiment jobs | Yes |
Environments | Yes |
Models and other assets stored in the workspace | Yes |
Compute resources | No |
Endpoints | No |
Important
Workspace move is currently in public preview. This preview is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.
For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
Prerequisites
An Azure Machine Learning workspace in the source subscription. For more information, see Create workspace resources.
You must have permissions to manage resources in both source and target subscriptions. For example, Contributor or Owner role at the subscription level. For more information on roles, see Azure roles.
- You need permissions to delete resources from the source location.
- You need permissions to create resources in the destination location.
- Thee move mustn't violate Azure Policies in the destination location.
- Any role assignments to the source workspace scope aren't moved; you must recreate them in the destination.
The destination subscription must be registered for required resource providers. The following table contains a list of the resource providers required by Azure Machine Learning:
Resource provider Why it's needed Microsoft.MachineLearningServices Creating the Azure Machine Learning workspace. Microsoft.Storage Azure Storage Account is used as the default storage for the workspace. Microsoft.ContainerRegistry Azure Container Registry is used by the workspace to build Docker images. Microsoft.KeyVault Azure Key Vault is used by the workspace to store secrets. Microsoft.Notebooks/NotebookProxies Integrated notebooks on Azure Machine Learning compute instance. Microsoft.ContainerService If you plan on deploying trained models to Azure Kubernetes Services. If you plan on using a customer-managed key with Azure Machine Learning, then the following service providers must be registered:
Resource provider Why it's needed Microsoft.DocumentDB/databaseAccounts Azure Cosmos DB instance that logs metadata for the workspace. Microsoft.Search/searchServices Azure Search provides indexing capabilities for the workspace. For information on registering resource providers, see Resolve errors for resource provider registration.
The Azure CLI.
Tip
The move operation does not use the Azure CLI extension for machine learning.
Supported scenarios
Automated workspace move across resource groups or subscriptions within the same region. For more information, see Moving resources to a new resource group or subscription.
Note
The workspace must be quiescent before the move; computes are deleted, no live endpoints or running experiments.
Moving a workspace that has private endpoints configured is supported. The private endpoints are disconnected and transitive private endpoints are recreated after the move. However, you're responsible for approving the new private endpoints (including the workspace private endpoint) after the move.
Limitations
Workspace move isn't meant for replicating workspaces, or moving individual assets such as models or datasets from one workspace to another.
Workspace move doesn't support migration across Azure regions.
Workspace move doesn't support migration across Microsoft Entra tenants.
Tip
For information on manually moving tenants, see the Transfer an Azure subscription to a different Microsoft Entra ID article.
The workspace mustn't be in use during the move operation. Verify that all experiment jobs, data profiling jobs, and labeling projects have completed. Also verify that inference endpoints aren't being invoked.
The workspace becomes unavailable during the move.
Before to the move, you must delete or detach computes and inference endpoints from the workspace.
Datastores may still show the old subscription information after the move. For steps to manually update the datastores, see Scenario: Move a workspace with nondefault datastores.
The following scenarios are not supported:
- Workspace with computes (either existing computes or in the process of creating the compute).
- Workspace with deployed services.
- Workspace with online endpoints/deployments.
- Workspace configured for customer managed-key.
- Workspace with currently running labeling projects.
- Workspace linked with Azure Databricks.
- Workspace move across regions.
Prepare and validate the move
In Azure CLI, set the subscription to that of your origin workspace
az account set -s origin-sub-id
Verify that the origin workspace isn't being used. Check that any experiment jobs, data profiling jobs, or labeling projects have completed. Also verify that inferencing endpoints aren't being invoked.
Delete or detach any computes from the workspace, and delete any inferencing endpoints. Moving computes and endpoints isn't supported. Also note that the workspace becomes unavailable during the move.
Create a destination resource group in the new subscription. This resource group will contain the workspace after the move. The destination must be in the same region as the origin.
az group create -g destination-rg -l my-region --subscription destination-sub-id
The following command demonstrates how to validate the move operation for workspace. You can include associated resources such as storage account, container registry, key vault, and application insights into the move by adding them to the
resources
list. The validation may take several minutes. In this command,origin-rg
is the origin resource group, whiledestination-rg
is the destination. The subscription IDs areorigin-sub-id
anddestination-sub-id
, while the workspace isorigin-workspace-name
:az resource invoke-action --action validateMoveResources --ids "/subscriptions/origin-sub-id/resourceGroups/origin-rg" --request-body "{ \"resources\": [\"/subscriptions/origin-sub-id/resourceGroups/origin-rg/providers/Microsoft.MachineLearningServices/workspaces/origin-workspace-name\"],\"targetResourceGroup\":\"/subscriptions/destination-sub-id/resourceGroups/destination-rg\" }"
Move the workspace
Once the validation has succeeded, move the workspace. You may also include any associated resources into move operation by adding them to the ids
parameter. This operation may take several minutes.
az resource move --destination-group destination-rg --destination-subscription-id destination-sub-id --ids "/subscriptions/origin-sub-id/resourceGroups/origin-rg/providers/Microsoft.MachineLearningServices/workspaces/origin-workspace-name"
After the move has completed, recreate any computes and redeploy any web service endpoints at the new location.
Scenario: Move a workspace with nondefault datastores
The automated workspace move operation doesn't move nondefault datastores. Use the following steps to manually update the data store credentials after the move.
Within Azure Machine Learning studio, select Data and then select a nondefault data store. For each nondefault data store, check if the Subscription ID and Resource group name fields are empty. If they are, select Update authentication.
In the Update datastore credentials dialog, select the subscription ID and resource group name that the storage account was moved to and then select Save.
If the Subscription ID and Resource group name fields are populated for the nondefault data assets, and refer to the subscription ID and resource group prior to the move, use the following steps:
Navigate to the Datastores tab, select the datastore, and then select Unregister.
Select Create to create a new datastore.
From the Create datastore dialog, use the same name, type, etc. as the datastore you unregistered. Select the subscription ID and storage account from the new location. Finally, select Create to create the new datastore registration.
Next steps
- Learn about resource move