Microsoft has made generally available a long-requested capability: moving databases from Azure Arc–enabled SQL Server instances directly to SQL Server on Azure Virtual Machines, all within the same Azure portal workflow. Administrators can now assess, configure, migrate, monitor, and cut over without leaving the Arc resource blade.
According to a report by Petri on July 15, the feature reached general availability (GA) after a preview that began in March. Microsoft’s own SQL Server enabled by Azure Arc release notes peg the milestone in June 2026. Either way, the door is now open to lift-and-shift SQL Server workloads into Azure infrastructure using a familiar, portal-driven experience.
One Portal, Two Destinations
Until now, Azure Arc’s native migration path pointed solely at Azure SQL Managed Instance, Microsoft’s managed PaaS offering. That choice works well for modernizing applications, but many organizations still need the full control that comes with a virtual machine. The new destination—SQL Server on Azure VMs—fills that gap.
The unified workflow means IT teams no longer have to juggle separate discovery tools, migration services, storage configurations, and monitoring dashboards. Whether the target is a managed instance or a VM, the control plane looks the same. Assess readiness, pick a destination, set up the data movement, watch progress, and cut over—all from the Azure Arc resource in the Azure portal.
That consistency eliminates retraining and reduces the risk of configuration drift when moving between different destination types. For shops managing hundreds of databases, the operational simplicity alone can shave days off a migration project.
How the Migration Works Under the Hood
Data movement relies on traditional backup and restore with log shipping, not a raw disk copy. The source Sql Server (connected to Azure Arc) takes full, differential, and transaction log backups. Those backup files go into Azure Blob Storage container, which acts as a staging area. A managed identity on the target Azure VM reads the backups and restores them, keeping the target synchronized with each new log backup.
When the cutover window arrives, the administrator initiates the final switch in the portal. The workflow applies the last incremental backup, brings the target database online, and directs applications to the new endpoint. Because most of the heavy data transfer happens in advance, downtime can be limited to final sync, validation, and connection string updates.
There is one critical placement rule: the Azure Blob Storage account and the target SQL Server VM must reside in the same Azure region. The storage account is an intermediary, not a long-term home. Permissions are handled through role-based access control (RBAC) and managed identities. The person running the migration needs the Storage Blob Data Reader role on the storage account and Reader on the resource group. The target VM’s managed identity also requires Storage Blob Data Reader to pull the backups.
What Gets Left Behind
The GA label does not mean every piece of a SQL Server instance magically appears on the new VM. Microsoft explicitly calls out unsupported server-level objects:
- SQL Server Agent jobs
- Credentials
- SQL Server Integration Services (SSIS) packages
- Server audit configurations
- High-availability and disaster-recovery topologies
Databases move, but scheduled tasks, linked logins, ETL pipelines, and auditing rules need separate migration planning. A successful database restore does not equal a working application. Teams must inventory these dependencies before cutover.
Other guardrails matter, too:
- A migration can move no more than 100 databases to the same Azure VM target at once, and after a 100-database migration finishes, you must wait at least 30 minutes before starting another batch.
- Existing databases on the target cannot be overwritten through Azure Database Migration Service.
- The target VM must be registered with the SQL IaaS Agent extension, which only supports a default instance or a single named instance for this migration scenario.
- Backup files for separate databases must live in separate folders inside the Blob container; nested folder structures are not supported.
- Source SQL Server versions 2012 through 2025 are covered, but the target cannot run SQL Server 2008 or older.
Administrators should see the built-in readiness assessment as the starting point, not the finish line. A green checkmark in the portal means the database is technically movable, not that the entire workload is ready for production.
A Steady March Toward Unified SQL Management
Azure Arc began as a hybrid inventory tool. Over the past two years, Microsoft has steadily turned it into a delivery mechanism for SQL Server operations. The timeline tells the story:
- July 2025: Continuous migration assessment GA
- Late 2025: Integrated migration workflow for Azure SQL Managed Instance GA
- March 2026: SQL Server on Azure VMs added as a target (preview)
- June/July 2026: SQL Server VM migration GA
Each step extended the same portal-based model—onboard your SQL estate to Arc, continuously assess it, and then move to Azure through a familiar interface. The business logic is clear: fewer tools for administrators, and a smoother ramp from hybrid management into Azure consumption for Microsoft.
SQL Server on Azure VMs matters precisely because not everything fits into a managed service. Legacy apps that need OS-level access, custom extended stored procedures, third-party monitoring agents, or specific patch rhythms often cannot move to Azure SQL Managed Instance without costly rewrites. The VM destination offers a lower-friction first step: relocate to Azure infrastructure while keeping the same SQL Server management practices, then decide later whether to modernize further.
Getting Started: Your Migration Checklist
If you are eyeing the new workflow, here is a concrete path forward.
1. Confirm source eligibility. The source SQL Server must be Azure Arc–enabled and running a supported version (2012 or later, any edition, Windows or Linux). Verify that the instance has the necessary permissions—least-privilege is the recommended approach, but sysadmin works too.
2. Prepare the target. Either select an existing Azure VM with SQL Server already installed and registered with the SQL IaaS Agent extension, or provision one during the migration. Double-check that the extension shows a green status in the portal; without it, the VM won’t appear as a target.
3. Set up Blob Storage. Create a storage account in the same Azure subscription and region as the target VM. Inside it, create a container for the backups. Grant the required RBAC roles to the user doing the migration (Storage Blob Data Reader on the storage account, Reader on its resource group) and to the target VM’s managed identity (Storage Blob Data Reader on the storage account).
4. Start the assessment. In the Azure portal, open your Arc-enabled SQL Server resource, go to Migration > Database migration. Run a readiness assessment to spot compatibility issues, sizing recommendations, and migration blockers.
5. Move the data. Take a full backup, optionally with COMPRESSION and CHECKSUM, and upload it to the Blob container. Follow with differential and log backups as close to the cutover window as possible. Use separate flat folders for each database if migrating multiples.
6. Validate connectivity. From the target SQL Server VM, run a RESTORE HEADERONLY FROM URL against the uploaded backup to confirm the managed identity or SAS token works.
7. Initiate and monitor the migration. Back in the portal, select the target VM and storage account, then start the migration. Azure Arc handles the restore and continuous synchronization. Monitor the job from the same dashboard.
8. Plan for the server-level objects that won’t move. Before cutting over, export SQL Agent jobs, SSIS packages, credentials, and audit specs. Review all login mappings and re-create them on the target. Test application connectivity with a non-production copy if possible.
9. Cut over and validate. Trigger the final cutover in the portal. Redirect applications, run integration tests, and confirm that all jobs and maintenance plans are running on the new VM.
What’s Next for Azure Arc Migrations
The GA of SQL Server VM migration completes the pair of native Azure destinations inside Arc. The foundation is now laid for Microsoft to expand further—perhaps to more exotic targets like Azure SQL Database, or to cover more server-level objects automatically. A unified migration control plane is also a natural hook for deeper Azure Arc management scenarios: post-migration configuration drift monitoring, compliance checks, and lifecycle management from the same pane of glass.
For now, the immediate win is practical: moving a SQL Server database to an Azure VM now feels like a logical extension of the hybrid cloud, not a painful detour through multiple tools and portals.