Azure SQL Managed Instance vs Azure SQL Database: How I Actually Made the Call

A field decision from a real production migration — not a feature-matrix blog.

When we migrated two internal enterprise applications (plus an integration layer) from on-premises SQL Server to Azure, the single most consequential decision in the whole programme was not the App Service tier, not the CDN, not the CI/CD design. It was the database platform. Azure gives you two serious PaaS options for SQL Server workloads — Azure SQL Database and Azure SQL Managed Instance (SQL MI) — and almost every comparison article online reads like a spec sheet. This post is different. It's the actual reasoning I went through, the evidence I gathered, the objections I had to answer during architecture review, and the trade-offs I knowingly accepted.

If you're staring at the same fork in the road, I hope walking through my decision saves you a few weeks. The starting point: what we were actually migrating

Context matters more than features, so here's ours: • One production SQL Server database, roughly 200 GB in size, that had lived on-prem for years. • Three separate backend services — two application backends and one integration API — all reading and writing to that same database. • More than 25 SQL Server Agent jobs running scheduled work against the database: batch processing, data movement, housekeeping. • A hard requirement that the database must never be exposed to the public internet — access only over a private network on port 1433. • A small team, a compressed timeline (we went from zero Azure resources to production in weeks, not months), and a real budget owner asking why every euro was being spent.

That last point is important. This wasn't a greenfield app designed cloud-native. This was a lift-and-shift of a living, heavily-scheduled, single-database system that three services depend on simultaneously. The fork: two genuinely good options

Azure SQL Database is the "born in the cloud" option — a database-scoped service, fast to provision, cheap to start, with elegant HA options like zone-redundant compute and active geo-replication. I took it seriously. In fact, during the evaluation I fully sketched out what a production + DR architecture on Azure SQL Database would look like for us: a General Purpose single database at 16 vCores with zone-redundant compute in the primary region, an asynchronous geo-replica standing by in a secondary region, 7-day PITR for operational recovery, and long-term retention for compliance. On paper it was a beautiful design.

SQL Managed Instance is the "SQL Server, but managed" option — an instance-scoped service deployed inside your own virtual network, with near-100% surface-area compatibility with on-prem SQL Server.

The honest question I forced myself to answer: does our workload actually need the instance, or am I just choosing the familiar thing?

During architecture review, this exact challenge came back to me formally: "Re-validate whether SQL Managed Instance is the intended PROD choice." Someone has to def…