SQL Server on Azure: SQL Managed Instance against SQL on a VM, feature by feature

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Start with blockers, not preference. SQL Managed Instance is a managed engine with no operating system access, no file system and a fixed backup model. SQL Server on an Azure VM is still SQL Server on Windows or Linux, and you still run it. The VM sections below cite Microsoft's Windows documentation, so check the Linux pages if that is your platform. If a workload depends on FILESTREAM, command-shell job steps, a non-SQL linked server or differential backups you take yourself, Managed Instance can't do that today. Use a VM, or change the workload first.

The commands and queries below come from Microsoft's published references. They were not run in a lab for this article.

Why it matters

The two options look close on a price sheet and differ sharply in operation. Microsoft describes Managed Instance as having almost 100% feature parity with SQL Server, and a VM as having full compatibility. The gap is small in count, but each item in it can stop a migration on its own.

The expensive failures come late. A team restores a test database, connects the application and signs off. The Agent job that shells out to copy a file, or the backup that a third-party tool must read, turns up after cutover. The checks further down are meant to find those first.

Who runs what

On a VM, high availability is your responsibility. Microsoft says its built-in VM recovery mechanisms do not guarantee that you will meet your SLA, RTO or RPO. You choose the operating system, the version and edition, the patch timing and the storage layout.

On Managed Instance, the service runs the latest stable engine on a patched operating system. You don't get host access. High availability is built in, so availability group and mirroring statements are not supported.

Registering a VM with the SQL IaaS Agent extension is free and adds portal management, automated backup and licence handling. It automates some tasks. It does not change who is responsible for the server.

Feature by feature

Everything in the Managed Instance column is taken from the T-SQL differences page and the features comparison, unless another source is linked. A VM runs the SQL Server product itself, so its column is normal product behaviour within the edition you install.

Three rows need more than a table cell.

Windows logins. The straight answer is "no" for CREATE LOGIN FROM WINDOWS. There is a route for applications that cannot change: Windows Authentication for Microsoft Entra principals, which uses Kerberos. The overview page labels it preview. Check its status before you depend on it, and note that identities must exist in Entra.

Machine Learning Services. On Managed Instance, the features comparison ties this to the SQL Server 2022 update policy. Update policy is covered below.

SSIS and Analysis Services. Managed Instance can host the SSIS catalog, but packages run on an Azure-SSIS Integration Runtime in Azure Data Factory. Analysis Services is not part of the instance, and tabular models move to Azure Analysis Services.

Limits that decide sizing

Resource limits differ by service tier. General Purpose stores files in Azure Blob storage, while Business Critical uses local storage and several replicas.

General Purpose has a trap that the table only hints at. Each file gets IOPS by its size: 500 IOPS and 100 MiB/s up to 129 GiB, rising to 7,500 IOPS and 250 MiB/s. A database with a single 100 GB data file gets 500 IOPS, however many vCores the instance has. Larger or additional files change that. Sizing by vCores alone misses it.

Next-gen General Purpose works differently. Throughput follows IOPS divided by 30, up to a cap per vCore count. Microsoft's example is a 4-vCore instance that reaches 145 MB/s at 4,350 IOPS and gains no more throughput above that. You pay for IOPS above the free quota in this tier only.

Log write rate is often the real ceiling for bulk loads and index rebuilds. Measure your peak log generation on the source and compare it with these figures before choosing a tier.

On a VM, disk and VM caps apply instead. Microsoft's SQL VM checklist gives the layout: separate drives for data, log and tempdb, read-only host caching on data disks, no caching on log disks, and tempdb on local SSD where possible. Above 160,000 IOPS it points to Premium SSD v2 or Ultra Disk.

Backup and the way back out

This is where the two models differ most.

Managed Instance takes automatic backups. Point-in-time retention is 7 days by default, configurable from 1 to 35 days, and long-term retention runs to 10 years. Storage is geo-redundant by default. If you change to locally redundant or zone-redundant storage, geo-restore is disabled.

You can't take a chain of your own. Native backups are copy-only and to Blob storage only. Any tool that expects to read your differential or log chain needs another plan.

Whether you can restore to SQL Server at all depends on two gates: the encryption on the database and the update policy.

Encryption comes first, because the default blocks the route. Microsoft says all newly created SQL databases are encrypted by default by using service-managed transparent data encryption (TDE). You can't take a copy-only backup of such a database, because the key can't be exported. Microsoft's remedies are customer-managed TDE, or disabling encryption on the database. With customer-managed TDE, the destination SQL Server must have access to the same key through the SQL Server Connector for Azure Key Vault.

A size limit applies as well. A copy-only backup can have up to 32 stripes, which Microsoft says is enough for databases up to 4 TB if backup compression is used. Test early if your database is larger.

The update policy sets the internal database format:

The default depends on how the instance is created. The SQL Server 2025 policy is the default for the portal and for REST API version 2026-08-01-preview onwards. The SQL Server 2022 policy is the default for PowerShell, CLI and older REST versions. The format change is one-way: moving to a newer policy upgrades the internal format permanently. The SQL Server 2022 and 2025 policies also end with that version's mainstream support, when instances move automatically to the policy for the latest major release.

Read the current value before you plan an exit. Azure CLI returns it from az sql mi show:

az sql mi show -g <resource-group> -n <instance> \
  --query "{format:databaseFormat, backup:currentBackupStorageRedundancy}"

The property names come from the REST reference. A value of AlwaysUpToDate means the native route back to SQL Server is closed.

On a VM, you own the whole chain. Automated Backup configures managed backup to a storage account for SQL Server 2016 and later Standard, Enterprise or Developer. Target user databases must use the full recovery model. Retention is 1 to 90 days, but it governs backup metadata in msdb, and files are not deleted from the container when it expires. You need a storage lifecycle rule to remove them.

az sql vm show -g <resource-group> -n <vm-name> --expand AutoBackupSettings

Treat these as ordinary SQL Server backups that another compatible server can restore, and prove that with a test restore.

High availability and patching

Managed Instance has no availability group for you to build. For a second region, use failover groups. Replication is asynchronous, so a forced failover can lose data. A failover group moves all user databases of the instance as a unit. Microsoft highly recommends a customer-managed failover policy. Both instances must share a DNS zone, which is set when the secondary is created, and the first instance in a subnet fixes the zone for that subnet. That is a build-time decision and it's awkward to fix later.

Planned maintenance follows the maintenance window setting. The default, 5 pm to 8 am, limits most activity, but urgent updates can fall outside it. To keep all updates inside a window, choose a non-default slot: 10 pm to 6 am local time, Monday to Thursday or Friday to Sunday. The feature covers planned maintenance only, and other causes can still interrupt connections.

On a VM, you build availability groups or failover cluster instances. Those bring a failover cluster to run. A recovery site needs network connectivity between sites, and Microsoft advises a replica domain controller there.

For patching, plan around a date. Automated Patching retires on 17 September 2027, and Microsoft says to avoid it in new environments and move to Azure Update Manager. It installs only updates marked Important or Critical. Cumulative updates not marked that way must be installed by hand, so don't assume a VM is current because the setting is on.

Network placement

Managed Instance lives in your virtual network, in a dedicated subnet delegated to Microsoft.Sql/managedInstances. That subnet must have a network security group and a route table attached, and it can hold nothing else. Microsoft sets a minimum of 32 IP addresses. After creation you can't move the instance or its virtual network to another resource group or subscription.

Connections use port 1433 inside the network. The optional public endpoint uses port 3342. The source says to use the domain name and allow traffic across the whole subnet range, because the underlying IP can change. A firewall rule pinned to one address can break when it changes.

A VM follows ordinary subnet and NSG design. Availability groups add listener considerations of their own, covered in Microsoft's availability group overview.

Checks that find blockers early

Run these read-only queries on the source instance. All catalog columns come from Microsoft's references for sys.database_files, sys.server_principals, sys.servers and sysjobsteps.

-- In each user database: FILESTREAM containers block Managed Instance
SELECT name, type_desc FROM sys.database_files WHERE type = 2;

-- Windows logins and groups that need an Entra plan
SELECT name, type_desc FROM sys.server_principals WHERE type IN ('U','G');

-- Linked servers: anything that is not a SQL family target is a blocker
SELECT name, product, provider FROM sys.servers WHERE is_linked = 1;

-- Agent job step types: only some run on Managed Instance
SELECT subsystem, COUNT(*) AS steps
FROM msdb.dbo.sysjobsteps
GROUP BY subsystem;

These cover four common blockers, not all of them. Microsoft's assessment rules list what migration tools test. Use those for the full picture, and keep the queries as a fast first pass.

Check the restore limits too. A backup can't be restored to Managed Instance if it contains an unsupported object, holds multiple backup sets or multiple log files, or would exceed the file count. The same page also states size limits of 8 TB for General Purpose and 4 TB for Business Critical. Those figures are lower than the instance sizes in the current resource limits table, so confirm them with a test restore if you are near either one.

Migration routes

Moving to a VM is ordinary server-to-server work. Backup and restore, log shipping or an availability group all remain available.

Moving to Managed Instance has its own online and offline routes. Online options include the Managed Instance link and Log Replay Service. Offline options include native backup and restore to Blob, BACPAC and BCP. SQL Agent jobs must be migrated with the offline Database Migration Service route, or scripted and re-created. That service supports only jobs with T-SQL subsystem steps, so jobs with SSIS package steps need manual migration.

The Managed Instance link has version rules that matter for rollback. From SQL Server 2016, 2017 or 2019, replication is one way: a manual failover breaks the link and failing back is not supported. Two-way disaster recovery starts at SQL Server 2022 and needs the matching update policy. The link works with Enterprise, Developer and Standard editions, and each source version needs a minimum cumulative update.

What to choose and why

These are editorial recommendations.

Where nothing blocks either option, the deciding question is whether you have people to run clusters, patching and backup verification. If you don't, buying that from the platform is usually worth the restrictions. If you do, a VM retains more control, within SQL Server edition, platform and support limits.

Risks and limits

Warning: Changing the update policy upgrades the internal database format permanently. Moving to Always-up-to-date also closes native restore to SQL Server and two-way link failover. Don't change it on a production instance until you have confirmed that no recovery or exit plan relies on the older format.

Warning: A forced failover on a failover group can lose recent transactions, because replication is asynchronous. Decide the acceptable data loss before an outage, and rehearse it.

Warning: Failing over a link from SQL Server 2016, 2017 or 2019 breaks the link, and there is no supported way back. Treat that failover as the cutover.

Other limits to keep in mind:

• Feature support changes. The T-SQL differences page has "isn't yet supported" entries, and some capabilities above are in preview. Recheck before you commit.
• This comparison does not cover licensing prices. Azure Hybrid Benefit, reservations and the licence-free DR benefit change the sums and need their own calculation.
• A VM's flexibility comes with work you can skip by mistake. Nothing warns you if a backup was never test-restored.

Sources

Opened 2026-11-10. Sources behind the corrections reopened 10 November 2026.

• T-SQL differences between SQL Server and Managed Instance
• Features comparison: Azure SQL Database and Managed Instance
• Managed Instance resource limits
• Managed Instance service tiers
• Managed Instance overview
• Update policy
• Automated backups
• Failover groups
• Managed Instance link
• Maintenance window
• Connectivity architecture
• Windows Authentication for Microsoft Entra principals
• Migration overview
• Transparent data encryption overview
• Restore a Managed Instance database to SQL Server
• Assessment rules
• IaaS against PaaS
• SQL IaaS Agent extension
• Automated Backup for SQL Server 2016 and later
• Automated Patching
• Performance best practices checklist
• High availability and disaster recovery on Azure VMs
• Availability group overview
• az sql mi, az sql vm, Managed Instances - Get

This article was originally published on 10 November 2026.