Article
Moving a self-hosted SQL Server database to Azure SQL isn't a lift-and-shift, even though it's often sold that way. Azure SQL Database is a managed platform-as-a-service, not just "SQL Server on someone else's hardware" - and that distinction is exactly where migration cost hides. A number quoted before anyone's looked at your schema is a guess.
Why this isn't a simple restore-and-go
Azure SQL Database doesn't support everything on-premises SQL Server does. SQL Server Agent jobs, cross-database queries, certain CLR integrations, and some linked-server patterns either don't exist in Azure SQL Database or work differently. If your database leans on any of these - and most databases that have been in production for years do, in ways nobody fully remembers - each one needs to be found, understood, and re-implemented before cutover. That discovery work is real effort, and it's invisible until someone actually audits the schema and the jobs running against it.
The cost drivers that actually move the number
How much the schema depends on unsupported features. This is the single biggest variable. A database that's stayed close to standard T-SQL migrates cheaply. One with years of accumulated SQL Agent jobs, CLR procedures, and cross-database joins needs each of those rebuilt for a platform that doesn't support them the same way - and that rebuild work, not the data transfer itself, is usually where the budget goes.
Sizing and tier selection. Azure SQL Database bills on DTUs or vCores, and getting the tier wrong in either direction is expensive - undersized and you're firefighting performance in production, oversized and you're paying for headroom you don't need. Getting this right needs real usage data from the existing system, not a guess based on server specs.
Downtime tolerance during cutover. A database that can go offline for a maintenance window is a cheaper migration than one that has to stay live throughout. When we optimized a reservation platform's SQL Server layer to eliminate deadlocks and cut read latency to 50ms under peak concurrent traffic, the fix had to hold while the booking system kept taking live traffic - that constraint, not the query tuning itself, is what shaped the engineering approach.
What sits in front of the database. If application code was written assuming specific SQL Server behavior - certain isolation-level assumptions, direct dependency on features Azure SQL Database doesn't support - the application layer needs updating alongside the database, not after it. On one logistics client's system we moved the application layer to ASP.NET Core on .NET 8 and the infrastructure to Azure App Service at the same time as auditing and rebuilding the SQL Server indexing strategy - treating the database migration in isolation from the application layer above it would have understated the real scope.
Why "just export and import" undersells the work
The technical mechanics of moving data from SQL Server to Azure SQL Database are well-documented and genuinely not the hard part. The hard part is everything the schema and the surrounding application code assume that Azure SQL Database won't just accept as-is. A credible estimate needs someone to actually look at your database - the jobs, the stored procedures, the cross-database dependencies - before naming a number.
If you want a real cost figure instead of a platform-average estimate, that starts with an assessment of your specific database and the application sitting on top of it.