SQL Server to Azure SQL Migration Checklist
Most SQL Server–to–Azure migrations don't fail because of Azure. They fail because the assessment step got skipped, the cutover plan was one line ("run the backup, restore it, switch the connection string"), and nobody tested rollback until they needed it at 2am. This is the checklist we actually run on paid engagements — not a marketing list, a working one.
1. Decide what "Azure SQL" actually means for you
"Azure SQL" isn't one product. Picking the wrong target is the single most common planning mistake, because each option has a different compatibility bar and a different ongoing operational model.
- Azure SQL Database — best fit if your workload is a single database, doesn't rely on cross-database queries, linked servers, SQL Agent jobs, or CLR, and you want Microsoft to own patching, backups, and HA entirely.
- Azure SQL Managed Instance — best fit if you need near-full SQL Server surface area (cross-db queries, SQL Agent, Service Broker, linked servers) with less migration rework, at a higher cost and with a VNet requirement.
- SQL Server on Azure VM (IaaS) — best fit if you need full OS-level access, specific SQL Server versions/features Azure SQL doesn't support, or third-party tools that expect a real Windows/Linux box underneath.
2. Run a real compatibility assessment before you commit
Don't estimate this from memory. Run Microsoft's Data Migration Assistant (DMA) against production (or a recent restore) and get an actual list of breaking changes, deprecated features, and unsupported objects.
- Run DMA's compatibility assessment against every database in scope, not a sample.
- Inventory SQL Agent jobs, linked servers, CLR assemblies, and cross-database queries — these are the top reasons teams get pushed from Azure SQL DB to Managed Instance mid-project.
- Check collation. Mismatched collation between source and target is a quiet, late-stage blocker that's expensive to discover during cutover.
- Identify any use of deprecated features (e.g., older replication topologies, certain system stored procedures) flagged by DMA.
- Confirm authentication model — SQL logins vs. Windows Auth vs. Azure AD/Entra ID — since this changes app connection strings.
3. Size the target correctly — don't guess DTUs or vCores
Undersizing shows up as a performance incident three weeks after go-live, when everyone's already declared the migration a success. Pull actual resource utilization (CPU, IOPS, memory, log throughput) from the source server over at least a full business cycle — not a quiet week — before choosing a service tier and compute size.
4. Plan the cutover like an engineer, not like a checklist item
"Backup, restore, repoint the app" works for a 2GB database with a two-hour maintenance window on a Sunday. It does not work for anything mission-critical. Real cutover planning means choosing a migration method that matches your acceptable downtime:
- Offline (backup/restore or export/import) — simplest, but downtime equals the full data transfer + validation time. Fine for small, low-criticality databases.
- Azure Database Migration Service (online mode) — continuous data sync with a short cutover window at the end. The right default for anything with a real uptime requirement.
- Transactional replication — gives you a live, queryable replica during migration and the shortest possible cutover window, at the cost of more setup complexity.
Whichever method you choose, write down the actual cutover sequence, the rollback trigger conditions ("if X happens within 30 minutes of cutover, we roll back"), and who has the authority to call it. Decide this before the migration window, not during it.
5. Security and networking — don't bolt this on afterward
- Decide VNet integration and private endpoint requirements before provisioning — retrofitting network isolation after go-live means downtime you didn't plan for.
- Migrate or redesign firewall rules; Azure SQL's server-level and database-level firewall model is different from on-prem network ACLs.
- Map SQL logins to Azure AD/Entra ID where practical — this is also your opportunity to actually clean up access that's accumulated for years.
- Confirm encryption requirements (TDE is on by default in Azure SQL, but confirm key management — service-managed vs. customer-managed keys — matches your compliance posture).
6. Test rollback before you need it
If your plan doesn't include a tested, timed rollback path, you don't have a migration plan — you have a bet. Test it in a lower environment first: how long does it actually take to revert the connection string and confirm the on-prem source is still consistent and current enough to serve traffic?
7. Post-migration: the first two weeks matter more than the cutover
- Set up Azure SQL-native monitoring (Query Performance Insight, Azure Monitor alerts) before go-live, not after something breaks.
- Re-baseline query performance — plans can and do shift after migration, especially with different compatibility levels or hardware generations.
- Right-size compute after two weeks of real traffic, not day one guesses. Azure makes scaling down (and saving money) easy — most teams never revisit their initial sizing.
- Confirm backup retention and point-in-time restore windows meet your actual RPO/RTO requirements — the Azure defaults are not automatically your compliance requirements.
The teams that get burned aren't the ones who chose the "wrong" Azure SQL product. They're the ones who skipped the compatibility assessment, sized from a hunch, and treated cutover as a formality instead of the highest-risk hour of the whole project.
Planning a migration and want a second set of eyes on the plan?
Free 20-minute fit call — bring your environment, get a straight read on the approach.
Book a free fit call