Migrating 90 tenant databases off SQL Server VMs

Size rules out General Purpose and Business Critical. Both cap at 4 TB. With 2.6 TB and 120 GB/month growth, you exhaust the remaining headroom in roughly 11 months, and moving to a larger tier later means a migration with downtime. Hyperscale goes to 100 TB and grows storage without re-provisioning, which is the deciding factor.

The reporting contention rules out simply scaling the primary up. The analysts' aggregations compete for the same CPU and memory as OLTP; more vCores delays the problem. On Hyperscale, create a named replica (read-only, separately sized compute) and repoint the analyst connections at it with ApplicationIntent=ReadOnly. A named replica is billed for its own compute, so size it one or two steps below the primary because the aggregations are short batch work.

Keep the tenant in its own database, not an elastic pool. Competitor isolation and a 2.6 TB working set both argue for dedicated resources.

The one-hour RPO is met by Hyperscale's snapshot backups; if you need a guaranteed, measurable RPO rather than a backup SLA, add a failover group instead of relying on geo-restore.

Serverless General Purpose, one database per trial tenant. Compute bills per second and auto-pause stops compute when the database is idle, which matches usage of ~2 hours per week.

Costs and constraints to plan for:

• The minimum auto-pause delay is 1 hour. A tenant that connects once a week still pays for an hour of compute after each session, so budget worst case 40 x 1 hour per week rather than near zero.
• Storage is billed while paused. Only compute stops. Set the max vCore low (2) and the min vCore at the floor so a resumed database does not spike the bill.
• The first connection to a paused database fails while it resumes (typically 30-60 seconds). Trial apps must retry with a login timeout of ~60 seconds, or users will report the database as broken.
• The two competitor tenants cannot share a database, so they stay in their own serverless databases even though pooling them would be cheaper.

If a trial tenant later becomes production, move it out of serverless rather than raising auto-pause to its 7-day maximum.

Choose Managed Instance for any tenant whose application depends on things Azure SQL Database does not provide: cross-database three-part-name queries in application code, SQL Server Agent jobs, CLR assemblies, Service Broker, linked servers, or server-level logins. Elastic Query can approximate some cross-database reads, but it adds latency and is a code change, which defeats the point of a lift-and-shift.

What the team commits to:

• A delegated subnet they own, with NSG rules for ports 1433 and 3342, a route table (a default route to the internet breaks the deployment), and a maintenance window they must pick and manage.
• No serverless cost model - MI compute is provisioned; the trial tenants would keep running a provisioned instance unless they stay on Azure SQL Database.
• A 16 TB storage ceiling, so the fastest-growing tenant could outgrow MI and still need Hyperscale eventually.

Practical split: Managed Instance for the tenants with server-coupled dependencies, Hyperscale for the 2.6 TB tenant, serverless for trials. Assess with the Azure SQL migration extension before cutover, and seed the large database with log replay or transactional replication so the final cutover is minutes rather than a full copy.