Microsoft has made database migrations from Azure Arc-enabled SQL Server instances to SQL Server on Azure Virtual Machines generally available, giving administrators a single Azure portal workflow for assessment, configuration, data movement, monitoring, validation, and final cutover.
Petri reported the availability on July 15, while Microsoft’s SQL Server enabled by Azure Arc release notes place the feature’s GA milestone in June 2026. The release completes an expansion that began in March, when Microsoft introduced SQL Server on Azure VMs as a new migration target alongside Azure SQL Managed Instance.
The practical payoff is consolidation. Instead of stitching together separate discovery reports, migration services, storage configuration, restore jobs, and monitoring screens, IT teams can manage most of the database journey from the Azure Arc resource in the Azure portal.
SQL Server migration in Azure Arc previously centered on Azure SQL Managed Instance, Microsoft’s managed platform-as-a-service destination. Adding SQL Server on Azure Virtual Machines gives customers a more conventional lift-and-shift option without forcing administrators to adopt another migration interface.
Microsoft says the Azure VM route uses the same migration dashboard, monitoring experience, and guided workflow already available for Managed Instance. Administrators can connect an existing SQL Server deployment to Azure Arc, review its migration readiness, select a destination, configure the job, monitor synchronization, and initiate cutover from one operational model.
That consistency matters because Azure SQL Managed Instance and SQL Server on Azure VMs solve different problems. Managed Instance reduces operating-system and database-platform management, while an Azure VM preserves greater control over SQL Server, Windows or Linux, installed software, storage configuration, and instance-level dependencies.
Organizations can therefore select a destination based on application compatibility, regulatory requirements, operational responsibilities, or modernization plans without retraining staff on a completely different migration process. The destination changes, but the migration control plane does not.
Azure Arc also supplies the inventory and assessment layer before data starts moving. Microsoft’s documentation says connected SQL Server instances can be evaluated for compatibility issues, migration blockers, target sizing, configuration, and recommended Azure SQL paths. Discovery and readiness reports are generated automatically on a recurring basis, although administrators can also trigger an assessment manually.
Azure Arc monitors the staging location and applies new backups to keep the target database closely synchronized with the source. When administrators are ready to switch production traffic, they initiate cutover, the workflow applies the latest uploaded backup, and the target database is brought online.
This model does not eliminate downtime, but it moves most of the long-running data transfer and restore work ahead of the final maintenance window. The interruption can consequently be limited largely to final synchronization, validation, application reconfiguration, and connection redirection.
There is an important placement requirement: the Azure Blob Storage account and the target SQL Server VM must reside in the same Azure region. The storage account acts as an intermediary rather than the permanent database destination, and the migration workflow uses managed identity to authenticate to it.
Administrators may select an existing SQL Server VM or provision a new target during the migration process. An existing target must be registered with the SQL IaaS Agent extension before it can be selected in the portal.
Microsoft’s current documentation lists support for SQL Server 2012 through SQL Server 2025, subject to minimum servicing levels. It covers every SQL Server edition on Windows and Linux, although the surrounding Azure Arc and target-VM requirements still determine whether a particular environment can use the integrated workflow.
Microsoft lists SQL Server Agent jobs, credentials, SQL Server Integration Services packages, and server-audit configuration among the unsupported objects. High-availability and disaster-recovery topology on the target is also not automatically configured to match the source.
That distinction is critical for established applications. A database may restore successfully while scheduled jobs, linked operational processes, authentication dependencies, SSIS workloads, monitoring agents, and application connection settings still require separate planning.
The documented limitations also include several target constraints:
Continuous migration assessment became generally available in July 2025. The integrated migration workflow for Azure SQL Managed Instance followed later in 2025, and SQL Server on Azure VMs entered the experience as a new target in March 2026 before reaching GA in June.
That progression reveals Microsoft’s broader strategy: onboard the SQL estate to Azure Arc first, continuously assess it, and then present Azure destinations from the same control plane. The immediate benefit for administrators is less tool switching; the commercial benefit for Microsoft is a clearer path from hybrid management into Azure consumption.
SQL Server on Azure VMs is especially important in that strategy because not every workload is ready for a managed database service. Legacy applications may depend on operating-system access, instance-level features, third-party agents, specific patching practices, or configurations that are difficult to reproduce in Azure SQL Managed Instance.
The VM destination gives those organizations a lower-change first step. They can relocate the workload to Azure infrastructure while retaining familiar SQL Server administration, then decide later whether deeper platform modernization is practical.
Administrators can start from an Azure Arc-enabled SQL Server resource in the Azure portal and open Migration > Database migration. Before launching a production job, they will need an eligible source, a properly registered SQL Server VM target, suitable Azure Blob Storage in the target region, the necessary Azure permissions, and a migration plan covering every dependency the database workflow does not carry across.
The GA release makes the mechanics of moving databases more coherent, but the final measure of success remains outside the dashboard: applications must reconnect, jobs must run, recovery objectives must hold, and the new Azure VM must behave like the SQL Server environment it replaced.
Petri reported the availability on July 15, while Microsoft’s SQL Server enabled by Azure Arc release notes place the feature’s GA milestone in June 2026. The release completes an expansion that began in March, when Microsoft introduced SQL Server on Azure VMs as a new migration target alongside Azure SQL Managed Instance.
The practical payoff is consolidation. Instead of stitching together separate discovery reports, migration services, storage configuration, restore jobs, and monitoring screens, IT teams can manage most of the database journey from the Azure Arc resource in the Azure portal.
Azure VMs Join the Unified Migration Workflow
SQL Server migration in Azure Arc previously centered on Azure SQL Managed Instance, Microsoft’s managed platform-as-a-service destination. Adding SQL Server on Azure Virtual Machines gives customers a more conventional lift-and-shift option without forcing administrators to adopt another migration interface.Microsoft says the Azure VM route uses the same migration dashboard, monitoring experience, and guided workflow already available for Managed Instance. Administrators can connect an existing SQL Server deployment to Azure Arc, review its migration readiness, select a destination, configure the job, monitor synchronization, and initiate cutover from one operational model.
That consistency matters because Azure SQL Managed Instance and SQL Server on Azure VMs solve different problems. Managed Instance reduces operating-system and database-platform management, while an Azure VM preserves greater control over SQL Server, Windows or Linux, installed software, storage configuration, and instance-level dependencies.
Organizations can therefore select a destination based on application compatibility, regulatory requirements, operational responsibilities, or modernization plans without retraining staff on a completely different migration process. The destination changes, but the migration control plane does not.
Azure Arc also supplies the inventory and assessment layer before data starts moving. Microsoft’s documentation says connected SQL Server instances can be evaluated for compatibility issues, migration blockers, target sizing, configuration, and recommended Azure SQL paths. Discovery and readiness reports are generated automatically on a recurring basis, although administrators can also trigger an assessment manually.
Backup and Log Shipping Do the Data Movement
The Azure VM workflow relies on backup and restore with log shipping rather than treating the source server as a disk image to be copied wholesale. Database backups are uploaded to Azure Blob Storage, restored to SQL Server on the target Azure VM, and followed by differential and transaction-log backups as they become available.Azure Arc monitors the staging location and applies new backups to keep the target database closely synchronized with the source. When administrators are ready to switch production traffic, they initiate cutover, the workflow applies the latest uploaded backup, and the target database is brought online.
This model does not eliminate downtime, but it moves most of the long-running data transfer and restore work ahead of the final maintenance window. The interruption can consequently be limited largely to final synchronization, validation, application reconfiguration, and connection redirection.
There is an important placement requirement: the Azure Blob Storage account and the target SQL Server VM must reside in the same Azure region. The storage account acts as an intermediary rather than the permanent database destination, and the migration workflow uses managed identity to authenticate to it.
Administrators may select an existing SQL Server VM or provision a new target during the migration process. An existing target must be registered with the SQL IaaS Agent extension before it can be selected in the portal.
Microsoft’s current documentation lists support for SQL Server 2012 through SQL Server 2025, subject to minimum servicing levels. It covers every SQL Server edition on Windows and Linux, although the surrounding Azure Arc and target-VM requirements still determine whether a particular environment can use the integrated workflow.
A Single Portal Does Not Migrate Every Dependency
The GA label should not be interpreted as automatic migration of an entire SQL Server host. The workflow moves databases, but several server-level objects remain outside its scope.Microsoft lists SQL Server Agent jobs, credentials, SQL Server Integration Services packages, and server-audit configuration among the unsupported objects. High-availability and disaster-recovery topology on the target is also not automatically configured to match the source.
That distinction is critical for established applications. A database may restore successfully while scheduled jobs, linked operational processes, authentication dependencies, SSIS workloads, monitoring agents, and application connection settings still require separate planning.
The documented limitations also include several target constraints:
- Existing databases on the destination cannot be overwritten through Azure Database Migration Service.
- A migration can move no more than 100 databases to the same Azure VM target at one time.
- SQL Server 2008 and older target versions are not supported.
- The SQL IaaS Agent extension supports a default instance or a single named instance for this migration scenario.
- Backup files for separate databases must use separate folders when sharing an Azure Blob Storage container.
Azure Arc Becomes Microsoft’s SQL Modernization Front Door
Microsoft has steadily expanded Azure Arc from a hybrid inventory and governance service into a delivery point for SQL Server operations. Connected instances can expose version, edition, database, host, configuration, performance, security, and migration information in Azure even when the underlying server remains in a data center or another cloud.Continuous migration assessment became generally available in July 2025. The integrated migration workflow for Azure SQL Managed Instance followed later in 2025, and SQL Server on Azure VMs entered the experience as a new target in March 2026 before reaching GA in June.
That progression reveals Microsoft’s broader strategy: onboard the SQL estate to Azure Arc first, continuously assess it, and then present Azure destinations from the same control plane. The immediate benefit for administrators is less tool switching; the commercial benefit for Microsoft is a clearer path from hybrid management into Azure consumption.
SQL Server on Azure VMs is especially important in that strategy because not every workload is ready for a managed database service. Legacy applications may depend on operating-system access, instance-level features, third-party agents, specific patching practices, or configurations that are difficult to reproduce in Azure SQL Managed Instance.
The VM destination gives those organizations a lower-change first step. They can relocate the workload to Azure infrastructure while retaining familiar SQL Server administration, then decide later whether deeper platform modernization is practical.
Administrators can start from an Azure Arc-enabled SQL Server resource in the Azure portal and open Migration > Database migration. Before launching a production job, they will need an eligible source, a properly registered SQL Server VM target, suitable Azure Blob Storage in the target region, the necessary Azure permissions, and a migration plan covering every dependency the database workflow does not carry across.
The GA release makes the mechanics of moving databases more coherent, but the final measure of success remains outside the dashboard: applications must reconnect, jobs must run, recovery objectives must hold, and the new Azure VM must behave like the SQL Server environment it replaced.
References
- Primary source: Petri IT Knowledgebase
Published: 2026-07-15T16:58:26+00:00
Microsoft Makes SQL Server Migration to Azure VMs GA in Azure Arc
Microsoft has made SQL Server migrations to Azure Virtual Machines generally available through Azure Arc.
petri.com
- Official source: learn.microsoft.com
Prepare Environment for a SQL VM Migration - SQL Server migration in Azure Arc | Microsoft Learn
Prepare your SQL Server instance enabled by Azure Arc for migration to SQL Server on Azure VMs.learn.microsoft.com - Official source: azure.microsoft.com
- Official source: techcommunity.microsoft.com
