Every Azure SQL Server engagement starts with the same question: which of the three Azure SQL flavors do I deploy on? Azure SQL Database (the original PaaS), Azure SQL Managed Instance (the "near-100% SQL Server compatibility" PaaS), and SQL Server on Azure VM (full IaaS). Microsoft's marketing collateral implies they're interchangeable; in production they emphatically are not. This decision matrix walks through the eight constraints that actually pick one over the other — cross-database queries, SQL Agent, SSIS/SSRS, CLR, instance-level config, network architecture, licensing, and DR — so you can pick the right tier the first time instead of migrating between them six months in.
- Azure SQL Database: cheapest, most managed. Pick when the workload is a single logical database with no SQL Agent, no CLR, no cross-DB joins, and modest size (≤4 TB Hyperscale, ≤1 TB Premium/Business Critical).
- Azure SQL Managed Instance: closest to on-prem SQL Server. Pick when you need SQL Agent, cross-database queries, CLR, Service Broker, or Database Mail and your app would need refactoring to run on Azure SQL Database.
- SQL Server on Azure VM: you're the DBA. Pick when you need Linked Servers, FILESTREAM, replication topologies, fine-grained SQL Server build version control, or you're licensed BYOL and want to amortize Software Assurance.
- The right move for lift-and-shift from on-prem is almost always Managed Instance first, then evaluate Database after 6 months of usage data.
- Never default to "VM" because it's "the most flexible." VMs come with all of SQL Server's operational burden — and Azure's IaaS pricing erases the licensing savings if your DBA team is small.
The Three Options in One Paragraph Each
Azure SQL Database (the PaaS database)
A single logical database, no concept of "instance." Microsoft manages the OS, the SQL Server engine version, patching, backups, HA, and the underlying storage. Connect via a server-level connection string (tcp:myserver.database.windows.net,1433) but each database is isolated — there's no cross-database join, no SQL Agent jobs at the database level (replaced by Elastic Jobs), no Database Mail. Service tiers: General Purpose (Standard storage, separate compute), Business Critical (local SSD, AlwaysOn-style HA with readable secondary), and Hyperscale (up to 100 TB, near-instant restore, multi-replica read).
Azure SQL Managed Instance (the PaaS instance)
A near-100% feature-compatible SQL Server instance running as a managed service. You get instance-level objects: cross-database queries, SQL Agent, Service Broker, CLR (with assemblies), Database Mail, linked servers (to other MI/Azure SQL DB endpoints), distributed transactions. What you don't get: filesystem access (so no FILESTREAM, no native cross-server backup-to-disk), and a few peripheral features (e.g. no SQL Server replication publisher, only subscriber). Service tiers: General Purpose and Business Critical, with a Next-gen General Purpose tier introducing local SSD on storage hierarchy.
SQL Server on Azure VM (the IaaS option)
A Windows or Linux VM you provision yourself, running a standard SQL Server install. You manage the OS, patches, SQL Server licensing, backups, HA topology (Always On AG, log shipping, etc.), monitoring — everything. Azure provides only the hardware abstraction and the Azure-specific tooling (Azure Backup integration, SQL VM Resource Provider for license model switching, Disk auto-scaling). The marketplace images come pre-installed and license-included; you can also BYOL from an existing Software Assurance entitlement.
The Eight Decision Constraints (In Priority Order)
If any of these constraints rules out a tier, that tier is out — don't try to engineer around it. Each one has killed multi-quarter migration projects we've been called in to rescue.
Constraint 1: Cross-Database Queries
Does the application JOIN tables across two or more databases?
| Tier | Cross-DB query |
|---|---|
| Azure SQL Database | ❌ Not supported (Elastic Query is read-only and limited) |
| Managed Instance | ✅ Full support, same syntax as on-prem |
| SQL on Azure VM | ✅ Full support |
This single feature ends the Azure SQL Database evaluation for ~40% of the lift-and-shift assessments we run. Legacy SQL Server apps with multi-database designs (one DB per tenant, one DB per business unit, master/staging DB pairs) all fail this check.
Constraint 2: SQL Server Agent Jobs
Does the workload depend on Agent jobs for ETL, maintenance, scheduled queries, or service alerts?
| Tier | SQL Agent |
|---|---|
| Azure SQL Database | ❌ Replaced by Elastic Jobs (Azure Automation flavor) — different syntax, fewer features |
| Managed Instance | ✅ Full SQL Agent, including PowerShell job steps and operators |
| SQL on Azure VM | ✅ Standard SQL Agent |
Migrating thousands of Agent jobs to Elastic Jobs is months of work even with the conversion tooling. MI is almost always the easier path.
Constraint 3: CLR Assemblies and SQL CLR
Any custom .NET assemblies registered with CREATE ASSEMBLY? (Common with regex extension functions, custom aggregates, etc.)
| Tier | CLR |
|---|---|
| Azure SQL Database | ❌ Removed (security) |
| Managed Instance | ✅ Supported (with SAFE permission set; UNSAFE reviewed) |
| SQL on Azure VM | ✅ Full support |
Constraint 4: Linked Servers / Distributed Transactions
| Tier | Linked Servers |
|---|---|
| Azure SQL Database | ❌ Not supported |
| Managed Instance | ⚠️ Only to other Azure SQL endpoints + a few external sources via MSDTC (still limited) |
| SQL on Azure VM | ✅ Full support, including to Oracle / DB2 / Postgres via providers |
If you have a legacy SQL Server that links to an Oracle DB for nightly extracts, you're on VM.
Constraint 5: SQL Server Replication (Publisher)
| Tier | Transactional / Merge Replication |
|---|---|
| Azure SQL Database | ❌ Cannot be a publisher (can be a subscriber) |
| Managed Instance | ⚠️ Subscriber only; transactional publisher in limited public preview |
| SQL on Azure VM | ✅ Full publisher + distributor + subscriber |
Constraint 6: SSIS / SSRS / SSAS
| Tier | SSIS | SSRS | SSAS |
|---|---|---|---|
| Azure SQL Database | External (ADF) | ❌ | ❌ |
| Managed Instance | External (ADF SSIS-IR) | External (Power BI) | External (Azure Analysis Services) |
| SQL on Azure VM | ✅ In-instance | ✅ In-instance | ✅ In-instance |
Note: even on VM, the modern Azure recommendation is to extract SSRS to Power BI Paginated Reports and SSAS to Azure Analysis Services. SSIS-in-VM is still common.
Constraint 7: Network Architecture
This is the one most migration plans get wrong. The three tiers have very different network postures:
| Tier | Default endpoint | VNet integration |
|---|---|---|
| Azure SQL Database | Public DNS endpoint (firewall rules + service endpoints) | Optional Private Endpoint |
| Managed Instance | Always inside a VNet subnet — no public endpoint by default | Required — pick subnet at deploy |
| SQL on Azure VM | NIC in a VNet subnet, NSG controls | Standard VM networking |
MI's VNet requirement is often a surprise: you need a dedicated /27 (or larger) subnet, a route table, and a delegation. On-prem apps connecting over ExpressRoute will need DNS resolution from the on-prem DC to the MI endpoint — usually a private DNS zone + zone link.
Constraint 8: Licensing
| Tier | License model |
|---|---|
| Azure SQL Database | Per-vCore (DTU mode being deprecated); Azure Hybrid Benefit applies to bring per-core SA licenses |
| Managed Instance | Per-vCore; Azure Hybrid Benefit applies |
| SQL on Azure VM | PAYG (license-included image) or BYOL (Software Assurance); switchable via SQL VM RP |
If you already pay for SQL Server Software Assurance, BYOL on a VM with AHB is typically the cheapest. Without SA, the PaaS options are usually cheaper per equivalent compute, because their pricing already bundles the engine and infrastructure savings.
The Decision Tree
Walking the constraints in priority order:
START: What are you running?
│
├─ Does any DB use cross-DB JOIN / SQL Agent / CLR / Linked Servers / Replication publisher?
│ │
│ ├─ YES → Azure SQL Database is out.
│ │ │
│ │ └─ Do you need FILESTREAM, Linked Servers to non-SQL endpoints,
│ │ SSIS-in-instance, or fine-grained patching control?
│ │ │
│ │ ├─ YES → SQL Server on Azure VM
│ │ └─ NO → Azure SQL Managed Instance
│ │
│ └─ NO → Azure SQL Database is in scope.
│ │
│ └─ Is your largest DB ≤ 4 TB and you don't need instance config?
│ │
│ ├─ YES → Azure SQL Database (Hyperscale or Business Critical)
│ └─ NO → Azure SQL Managed InstanceCost Comparison: 8-Core, 64 GB RAM Workload
Indicative monthly cost in US East (East US 2 region) for a comparable workload at 8 vCore / 64 GB. List prices, 1-year reserved capacity where applicable, USD. Cross-check Azure pricing calculator before committing.
| Configuration | ~Monthly | Notes |
|---|---|---|
| Azure SQL DB — Business Critical Gen5 8vC | ~$2,500 | Includes HA replica, 1 TB storage, 7-day PITR |
| Azure SQL DB — Business Critical Gen5 8vC + AHB | ~$1,250 | ~50% reduction with Software Assurance |
| Azure SQL MI — Business Critical Gen5 8vC | ~$3,200 | Includes HA, 1 TB storage |
| Azure SQL MI — Business Critical Gen5 8vC + AHB | ~$1,600 | ~50% reduction |
| Standard_D8s_v5 (8vC / 32 GB) + SQL Server Enterprise license-included | ~$2,800 | + ~$200/mo for Premium SSD, no HA replica |
| Standard_D8s_v5 + SQL Server Enterprise BYOL + AHB | ~$550 | VM compute only; you bring the SA license |
The VM line items above do not include a second VM for Always On AG HA. The PaaS lines include HA built-in. To compare apples-to-apples, double the VM cost for HA, plus the cost of Witness, plus storage replication. A "cheap VM" deployment that achieves PaaS-level uptime is usually within 20% of MI pricing, with all the operational overhead.
Migration Path Recommendations
| From | Easiest destination | Why |
|---|---|---|
| On-prem SQL Server (lift-and-shift) | Managed Instance | Best feature parity; near-zero app refactor |
| Greenfield app on Azure | Azure SQL Database (Hyperscale) | Cheapest TCO when designed for the constraints |
| Multi-tenant SaaS with isolated DBs | Azure SQL Database — Elastic Pool | Pool budget across tenants; cost-effective at scale |
| Hybrid scenario with cross-cloud / cross-DC requirements | SQL Server on Azure VM | Only option supporting full networking flexibility |
| SQL Server 2008/2012 EOL forced move | SQL Server on Azure VM with Extended Security Updates | Azure VM gets free ESU through 2025+; PaaS targets 2019+ |
What the Azure DMS Won't Tell You
Azure Database Migration Service (DMS) is excellent at moving data. It is not a strategic-choice advisor. DMS will happily migrate your on-prem SQL Server straight to Azure SQL Database, blissfully ignoring that 30 Agent jobs depend on cross-database queries — only for the migration to "succeed" and the application to break the next day. Always run Data Migration Assistant (DMA) before DMS to surface compatibility blockers, and reconcile DMA's compatibility report against the eight constraints above.
Working with JusDB on Azure SQL Migrations
JusDB has migrated SQL Server workloads across all three Azure tiers. Our SQL Server consulting engagements typically begin with a 1–2 week Azure target-assessment that runs Data Migration Assistant, reconciles compatibility against the eight constraints above, and delivers a written recommendation with cost models for the top two viable tiers — not a Slack-thread guess at which Azure SKU to pick. For execution, we handle the full cutover on Azure SQL Managed Instance, Azure SQL Database, or SQL Server on Azure VM with documented rollback runbooks.
Explore SQL Server Consulting → | SQL Server Remote DBA → | Talk to a SQL Server DBA
Related reading: