There are four ways to run SQL Server with Azure in the picture, and they are almost always presented as a menu of products. They are not a menu. They are four points on a single gradient, and the thing that changes along it is not price or performance but authority: who decides when the engine gets patched, who owns the backups, who is responsible when high availability is tested for real, and who chooses what version you are running next year. Every genuinely difficult question in this series is a question about where on that gradient a given workload belongs, and almost none of them are answered by a pricing calculator.
The gradient
At one end sits Azure SQL Database, where Microsoft runs the database. You get a database and a service level agreement on it, and you do not get an instance: no Agent, no cross-database queries, no linked servers, no Windows logins, no ability to take or restore a backup file yourself. Patching, backups, high availability and the engine version are all Microsoft’s, permanently and without an opt-out.
Next is Azure SQL Managed Instance, where Microsoft runs the instance and you keep instance semantics. The Agent is there, cross-database queries work, linked servers and the common language runtime and Service Broker are back, and a database can be restored into it from a backup file the way you have always done it. Patching and the underlying availability model remain Microsoft’s, but you gain a real say over the engine version through a mechanism called the update policy, which is one of the more consequential and least understood choices in the whole family.
Then SQL Server on an Azure virtual machine, where you run everything on Microsoft’s hardware. This is not a compromise option, it is the actual product, unmodified, with every feature it has ever had, including the ones the platform services have no answer for. What you have delegated here is the datacentre and nothing else. Patching is yours. Backups are yours. High availability is yours to build, and the service level agreement covers the virtual machine, never the SQL Server process running on it.
And at the far end, SQL Server enabled by Azure Arc, where you run everything on your own hardware and Microsoft runs the paperwork. The server stays exactly where it is. What moves to Azure is the management and commercial wrapper: an inventory, a licensing posture that is queryable as metadata, extended security updates without a volume-licensing negotiation, a free and continuously refreshed migration assessment, and Entra authentication for recent versions. It is the option most people forget is an option, and for a large number of estates it is the correct answer for the next two years.
The question is not which product is best. It is which responsibilities you are willing to stop holding, and which ones your application will not let you put down.
Versionless, or pinned
The cleanest way to feel the difference between the platform services and the virtual machine is to ask what version you are running. On Azure SQL Database the question has no answer. The engine is continuously updated and always on the latest stable build, which means no upgrade project, no cumulative update window, and no end-of-support date, ever again. That is the single largest operational benefit anywhere in this series, and it is also an irreversible surrender: you will never decline an engine change, never defer one for a vendor’s certification cycle, and never pin a build because an application is known to behave differently on the next one.
Managed Instance splits the difference in an interesting way. It has an update policy, and the choice you make there governs the engine format you get, the range of compatibility levels available to you, and whether a database can ever be moved back out to a SQL Server instance. The default for every instance, new and existing, is the policy named for SQL Server 2022, which caps compatibility at 160. There is an always-up-to-date policy that behaves like the versionless model and unlocks the newer levels, and choosing it is a one-way door: once an instance is on it, it cannot go back. Microsoft recommends the evergreen policy and ships the pinned one as the default, which tells you something honest about how confident anyone is that evergreen suits every estate.
On a virtual machine you are pinned by definition, and that is frequently the reason to be there. A vendor who certifies against a specific build, an application with a known optimiser sensitivity, a regulated system where any change requires a revalidation cycle: these are legitimate architectures, not failures of ambition, and the versionless services cannot accommodate any of them. If you need to be able to say no to a change, you need a virtual machine, and the rest of this series will not talk you out of it.
Where the boundaries actually sit
Three practical limits are worth carrying because they end conversations early. Azure SQL Database reaches 128 terabytes on Hyperscale. Managed Instance reaches 32 terabytes on its next-generation General Purpose tier and 16 on the classic one. A virtual machine will hold considerably more than either, into the hundreds of terabytes, because it is bounded by how many disks you are willing to attach. Size alone rarely decides anything, but it removes options at the top end faster than people expect.
The business intelligence services are the more common ambush. Reporting Services runs on neither platform service. Managed Instance will happily host a report server’s catalogue databases, but the report server itself needs a machine to run on, and the product line is being wound down: there will be no Reporting Services in SQL Server 2025, the existing 2022 server is supported into 2033, and the direction of travel is Power BI Report Server. Integration Services packages do not run in either platform service either, but they have a clean destination in the Azure-SSIS integration runtime inside Data Factory, which is alive and not deprecated. Analysis Services is a separate Azure service entirely. Only the virtual machine runs all three natively, and if your SQL Server is really a business intelligence server wearing a database’s clothes, that is the whole answer.
Things that look like options and are not
A few adjacent products come up in every one of these conversations and deserve a boundary rather than a chapter. SQL database in Microsoft Fabric went generally available at the end of 2025, and it is the Azure SQL Database engine surfaced as an item inside Fabric with automatic replication into OneLake. It is a real and sensible thing to want when the transactional store needs to sit inside the analytics estate rather than beside it, and it is not a migration target for a lifted line-of-business database. Think of it as the analytics platform growing a transactional front end, not as a fifth deployment option.
Azure Synapse is not dead, but it is directional in a way that should stop you starting anything new there. Its Data Explorer component was retired in late 2025, and Synapse Link for SQL is discontinued in SQL Server 2025 in favour of Fabric mirroring. New analytics work goes to Fabric. Azure SQL Edge was retired in September 2025 and is simply gone. Cosmos DB is a different category of product and belongs in this article only as a clarification: it is not a way to run SQL Server, whatever the query dialect suggests.
Why this is urgent in a way it was not two years ago
This series exists now rather than at any other time for three reasons, and they compound.
SQL Server 2016 left extended support on 14 July 2026, a week before I wrote this. That alone would be routine. What is not routine is that the old escape hatch has closed: moving a 2016 workload onto an Azure virtual machine no longer earns free extended security updates for it. That changed on 1 April 2026 as part of a broader pricing-consistency alignment, and it invalidates the argument at the centre of essentially every migration article written before this year. SQL Server 2014, which is older, is explicitly grandfathered and does still get them free in Azure, which produces the genuinely strange situation where the newer unsupported version is the more expensive one to keep alive. If you have been carrying “lift it to Azure and the patches are free” as a rule of thumb, it is now wrong in the specific case where you are most likely to reach for it.
SQL Server 2012 is past the end of its extended security updates entirely. There is no longer a price at which it can be patched, and Microsoft’s current guidance for it is simply to upgrade. That converts every 2012 conversation from a cost discussion into a risk discussion, which in my experience is the conversation that actually moves budget.
And the migration toolchain collapsed. The Data Migration Assistant, Azure Data Studio, the Azure SQL Migration extension that lived inside it, and the classic Database Migration Service have all been retired, three of the four within the last eighteen months. Nearly every migration guide you will find describes a workflow that cannot be executed today. That story, and what actually replaced them, is a full article later in this series, and it is the one I would read first if you are already mid-project.
An estate that was safe to leave alone in 2024 is not safe to leave alone now, and the reason is not that anything got worse. It is that the free options quietly expired.
The decision, stated honestly
Microsoft frames the choice as a question about whether you want to manage the database, apply the patches and take the backups, or delegate all of that to Azure. That is a fair opening question and it is not sufficient, because it assumes the answer is yours to give. Usually it is not. The application decides. If it uses the Agent, queries across databases, reaches through a linked server, or authenticates Windows principals, then the most delegated option is off the table regardless of how much you would like it, and the real choice is between the instance-scoped service and a virtual machine.
The second constraint is licensing posture, and it is the one most often discovered too late. What you already own, and whether it carries Software Assurance, changes the relative cost of these options by multiples rather than percentages, and it does so unevenly: an Enterprise estate with active Software Assurance is worth four times as many cores on one tier as on another, and worth nothing extra on the tier Microsoft now recommends by default. That is not a footnote. It is a load-bearing chapter, and it has one later in this series.
The third is honesty about availability. The platform services carry a service level agreement on the database. A virtual machine carries one on the virtual machine, and Microsoft says plainly that it does not cover the SQL Server process, and that building a supported high availability configuration does not earn you an additional commitment. You can absolutely build something excellent on infrastructure, and many estates should, but you are building it, you are testing it, and you are answering for it at three in the morning. Pretending otherwise in a design document is how organisations end up believing they have bought an availability guarantee they were only ever renting hardware for.
How the rest of this goes
The next three articles take the destinations one at a time and in order of decreasing delegation: the database without the instance, the instance that survived the move, and the virtual machine where you get everything and owe everything. Each is followed by a build sheet that actually performs the migration to that destination, written so a competent administrator can reproduce it from the text. After those comes the fourth option, Arc-enabled SQL Server, which is less a destination than a bridge with a good toll system, and which leans on the Azure Arc series rather than re-teaching onboarding. Then licensing and cost in full, because by that point you will have seen how often it is the deciding factor. Then the migration doctrine and the state of the toolchain. And finally the decision itself: which workloads go where, which estates should not move at all yet, and how to defend either answer to the people paying for it.
Azure SQL
Next: [SQL 2] Azure SQL Database: The Database Without the Instance ›
