Serverless compute gets pitched as the modern default and provisioned as the thing you are migrating away from. That framing has cost a lot of teams a lot of money, because it treats a pricing decision as an architectural one.
The actual question is narrow: what does your usage look like across a week? Not how big the database is. Not how many users you have. The shape of the curve.
What you are really choosing between
Provisioned compute bills you for capacity whether or not you use it. It is a flat line on a graph. Serverless bills you for what you consume, per second, and can scale down to nothing when idle. It is a jagged line that touches zero.
If your jagged line spends most of the week near zero, serverless wins easily. If it sits near its ceiling most of the time, serverless is simply a more expensive way to buy the same capacity, because you pay a premium per unit for the privilege of elasticity you never use.
There is a crossover point, and for Azure SQL it tends to land somewhere around a quarter to a third of full time utilisation. Below that, serverless. Above it, provisioned. The exact number moves with tier and region, which is why you should calculate it for your own workload rather than trusting a figure in an article, including this one.
Measure before you decide
You do not have to guess. Azure has been recording your utilisation the whole time.
For an existing Azure SQL database, query
sys.dm_db_resource_stats for the last hour at fine grain, or
sys.resource_stats in the master database for the last fourteen
days. Pull average CPU and IO percentage in fifteen minute buckets across two
full weeks, so you capture both a normal week and whatever month end does to you.
For an on premises server you are planning to move, the same picture comes from Performance Monitor counters or a few days of Query Store data. It is less convenient and just as decisive.
Then plot it. Not a summary statistic, the actual curve. Averages hide exactly the thing you are trying to see: a database that averages twenty percent CPU might be idle for twenty two hours and pinned for two, or it might hum along at twenty percent constantly. Those two profiles want opposite answers and produce the same average.
The costs that are not on the pricing page
Two behaviours surprise people after they switch.
The first is auto pause. Serverless can pause a database that has been idle, which is where much of the saving comes from. Waking it takes a few seconds, and the first query after a pause pays that cost. For a nightly batch nobody notices. For a customer facing screen at 8:55am, somebody notices, and the fix is either to disable auto pause, which removes most of the benefit, or to keep something warm, which is a workaround with its own cost.
The second is that memory scales with the compute you are currently using. A database that has scaled down has a smaller buffer pool, so the first heavy query after a quiet period reads from storage rather than memory and runs slower than the same query at midday. This is not a fault, it is the deal, but it turns into a support ticket if nobody was told.
You are allowed to split the estate
The most common mistake is treating this as one decision for one server, because that is how the old hardware forced you to think. In Azure each database can make its own choice.
A typical outcome after profiling: the transactional database that serves the application all day stays provisioned, the reporting replica that gets hammered for two hours each morning goes serverless with a generous ceiling, and the three small departmental databases that are touched twice a week go serverless with aggressive auto pause and cost almost nothing.
That mixed answer is unsatisfying to write on a slide and it is usually the right one. It also has the advantage of being reversible: changing a database between serverless and provisioned is a tier change, not a migration, so a decision made on two weeks of data can be revised after two months of reality.
The short version
Pull two weeks of utilisation. Plot the curve rather than the average. Below roughly a third utilisation, serverless. Above it, provisioned. Check whether anything user facing would be hurt by a cold start. Decide per database, not per server. Revisit after a quarter.
It is a smaller decision than the vendor material implies, and the data to make it properly is already sitting in your own system.