Migrating SQL Server to Azure SQL Database: A DBA's Practical Checklist

Cloud migration pressure is relentless in 2026. Azure SQL Database promises automatic backups, built-in high availability, and no more patching weekends. Most of that is true — but the gap between "technically migrated" and "running cleanly in production" is where migrations go sideways.

I've moved dozens of SQL Server instances to Azure SQL across industries from healthcare to logistics. The checklist below reflects what actually breaks, what gets missed in vendor documentation, and what separates a clean cutover from a panicked rollback.

Phase 1: Pre-Migration Assessment (Don't Skip This)

The single most common mistake: treating Azure SQL as a drop-in replacement for SQL Server. It isn't. Before touching anything, run these checks:

Compatibility Assessment

Run the Database Experimentation Assistant (DEA) and Data Migration Assistant (DMA) against your source database. These tools surface compatibility blockers that will stop you cold if discovered mid-migration:

• Linked servers — Azure SQL doesn't support them. If your app depends on cross-server queries, you need a redesign strategy before you migrate, not after.
• SQL Server Agent jobs — Azure SQL has no SQL Agent. Jobs must move to Azure Elastic Jobs, Azure Automation, or Logic Apps. Map every job, its schedule, and its dependencies before day one.
• CLR assemblies — Only SAFE CLR is supported in Azure SQL. EXTERNAL_ACCESS and UNSAFE assemblies are blocked. This surprises more teams than it should.
• Cross-database queries — Azure SQL databases are isolated. If you have USE OtherDB anywhere in your code, that breaks.
• Bulk operations and BCP — Work, but require specific network and firewall configuration.

Size and Tier Sizing

Azure SQL pricing is driven by vCores and storage. The most common mistake is under-sizing based on current CPU averages. Averages lie. Pull your peak P95 CPU and memory utilization across a full business cycle — including month-end batch runs, reporting jobs, and any seasonal spikes. Size for your peak, not your average. Recovering from a tier that's too small costs you a maintenance window.

General Purpose (standard remote storage) works for most OLTP workloads. Business Critical (local SSD, built-in HA replicas, read scale-out) is worth the premium if you have latency-sensitive workloads or need in-memory OLTP. Don't guess — test with a workload replay tool before committing.

Phase 2: Choose Your Migration Approach Carefully

There are three main paths, and the right one depends on your downtime tolerance:

Option A: Azure Database Migration Service (DMS) — Online Migration

Best for: production databases where downtime must be under 15 minutes. DMS uses log shipping to keep Azure SQL synchronized with your on-prem source in near-real-time. When you're ready to cut over, you initiate cutover, DMS drains the last few transactions, and you flip DNS.

Gotcha: DMS requires that your source database have Change Data Capture (CDC) enabled and that all tables have primary keys. Audit this before you start — adding PKs to large tables mid-migration is a painful surprise.

Option B: BACPAC Export/Import — Simple but Has Downtime

For smaller databases (under 100GB) and planned maintenance windows: export to BACPAC, import to Azure SQL. Simple, well-documented, reliable. But it's a cold migration — your database is offline for the duration of the export and import. On a 50GB database, expect 2-4 hours. On 500GB, expect much more. Know your numbers before you schedule the window.

Option C: Backup and Restore (Managed Instance Only)

If you're migrating to Azure SQL Managed Instance (full SQL Server engine compatibility), you can restore native .bak files from Azure Blob Storage. This is the cleanest path for complex databases with SQL Agent, CLR, and other features that don't exist in standard Azure SQL Database.

The Checklist: What Gets Missed

After the migration approach is chosen, these are the items teams most consistently overlook:

• Firewall rules — Azure SQL has its own firewall separate from your VNet. Your app servers, monitoring tools, and admin workstations all need explicit rules. Test connectivity from every system that touches the database before cutover, not after.
• Connection string updates — Azure SQL requires TLS 1.2 minimum. Older drivers and .NET Framework 3.5 apps will fail silently or throw cryptic errors. Audit your connection strings and driver versions before the window.
• Statistics and index maintenance — Statistics don't transfer with the migration. Azure SQL will build them over time, but query plans will be suboptimal for the first few days post-migration. Proactively update statistics on your critical tables immediately after cutover.
• Max degree of parallelism (MAXDOP) — Azure SQL sets MAXDOP = 8 by default on most tiers. If your on-prem instance had a different setting, query behavior may change. Check your current MAXDOP and adjust on Azure SQL post-migration.
• Monitoring and alerting — Azure Monitor, Query Performance Insights, and Intelligent Insights are powerful but require setup. Don't go live without alert rules on CPU, DTU/vCore consumption, and deadlocks configured in advance.
• Backup verification — Azure SQL handles automated backups, but verify your point-in-time restore window (default: 7 days, configurable to 35) is set appropriately before you decommission your on-prem backups.

Post-Migration Validation

A migration isn't complete when the data is in Azure. It's complete when your application is running cleanly. Run this validation sequence:

1. Execute your critical application workflows end-to-end in a staging environment on Azure SQL before production cutover.
2. Compare row counts on every table between source and destination.
3. Run your top 20 most-executed queries and compare execution plans. Any plan regression needs investigation before you go live.
4. Verify all scheduled jobs have been re-created and tested in their new form (Azure Elastic Jobs, Automation, etc.).
5. Confirm application connection pools are sizing correctly — Azure SQL has connection limits per service tier.
6. Smoke-test your monitoring dashboards. If a query goes sideways at 2 AM, you want to know in 2 minutes, not 2 hours.

One Last Thing Most Teams Get Wrong

They treat the migration as a one-time project and immediately decommission their DBA resources. Three weeks later, query performance has degraded, an index is missing, and no one knows why the month-end report is running 4x slower than on-prem.

Azure SQL is managed infrastructure — Microsoft handles the hardware and patches. But query optimization, index design, schema decisions, and workload management are still your responsibility. The database doesn't tune itself.

If your team doesn't have the bandwidth to stay on top of Azure SQL post-migration, a remote DBA engagement covers the gap without the overhead of a full-time hire. We've done SQL Server to Azure SQL migrations for companies from 50GB line-of-business databases to multi-terabyte enterprise workloads. The patterns above hold across all of them.

Questions about your specific migration? Start with our cloud database migration service page or reach out directly — we're happy to walk through your environment before you commit to an approach.