Almost every Azure migration involving SQL Server reaches this fork, and the wrong turn is expensive in a specific way: you discover the missing feature after the migration, in production, with a deadline behind you.
The decision is mostly about surface area — how much of SQL Server your application actually uses.
The three options
SQL Database (single database or elastic pool) — the PaaS offering. Fully managed, automatic patching, built-in high availability, serverless and hyperscale tiers. It does not have SQL Agent, cross-database queries within the server, CLR, Service Broker, linked servers or several other instance-level features.
SQL Managed Instance — near-full SQL Server instance compatibility as a managed service. SQL Agent, cross-database queries, Service Broker, CLR and linked servers all work. It deploys into your VNet, supports native backup/restore from a URL, and the Database Migration Service can move you with minimal changes. It costs more than SQL Database and takes considerably longer to deploy or scale.
SQL Server on a VM — you manage everything, you get everything, including features the managed products do not expose and the ability to run a version Microsoft no longer supports in PaaS. Also: you patch it, you configure Always On, you own the backups.
The decision tree
Start at SQL Database. If the application works there, take it: it is the cheapest at the low end, the operational surface is smallest, and serverless tiers mean a staging database costs almost nothing when nobody uses it.
Move to Managed Instance if you hit any of: SQL Agent jobs you cannot replace with an external scheduler, cross-database queries, Service Broker, CLR assemblies, linked servers, or a third-party application with a vendor-supported configuration that requires instance-level access. Managed Instance exists precisely for lift-and-shift of a real SQL Server, and for that job it is the right tool.
Only go to a VM if you need a feature neither offers (FileStream, certain replication topologies, an unsupported version), you have a licensing arrangement that makes it dramatically cheaper, or a vendor will not support anything else. Treat it as the exception it is — a VM means you own patching and failover, and most teams underestimate what that costs over three years.
Run the Data Migration Assistant against your existing database before any of this. It reports exactly which features block which target, which turns the debate into a list.
Cost, and the levers people miss
- Azure Hybrid Benefit applies to all three and is the largest single discount for SQL Server Enterprise licences with Software Assurance. Check your entitlements before pricing anything, as in the Azure bill piece.
- Serverless tier for SQL Database is genuinely good for development, internal tools and anything with quiet periods — it pauses and you stop paying for compute.
- Elastic pools when you have many small databases with uncorrelated peaks. This is the multi-tenant SaaS case and the saving is substantial.
- Reservations on the compute of vCore-model databases, once the size is stable.
- Hyperscale for very large databases, where the storage architecture changes the backup and restore story entirely — near-instant restores regardless of size.
The migration
For Managed Instance, the path that keeps downtime short is the Database Migration Service in online mode: it restores your backups and then replicates changes until you cut over. Downtime is the cutover itself, typically minutes.
For SQL Database, transactional replication or DMS online mode, with the same shape.
Either way, three things decide whether it goes well:
- Run the Data Migration Assistant early and fix the blockers before the migration weekend, not during it.
- Test the slowest queries against the target before cutover. Compatibility level and cardinality estimation differences produce regressions, and they are found by running the query, not by reading documentation.
- Keep the source running, read-only, for a week. The rollback plan is repointing the connection string, and it only exists if the source is still there.
After you land
Enable auditing to a Log Analytics workspace, Microsoft Defender for SQL, private endpoints with public network access disabled, and Transparent Data Encryption with a customer-managed key if your compliance line requires it. Check the automated backup retention actually matches what you promised the business — the default is shorter than most people assume, and long-term retention is a separate setting.
We work through this decision in the migration phase of cloud engagements, usually with the Data Migration Assistant report on the table so the conversation is about facts rather than preferences.
What to do this week
Run the Data Migration Assistant against your production database with SQL Database as the target. The blocker list it produces answers the whole question in about twenty minutes, and it is the document to bring to the architecture discussion.