If you are weighing a move from on-premises SQL Server to Azure, two questions come up before any of the others: how much of the work Microsoft actually takes off your hands, and how many users the platform will support. Both questions have clearer answers than most of the material online suggests — and in the case of the second one, the question itself is usually the wrong shape.

What is Azure SQL Managed Instance?

Azure SQL Managed Instance is a fully managed deployment option in the Azure SQL family that gives you an entire SQL Server instance rather than a single database. That distinction is the whole point of the product.

Azure SQL Database gives you one database in isolation. Anything that reaches beyond the boundary of that database — SQL Server Agent jobs, cross-database queries, linked servers, Service Broker, CLR, Database Mail — either does not exist or works differently. For a greenfield application that is rarely a problem. For an established SQL Server estate built up over a decade, it usually is.

Managed Instance closes most of that gap. It offers near-complete surface-area compatibility with the SQL Server database engine, which means the majority of existing databases can be moved with little or no application rewriting. That is why it tends to be the right destination for a lift-and-shift, while Azure SQL Database suits applications designed for it from the start.

Is Azure SQL Managed Instance PaaS?

Yes. Managed Instance is a platform-as-a-service offering. You do not get a server, you do not get an operating system, and you do not get Remote Desktop access. Microsoft provisions and runs the underlying infrastructure; you interact with a SQL Server instance endpoint.

It is worth being clear about what that rules out, because it is the most common source of surprise during a migration. If something in your current environment depends on the machine rather than the database engine, it does not come with you:

• Scheduled tasks or scripts running on the SQL Server host
• Local file shares, mapped drives, or processes reading and writing to the server's file system
• Third-party agents installed on the server
• Anything relying on the Windows account the service runs under

SQL Server Agent jobs themselves do come across, which is a major advantage over Azure SQL Database. What does not come across is anything a job does outside the engine — a job step calling a batch file, or writing output to a local folder, needs rethinking before you migrate rather than after.

Is Azure SQL Managed Instance fully managed?

Yes, and this is where the phrase does more harm than good. "Fully managed" describes the infrastructure, not the database.

Microsoft takes care of: the operating system and engine patching, high availability and failover, automated backups and point-in-time restore, the underlying hardware, and the storage layer.

You still own: schema design, indexing strategy, query performance, the security model and who can access what, data retention decisions, and — the one that catches people — cost.

A poorly indexed database does not become fast because it moved to Azure. It becomes a poorly indexed database that bills by the hour. Compute is the dominant line item on a Managed Instance, and inefficient queries consume compute continuously. We have seen more than one migration where the monthly bill, not the outage report, is what finally triggered a performance review that should have happened years earlier.

The honest summary: Managed Instance removes the work of keeping a database server running. It does not remove the work of running a database well. If nobody owned indexing, query tuning, or capacity planning before the migration, nobody will own it afterwards either — and the consequences simply become visible on an invoice instead of in a help desk queue.

What is the maximum number of users on an Azure SQL Database?

This is one of the most common questions asked about Azure SQL, and it does not have a direct answer, because the platform does not limit users in the way the question assumes.

There is no meaningful cap on how many logins or database users you can create. What is actually constrained is concurrency, and it comes in two forms:

• Concurrent sessions — how many connections can be open at once. On the vCore purchasing model this ceiling is high (tens of thousands) and rarely the binding constraint.
• Concurrent workers — how many requests can actively execute at the same time. This scales with the number of vCores or DTUs you have provisioned, and it is almost always the limit you hit first.

The practical consequence is that "how many users can we support" depends far more on how your application behaves than on how many people use it. An application with proper connection pooling and short, efficient queries can serve several thousand end users on a modest service tier. An application that opens a connection per user and holds it, or runs long queries that occupy a worker for seconds at a time, can exhaust the available workers with a few dozen people signed in.

When a database starts refusing connections, the error usually points at a resource limit, and the instinct is to scale up. Sometimes that is right. Often the real cause is a missing index, an unclosed connection, or a query pattern that holds workers far longer than it needs to — and scaling up simply pays more to hide it.

Exact ceilings differ by service tier and purchasing model and Microsoft revises them over time, so check the current resource limits documentation for the tier you are sizing. The shape of the answer, though, does not change: size for concurrency and query efficiency, not for user count.

Managed Instance, Azure SQL Database, or SQL Server on a VM?

Three options, and the choice is usually decided by compatibility requirements rather than price.

Option	Best suited to	Main trade-off
Azure SQL Database	New applications, or single databases with no cross-database dependencies	Smallest surface area; no SQL Agent, no cross-database queries
Azure SQL Managed Instance	Existing SQL Server estates moving to PaaS with minimal rewriting	Requires virtual network planning; management operations can be slow
SQL Server on an Azure VM	Workloads needing OS access, or features unavailable in PaaS	You are still patching, backing up, and managing a server

SQL Server on a VM is worth keeping on the table. It is infrastructure-as-a-service, so it hands the maintenance burden straight back to you — but if something genuinely requires the operating system, it is the honest answer rather than a compromise.

The limits that actually bite

Published limits are easy to look up. These are the ones that tend to cause trouble on real projects:

• Network planning is not optional. A Managed Instance is deployed into a delegated subnet in your virtual network. That subnet cannot host other resources, and the address space needs to be sized correctly at creation. Getting it wrong is painful to undo later, so this deserves attention before anything is provisioned.
• Management operations are slow. Creating an instance, or scaling one, is measured in hours rather than minutes. This is fine when you plan for it and genuinely disruptive when you assumed you could resize on a Friday afternoon.
• Storage is capped per instance and per tier. Estates that have grown organically for years are the ones most likely to run into this, and it is worth measuring actual sizes early rather than estimating.
• Backups are automatic, retention is a decision. Point-in-time restore covers a configurable recent window; longer retention has to be configured deliberately. Assuming ten years of history exists because "Azure backs it up" is a bad discovery to make during an audit.
• A handful of features are unavailable. FILESTREAM and FileTable are the ones most likely to appear in an older estate. Finding them during assessment is routine; finding them mid-migration is not.

How to approach the decision

The order that avoids the most rework:

1. Assess before choosing. Inventory what the databases actually depend on — agent jobs, linked servers, cross-database queries, file system access, unusual features. The findings usually pick the destination for you.
2. Size for concurrency and query behaviour, not for headcount or current server specification. Existing hardware often reflects a purchasing decision from years ago rather than real demand.
3. Fix the worst performance problems before migrating, not after. In Azure, inefficiency is a recurring charge. Work that never justified itself on a paid-for server frequently pays for itself within months on a metered one.
4. Plan the network first. It is the hardest thing to change later.

Done in that order, a Managed Instance migration is generally an unremarkable project. Done in reverse — provision first, discover dependencies later — it becomes the kind of engagement people tell stories about.

Getting help with it

Lemington Consulting has worked with Microsoft SQL Server since well before any of it ran in a cloud, and we handle assessments, migrations, and ongoing management of Azure SQL Managed Instance, Azure SQL Database, and SQL Server cloud hosting. We also provide SQL Server development and administration for organizations that want the database looked after properly, wherever it happens to run.

If you are weighing a move to Azure and want an assessment of what your databases actually depend on before committing to a destination, get in touch. You may also find our SQL Server FAQs useful.