Managed Instance exists because Microsoft eventually accepted that the missing instance was killing migrations. Everything the database-scoped service removed, this one puts back: the Agent, cross-database queries, linked servers, the common language runtime, Service Broker, Database Mail, and the ability to restore an ordinary backup file taken from an ordinary SQL Server. It is the closest thing to lifting a real instance into a managed service that exists, and it is where most estates with a decade of accumulated dependencies actually belong. It also carries two or three decisions that cannot be undone afterwards, and those are what this article is really about.
What comes back
The restoration of instance scope is genuine rather than cosmetic, and it is worth enumerating in prose because the list is the entire commercial case for the product. SQL Server Agent runs jobs, which means the estate’s scheduled work moves rather than being rebuilt. Queries reach across databases by three-part name, and transactions span them. The common language runtime executes, without file system access. Service Broker works, including between managed instances. Linked servers connect, to SQL family targets. Database Mail sends. Distributed transactions across instances have been generally available for years now, and if you have read somewhere that they remain in preview, that page is stale: it is a genuinely supported capability and has been since late 2023.
Most of these arrive with a small, sharp edge. The Agent is the Agent, but without alerts, proxies, or the shell escape hatch, and its mail profile has to carry one specific reserved name for anything to send. Linked servers reach SQL family targets, so the link to the ancient Oracle box is a redesign rather than a migration. The runtime cannot touch the file system, which is exactly the assembly you will discover in week four. None of these are showstoppers, and collectively they are the reason a Managed Instance migration is a project with a discovery phase rather than a restore and a change of connection string.
The capability that most often decides the choice is quieter than any of those. Windows authentication for Entra principals, using Kerberos, is generally available, which means a domain-joined application whose connection string cannot be changed and whose vendor no longer exists can authenticate against a managed instance. I have seen that single feature carry an entire business case, because the alternative was a rewrite nobody was going to fund.
Managed Instance is not a better database. It is a place where the last fifteen years of decisions somebody else made are still allowed to be true.
The update policy is the version decision
This is the setting I would put first on any design review, because it is the one that quietly decides what the instance can do for the rest of its life, and it has a default that most people never consciously choose.
There are three policies. One is named for SQL Server 2022, one for SQL Server 2025, and one is called always-up-to-date. The policy governs the engine format, the range of database compatibility levels available, the backup compatibility of what the instance produces, and whether a database can ever be moved back out to a real SQL Server. The default, for every instance already running and every instance you create today, is the SQL Server 2022 policy, which caps compatibility at 160 with a default of 150. The 2025 policy and the always-up-to-date policy both open the range to 170.
Two things about that are worth carrying into a design conversation. The first is that always-up-to-date is a one-way door, stated as plainly in the documentation as it could be: once enabled, you cannot go back. The second is that Microsoft recommends the evergreen policy while shipping the pinned one as the default, and the transition from the 2025 policy to always-up-to-date is currently disabled anyway. Read that combination honestly. It says the platform team believes evergreen is right and is not confident enough to impose it, and it means the majority of real managed instances in the world are sitting at a compatibility ceiling of 160 without anyone having decided that.
The practical consequence surfaces in two places. If someone tells you Azure SQL supports compatibility level 170, they are describing the database-scoped service, and it is true there; on a default managed instance it is not available. And if there is any prospect of ever moving a database back out, to a virtual machine or on-premises, the always-up-to-date policy forecloses it. That is not usually a reason to avoid evergreen, but it is a reason to decide rather than to inherit.
Three tiers, and the trade the newest one asks for
The classic General Purpose tier is the remote-storage model: stateless compute over durable storage, where a failover is a process moving and a cache going cold. It caps at 16 terabytes, 100 databases and 80 vCores, and zone redundancy became available for it in mid-2025.
Business Critical is the local solid-state model with an Always On style replica set and a free readable secondary. It is the tier for workloads that need low latency and real throughput, and it is the only tier the near-zero-downtime migration path can reach online, which occasionally decides the tier before performance does.
Next-generation General Purpose went generally available in late 2025 and is the interesting one. It moves onto Elastic SAN storage and lifts the ceilings substantially: 32 terabytes at higher vCore counts, 500 databases per instance, and up to 128 vCores. It is frequently described as costing the same as General Purpose, and that is true only of the baseline. Input and output beyond an included allowance is chargeable, and there are memory sliders that also bill, so a workload that is genuinely storage-hungry can land above classic General Purpose rather than level with it. Model it rather than assuming it.
The real trade is availability, and the documentation says it without hedging: zone redundancy is not available for the next-generation General Purpose tier. That is the whole sentence and it is worth quoting to anyone who is about to choose that tier for a production system with an availability commitment attached. Its failover behaviour deserves the same care, and deserves to be quoted in full rather than reduced to its worst number. The documented behaviour is that failover duration scales with the number of databases, up to ten minutes, and that while the instance becomes available after about two minutes, some databases may be available after a delay. Quoted whole, that is a reasonable characteristic of a tier that holds five hundred databases. Quoted as “ten minute failovers”, it sounds like a defect.
What availability you are actually buying
The service level agreement here has more structure than most people assume, and the numbers have moved, so this is a place to check the current consolidated document rather than a remembered figure. The shape is that both General Purpose and Business Critical carry a higher commitment when deployed zone-redundant than when not, so zone redundancy is not a Business Critical privilege. If you have been carrying a rule that only the expensive tier benefits, it is worth re-reading. Next-generation General Purpose, being unable to be zone-redundant at all, cannot reach the higher figure.
There is one condition attached to all of it that I rarely see in a design document and have twice seen matter. The commitment is conditioned on maintaining a compliant networking configuration. Managed Instance lives in a delegated subnet in your virtual network, with required rules on the network security group and the route table, and teams tighten those. If someone hardens the subnet in a way that breaks the required configuration, the instance may keep working while the service level agreement quietly no longer applies. That is a genuinely unusual property, and it means the network hardening review and the availability design are the same conversation.
Backups, and the escape hatch that mostly is not one
Automatic backups are the platform’s, with point-in-time restore and long-term retention, and they are better than what most estates run for themselves. The question that always follows is whether you can take your own backup off the instance, and the answer has a shape worth getting exactly right because it is widely mis-stated in both directions.
You can take a full copy-only backup to a URL. You cannot take differential, log, or file-snapshot backups, and you cannot write to a disk or tape device. And the constraint that actually bites: copy-only backup is blocked when the database uses service-managed transparent data encryption, which is the default state of every database you did not deliberately configure otherwise. So the honest position is that the escape hatch exists and is unavailable by default. If the ability to extract your own backup matters, whether for an exit strategy, a regulator, or a development refresh, then customer-managed keys are a decision to take at design time, not a thing to discover during an audit.
Ask early whether you will ever need to get your data out in a form you control. The answer changes an encryption decision you otherwise would have left at its default.
The one-way doors, and the ways to spend less
Collation is fixed at instance creation and cannot be changed afterwards. If the source estate uses something other than the default, that has to be right on the first attempt, and getting it wrong means rebuilding the instance rather than fixing it. The update policy discussed above is the second one-way door. Between them they account for most of the rebuilds I have watched teams perform in the first month.
On the other side, there are three cost mechanisms that are genuinely underused. Instance pools are the only place a two-vCore instance can exist, and are the right home for a collection of small instances that individually cannot justify the minimum size. Stop and start is generally available on General Purpose, and a stopped instance bills for storage only with no compute and no license, which makes non-production instances dramatically cheaper if anybody remembers to stop them; note that it is blocked when the instance is in a failover group, is participating in a link, is zone-redundant, or lives in a pool, which excludes most production. And there is a free offer, one instance per subscription for twelve months against a monthly compute allowance, which is the fastest honest way to find out whether an application’s dependencies survive the move.
Where it belongs
Managed Instance is the default destination for a lifted estate with instance dependencies, which in practice means most estates older than about five years. It is the right answer when the Agent matters, when databases talk to each other, when Windows authentication has to keep working, and when nobody is going to fund a rewrite. It is the wrong answer when the workload genuinely needs the whole product, Reporting Services and Analysis Services and the exotic features, and it is an expensive answer for a single small database that would have been happy in the database-scoped service.
The build sheet that follows takes both realistic paths into it: a native restore from a URL for an old source, which is how a compatibility level 110 database from 2012 arrives intact, and the Managed Instance link for anything from 2016 with the right service pack upward, which is the near-zero-downtime route and the only online path into Business Critical. Both are written to be reproducible, including the certificate work that the documentation glosses over and that consistently costs people an afternoon.
Azure SQL
‹ Previous: [SQL 2.1] Build Sheet: A First Azure SQL Database, Migrated
Next: [SQL 3.1] Build Sheet: Migrating to Managed Instance ›
