Move Azure SQL Managed Instance across subnets
Applies to: Azure SQL Managed Instance
Azure SQL Managed Instance must be deployed inside a dedicated subnet within an Azure virtual network. The number of managed instances that can be deployed within the subnet depends on the size of the subnet (subnet range).
This article teaches you to move your managed instance from one subnet to another (in the same VNet or a different one), similar to scaling vCores or changing the instance service tier. SQL Managed Instance is available during the move, except during a short downtime caused by a failover at the end of the update - typically lasting up to 10 seconds, even if long-running transactions are interrupted.
Moving the instance to another subnet triggers the following virtual cluster operations:
- The virtual cluster will build out or resize the underlying infrastructure in destination subnet.
- The virtual cluster is removed or defragmented in the source subnet.
Before moving your instance to another subnet, consider familiarizing yourself with the following concepts:
- Determine required subnet size and range for Azure SQL Managed Instance.
- Choose between moving the instance to a new subnet or using an existing subnet.
- Use management operations to automatically deploy new managed instances, update instance properties, or delete instances. It's possible to monitor these management operations.
Requirements and limitations
To deploy a managed instance, or move it to another subnet, the destination subnet must have certain network requirements.
Before you move your managed instance, confirm the subnet is marked as Ready for Managed Instance.
In the Virtual network UI of the Azure portal, virtual networks that meet the prerequisites for a managed instance are categorized as Ready for Managed Instance. Virtual networks that have subnets with managed instances already deployed to them display an SQL Managed Instance icon before the virtual network name. Empty subnets that are ready for a managed instance display a Virtual network subnet icon.
Subnets that are marked as Not ready don't fulfill all the requirements for SQL Managed Instance deployment. Use the info icon on the right of the subnet name to learn why the subnet isn't ready and if subnet can meet network requirements. These requirements include:
- delegating to the Microsoft.Sql/managedInstances resource provider
- attaching a route table
- attaching a network security group
In the case that subnet is part of some other virtual network, extra requirement is
- bi-directional peering between current and destination virtual network.
After all requirements are satisfied, the subnet moves from the Not ready to the Ready for Managed Instance category and can be used for a managed instance.
Subnet that is already in use (subnets used for instance deployments can't contain other resources), or the subnet has a different DNS zone (a cross-subnet instance move limitation) are always part of the Not ready category.
Depending on the subnet state and designation, the following adjustments may be made to the destination subnet:
- Ready for Managed Instance (contains existing SQL Managed Instance): No adjustments are made. These subnets already contain managed instances, and making any change to the subnet could impact existing instances.
- Ready for Managed Instance (empty): The workflow validates all the required rules in the network security group and route table, and adds any rules that are necessary but missing. 1
1 Custom rules added to the source subnet configuration are not copied to the destination subnet. Any customization of the source subnet configuration must be replicated manually to the destination subnet. One way to achieve this is by using the same route table and network security group for the source and destination subnet.
Destination subnet limitations
Consider the following limitations when choosing a destination subnet for an existing instance:
SQL Managed Instance can be moved to the subnet that is either:
- In the same virtual network as the currently used,
- In a peered virtual network, if moving to a subnet in another virtual network.
The DNS zone of the instances in destination subnet must match the DNS zone of the instance being moved. This limitation applies if you plan to move to a non-empty subnet.
- You can specially prepare the destination subnet to retain the DNS zone of SQL Managed Instance that is being moved. Preparation can be done by creating new SQL Managed Instance in an empty subnet and providing dnsZonePartner parameter in create request. This parameter as a value accepts the ID of SQL Managed Instance, and in this case you can use the instance that would later be moved to the new subnet1.
1 Apart from this approach there is no other way for you to dictate the DNS zone of SQL Managed Instance since it is randomly generated. There also, as of now, doesn't exist a way to update the DNS zone of an existing SQL Managed Instance.
- If you want to migrate a SQL Managed Instance with an auto-failover group, the following prerequisites apply:
- The target subnet needs to have the same security rules needed for failover group replication as the source subnet: Open both inbound and outbound ports 5022 and the range 11000~11999 in the Network Security Group (NSG) for connections from the other managed instance subnet (the one that holds the failover group replica) to allow replication traffic between the two instances.
- The target subnet can't have an overlapping address range with the subnet that holds the secondary instance replica of the failover group. For example, if MI1 is in subnet S1, the secondary instance in the failover group is MI2 in subnet S2. We want to move MI1 to subnet S3. Subnet S3 can't have an overlapping address range with subnet S2.
To learn more about configuring the network for auto-failover groups, review Enable geo-replication between managed instances.
Migration from Gen4 hardware
Instances running on Gen4 hardware must be upgraded to newer hardware since Gen4 is being retired. Upgrading hardware and moving to another subnet can be performed in one operation.
Gen4 hardware is being retired and is not available for new deployments, as announced on December 18, 2019. Customers using Gen4 for Azure SQL Databases, elastic pools, or SQL managed instances should migrate to currently available hardware, such as standard-series (Gen5), before January 31, 2023.
For more information on Gen4 hardware retirement and migration to current hardware, see our Blog post on Gen4 retirement. Existing Gen4 databases, elastic pools, and SQL managed instances will be migrated automatically to equivalent standard-series (Gen5) hardware.
Downtime caused by automatic migration will be minimal and similar to downtime during scaling operations within selected service tier. To avoid unplanned interruptions to workloads, migrate proactively at the time of your choice before January 31, 2023.
The following table details the operation steps that occur during the instance move operation:
|Step name||Step description|
|Request validation||Validates the submitted parameters. If a misconfiguration is detected, the operation fails with an error.|
|Virtual cluster resizing / creation||Depending on the state of the destination subnet, the virtual cluster is either created or resized.|
|New instance startup||The SQL process starts on the deployed virtual cluster in the destination subnet.|
|Seeding database files / attaching database files||Depending on the service tier, either the database is seeded or the database files are attached.|
|Preparing failover and failover||After data has been seeded or database files reattached, the system prepares for failover. When everything is ready, the system performs a failover with a short downtime, usually less than 10 seconds.|
|Old SQL instance cleanup||Removes the old SQL process from the source virtual cluster.|
|Virtual cluster deletion||If it's the last instance within the source subnet, the final step deletes the virtual cluster synchronously. Otherwise, the virtual cluster is asynchronously defragmented.|
A detailed explanation of the operation steps can be found in the overview of Azure SQL Managed Instance management operations
Move the instance
A cross-subnet instance move is part of the instance update operation. Existing instance update API, Azure PowerShell, and Azure CLI commands have been enhanced with a subnet ID property.
In the Azure portal, use the subnet field on the Networking blade to move the instance to the destination subnet. When using Azure PowerShell or the Azure CLI, provide a different subnet ID in the update command to move the instance from an existing subnet to the destination subnet.
For a full reference of instance management commands, see Management API reference for Azure SQL Managed Instance.
The option to choose the instance subnet is located on the Networking blade of the Azure portal. The instance move operation starts when you select a subnet and save your changes.
The first step of the move operation is to prepare the destination subnet for deployment, which may take several minutes. Once the subnet is ready, the instance move management operation starts and becomes visible in the Azure portal.
Monitor instance move operations from the Overview blade of the Azure portal. Select the notification to open an additional blade containing information about the current step, the total steps, and a button to cancel the operation.
- To learn how to create your first managed instance, see Quickstart guide.
- For a features and comparison list, see common SQL features.
- For more information about VNet configuration, see SQL Managed Instance VNet configuration.
- For a quickstart that creates a managed instance and restores a database from a backup file, see Create a managed instance.
- For a tutorial about using Azure Database Migration Service for migration, see SQL Managed Instance migration using Database Migration Service.
Submit and view feedback for