The most expensive cloud migrations are the ones that move existing performance problems to a service that charges by the hour. A 5–10 day pre-migration health check routinely saves 3–6x its cost in avoided overprovisioning, refactor cycles, and downtime. Here's what to check before you cut over.
Cloud migration projects fail in predictable ways. The most common: a team measures their current SQL Server instance's resource consumption, picks an Azure SQL or AWS RDS tier that matches, migrates, and immediately discovers the new tier can't keep up. They scale up. It still can't keep up. They scale up again. Six months later, the cloud bill is 4x what was projected and nobody is sure why.
The cause is almost always the same: nobody profiled what the database actually needed versus what it was currently using. Those are very different numbers.
What to verify before you migrate
1. Actual workload size, not provisioned size
On-prem SQL Server is typically overprovisioned. If you size your cloud instance to match the on-prem hardware, you're paying for overprovisioning forever. A health check measures real working set, real CPU pressure, real I/O latency, and real concurrency — then maps those to a cloud SKU that fits.
2. Query patterns that won't move cleanly
Some things on-prem behave differently in the cloud:
- Cross-database queries (banned in Azure SQL Database, work in Managed Instance)
- SQL Agent jobs (handled differently per service)
- Linked servers (limited in Azure SQL DB, fine in MI and RDS)
- CLR assemblies (restricted in Azure SQL DB)
- Filestream / FileTable (not in Azure SQL DB)
- Replication topologies (subscriber-side limits vary)
A pre-migration audit surfaces every dependency before it bites you in cutover week.
3. The "lift & shift trap"
Lifting a 4 TB database with 700 GB of dead history, fragmented indexes, and unused indexes inflating storage is paying the cloud vendor to host your debt. A health check identifies what's safe to archive, drop, or compress before you start paying per-GB.
4. Index strategy under cloud I/O patterns
Cloud storage tiers have different latency profiles than local SSD. An index plan that's fine on-prem can suddenly become the bottleneck on cloud storage. Reviewing index choices with the target platform in mind is part of a proper pre-migration check.
Azure SQL Database, Azure SQL Managed Instance, and AWS RDS for SQL Server each have different feature surfaces and pricing curves. A health check that doesn't take the target platform into account isn't a migration prep — it's an on-prem audit with a cloud label.
5. Compatibility level and IQP features
The new instance will run at the latest compatibility level by default. Intelligent Query Processing features (batch mode on rowstore, scalar UDF inlining, deferred compilation, memory grant feedback) change query behavior in subtle ways. A pre-migration test against modern compat level catches regressions before they're customer-facing.
6. Backup & recovery strategy alignment
Cloud platforms give you backups, but the RPO/RTO model is different. PITR windows are configurable. Long-term retention costs extra. Geo-restore vs. failover groups have different cost and recovery profiles. A health check models your current RPO/RTO requirements against the cloud service's options and prices the right tier.
7. HA/DR translation
Always On Availability Groups don't simply move to the cloud. In Azure SQL DB, HA is built in but your read-routing logic changes. In Managed Instance, AGs exist but with a different quorum model. In RDS, Multi-AZ is the equivalent but doesn't behave identically. The pre-migration check produces a side-by-side: today's HA topology vs. the target's equivalent.
The economics
A typical pre-migration health check runs $4K–$12K depending on scope. The avoided cost is usually one or more of:
- One scale-tier reduction in the cloud SKU (often $1K–$5K/month, recurring)
- Avoided storage cost from archiving and compression (10–40% storage reduction is typical)
- Avoided refactor cycles for queries that wouldn't work cleanly
- Avoided downtime from cutover surprises
I have not yet seen a pre-migration health check that didn't pay for itself in the first three months post-migration.
Planning a SQL Server migration to Azure SQL, Azure Managed Instance, or AWS RDS? Book a free discovery call below — we'll talk through your timeline, your target platform, and whether a pre-migration check makes sense for your scope.