Applies toSQL Server 2016+ on Azure VMs to Azure SQL Managed Instance (General Purpose / next-gen GP / Business Critical)
1. Why move off the VMs
| Work on SQL VMs | On MI |
|---|---|
| OS and SQL patching, CU testing | Managed by Azure (update policy you choose) |
| AG / cluster design, quorum, witness | Built-in HA (zone redundancy optional) |
| Backup jobs, retention, restore tests | Automated backups, PITR 1–35 days, LTR up to 10 years |
| Monitoring agents, disk sizing | Platform metrics, storage scale with a setting |
| Licence: VM + SQL (AHB) | vCores (AHB applies; GP 1 EE core = 4 vCores) |
Build the case on operations effort saved plus any VM/disk over-provisioning, not only list prices.
2. Readiness
- Run the MI assessment (Azure Migrate / Arc / DMS) against the VM instance.
- Typical blockers on VMs: FILESTREAM,
xp_cmdshell, OS-level jobs, third-party agents, very high log rates. Fix or keep those databases on VMs. - Check the MI storage and log rate limits for your tier against the VM's baseline.
3. Choose the method
| Method | Downtime | Why on Azure |
|---|---|---|
| MI link | Seconds | VM and MI are in the same region/VNet family — low latency, fast seeding |
| LRS | Minutes | Reuse backups to URL already configured on the VM |
Native backup to URL + RESTORE FROM URL on MI | Restore time | Small databases (full restore only; no NORECOVERY chain on MI outside LRS) |
4. Network inside Azure
- MI in its own delegated subnet (in the same spoke or a data spoke), peered to the app VNets.
- Apps already in Azure: just new DNS name (
<mi>.<dnszone>.database.windows.net) through the VNet — no on-premises routing needed. - Use a DNS alias (CNAME in your private DNS) for the app connection so later moves are easy.
5. Cut over and consolidate
- Move databases from several VMs into one or a few MIs (instance pools or larger MIs) — consolidation is where the savings are.
- Cross-database queries between databases that land on the same MI keep working.
- Use failover groups for DR (MI to MI in the paired region) — replaces your VM DR replicas.
6. Decommission
- Keep the VM databases read-only for an agreed period.
- Take final backups to long-term storage.
- Delete VMs, disks, load balancers, cluster witnesses; release AHB licences and reservations (exchange VM reservations for SQL MI reservations where possible).
Tip
Do this per application, not per VM. An app's databases often span two VMs (reporting on one, OLTP on another); landing them on the same MI lets you remove linked servers along the way.