SQL Managed Instance
SQL Managed Instance is a managed deployment of the SQL Server engine that delivers near-full instance compatibility — SQL Server Agent, cross-database queries, the CLR, Service Broker, and instance-scoped features — without you running the OS or the engine. It is the migration target for existing SQL Server applications that Azure SQL Database cannot host unchanged.
It trades some of SQL Database's convenience for that compatibility: it deploys into a VNet subnet, provisions in tens of minutes rather than seconds, and costs more at the low end. Chosen for the right reason — a lift of an instance-dependent application — it is the path of least rework; chosen by default, it is overkill.
Instance Compatibility
Managed Instance closes the gaps that block a straight migration to SQL Database: SQL Agent for scheduled jobs, cross-database queries and transactions, the common language runtime, Service Broker, linked servers, and instance-level logins. If an application's database layer assumes a whole SQL Server instance, this is what makes the move possible without rewriting it.
Service Tiers
Two tiers mirror SQL Database's durability split. General Purpose uses remote storage and is the balanced default. Business Critical adds local SSD and an Always On replica set for the lowest latency and a readable secondary. The choice follows the same logic as SQL Database — Business Critical when latency and fast failover justify the cost.
Networking
Managed Instance always lives inside a VNet subnet that is delegated to it, so it is private by design and reaches the rest of your network natively. That subnet must be sized and planned up front — it cannot be shared with other resources, and an undersized or badly placed subnet is painful to change after the instance exists.
Migration
The Azure Database Migration Service and native backup-and-restore move existing databases in. The Managed Instance link feature uses SQL Server's own replication to keep an instance in sync with on-premises for near-zero-downtime migration and even hybrid read-scale, then a one-way cutover when you are ready. This is the smoothest path off on-premises SQL Server.
SQL Managed Instance — Near-full SQL Server instance — Agent, cross-database queries, CLR, VNet-native. Choose it to migrate an instance-dependent app with minimal change.
Azure SQL Database — Managed single databases and pools, newest features first, faster and cheaper at small scale. Choose it for new apps that do not need instance features.
- Choosing Managed Instance by default when Azure SQL Database would host the app — paying more and provisioning slower for compatibility you do not use.
- Undersizing or misplacing the delegated subnet, which is hard to change once the instance is deployed into it.
- Expecting seconds-scale provisioning and scaling — Managed Instance operations take tens of minutes, which affects deployment and scaling plans.
- Migrating with a one-shot backup/restore when the link feature would have given near-zero-downtime cutover.
- Assuming 100% SQL Server parity — a few instance features still differ, and the unsupported ones surface during testing.
- Putting the instance on General Purpose for a latency-critical workload that needed Business Critical's local SSD and replica.
- Choose Managed Instance specifically to migrate instance-dependent SQL Server apps; use Azure SQL Database for new work.
- Plan and size the delegated VNet subnet up front — it is dedicated to the instance and hard to change later.
- Use the Managed Instance link feature for near-zero-downtime migration and hybrid read-scale before cutover.
- Pick Business Critical when latency and fast failover matter; General Purpose otherwise.
- Validate the specific instance features your app uses against the supported list before committing.
- Authenticate with Microsoft Entra and keep the instance reachable only over its private VNet path.
Knowledge Check
What is the main reason to choose SQL Managed Instance over Azure SQL Database?
- Near-full SQL Server instance compatibility — Agent, cross-database queries, CLR — for migrating an existing app
- Lower cost at small scale, since it shares one pool of compute across many small databases instead of dedicating capacity
- Faster, seconds-scale provisioning and scaling of compute
- A serverless, scale-to-zero billing model that pauses when idle
Why must the delegated subnet for a Managed Instance be planned carefully up front?
- It is dedicated to the instance and hard to resize or relocate after deployment
- It determines the SQL Server engine version the instance runs after deployment
- It sets the backup retention period for the instance
- It can be shared with other resources in the VNet to save IP space
Which tool gives near-zero-downtime migration from on-premises SQL Server to Managed Instance?
- The Managed Instance link feature, which keeps the instance in sync until a one-way cutover
- A single native full backup-and-restore taken right before cutover
- Exporting and importing a BACPAC file of the whole database during a planned maintenance window
- Active geo-replication from the on-premises server
You got correct