SQL Server Hosting: On-Premises, Azure VM, Managed Instance or Azure SQL Database
Azure has three destinations that carry the SQL Server name, and they are not interchangeable. The features your instance depends on usually decide the answer.
SQL Server feature support by Azure option
| What your instance uses |
SQL Server on an Azure VM |
Azure SQL Managed Instance |
Azure SQL Database |
| SQL Server Agent jobs |
Yes |
Yes, with some differences |
No (elastic jobs instead) |
| Cross-database queries |
Yes |
Yes, within the instance |
No (elastic queries instead) |
| Linked servers |
Yes |
Limited: to SQL Server and SQL Database, no distributed transactions |
No |
| CLR |
Yes |
Yes, with limits |
No |
| Service Broker |
Yes |
Yes, with differences |
No |
| Operating system access |
Yes |
No |
No |
-
Stay on premises
This fits when data must stay in your own data center, your hardware is recent, or low latency to local systems matters. You keep full control and the operating work. Upgrading to a supported version removes the end-of-support risk.
-
SQL Server on an Azure virtual machine
This is the closest match to what you run today: the same features, with you managing the operating system and SQL Server. It is a sensible first step when an application cannot change.
-
Azure SQL Managed Instance
This is the nearest thing to a drop-in move for an instance full of Agent jobs and cross-database queries, with Microsoft running the platform underneath.
-
Azure SQL Database
This suits applications built around single databases that can live without Agent jobs, linked servers and CLR. It is the most hands-off option.
We map your instance's features against this table before we recommend anything, and we write down the trade-offs and your way back out.