Migrating SQL Server to Azure: A Step-by-Step Guide

Step 1: Choose the Target Platform

"Azure" means three different targets for SQL Server, and the choice drives everything that follows:

Rule of thumb: the closer to "my application expects a full SQL Server instance", the more it points to a VM or Managed Instance. The assessment in step 3 confirms or corrects this choice.

Step 2: Inventory and Baseline

Before any tool runs, know what you are moving. Per instance: versions and editions, all databases with size and growth, collation, compatibility level, encryption (TDE), features in use, and every dependency outside the database: logins, SQL Agent jobs, linked servers, credentials, Database Mail, SSIS packages, server triggers, and the applications and services that connect.

# Quick inventory with dbatools
Get-DbaInstanceProperty -SqlInstance SQL01 |
    Where-Object Name -in 'VersionString','Edition','Collation','IsHadrEnabled'

Get-DbaDatabase -SqlInstance SQL01 -ExcludeSystem |
    Select-Object Name, SizeMB, Compatibility, Collation, RecoveryModel, EncryptionEnabled

Get-DbaAgentJob -SqlInstance SQL01 | Select-Object Name, Enabled, OwnerLoginName
Get-DbaLinkedServer -SqlInstance SQL01 | Select-Object Name, DataSource

Also capture a performance baseline under real load: CPU, memory, IOPS, throughput, latency, top queries, and the peak times. Without it, nobody can later answer "is it slower in Azure?", and sizing becomes guesswork.

Step 3: Assess Compatibility and Size

The current Microsoft tool is the Migrate SQL Server feature in SSMS 22 or later:

1. In the Visual Studio Installer, modify your SSMS installation and add the Hybrid and Migration workload.
2. Connect to the source instance, right-click it in Object Explorer and select Migrate SQL Server.
3. Select Run Assessment and open the generated HTML report.

The report compares Azure SQL Database, Managed Instance and SQL Server on Azure VM, and shows readiness per target, compatibility findings with affected objects, a recommended minimum configuration (tier, vCores, storage) and estimated monthly cost. Treat "Ready with conditions" as a to-do list, not as approval. If the instance is enabled by Azure Arc, SSMS uses the precomputed Arc assessment instead (View Readiness Assessment), and for whole datacenters, Azure Migrate runs the same kind of assessment at scale.

For the assessment alone, the login does not need sysadmin; Microsoft documents a minimum permission set (VIEW SERVER STATE, VIEW ANY DEFINITION, read access to parts of msdb and others). Running the migration from SSMS requires sysadmin.

Step 4: Choose the Migration Method

Step 5: Prepare the Target and the Network

• Connectivity: a site-to-site VPN or ExpressRoute between on-premises and the Azure virtual network. Measure the real throughput: it decides how long seeding and the final copy take. More on running replication over ExpressRoute: Distributed AG On-Prem to Azure over ExpressRoute.
• Managed Instance: needs a dedicated, delegated subnet. Plan it with the network team early; a misconfigured subnet or NSG is the most common reason instance creation or connectivity fails. Creating a new instance can also take a long time, so do it days ahead, not on migration day.
• SQL Server on Azure VM: follow the storage best practices: separate disks for data, log and tempdb, read-only host caching for data, none for log, 64 KB allocation unit size (see SQL Server and Block Size). If you install SQL Server yourself on a v6 VM series, check the sector size first: An Azure VM with 8 KB Sector Size Can Break SQL Server.
• Collation and time zone of a Managed Instance are set at creation and cannot be changed later. Match the source.
• Storage account for backups in the same region as the target, plus a SAS token (or managed identity) for access.

Step 6: Move Everything Outside the Database

This is the step that decides whether the application works on Monday. Backup/restore and every replication-based method move user databases only. System databases cannot be restored to a Managed Instance, and on a VM you should not try either. Script and recreate:

• Logins with their original SIDs and password hashes, so database users stay mapped. Otherwise you get orphaned users.
• SQL Agent jobs, operators, alerts, proxies and credentials (not applicable to Azure SQL Database).
• Linked servers, Database Mail profiles, server-level triggers, custom error messages, server roles and permissions.
• TDE certificates: a TDE-protected database cannot be restored until its certificate exists on the target. For Managed Instance, Microsoft documents a specific certificate migration procedure.

# Script instance-level objects for review and replay
Export-DbaLogin    -SqlInstance SQL01 -Path C:\Migration\SQL01
Export-DbaInstance -SqlInstance SQL01 -Path C:\Migration\SQL01 -Exclude Databases

On a Managed Instance, logins and jobs are not synchronized automatically after the migration either, which matters if you later add a failover group: Are Logins and SQL Agent Jobs Automatically Synchronized?

Step 7: Do a Test Migration

Run the complete process once with a copy of production, end to end, including the instance-level objects. Then:

• Point a test instance of the application at the target and run its functional tests.
• Run validation queries on source and target: row counts per table, checksums or sums over key columns, a few business totals the application owners know by heart.
• Run a load test and compare against the baseline from step 2.
• Measure every duration: backup, transfer, restore, seeding, cutover. These numbers become the timetable of the real cutover.

Step 8: Migrate the Data

Option A: backup to URL and restore (VM or Managed Instance)

-- On the source (SQL Server 2016+): credential for the container
CREATE CREDENTIAL [https://migstore.blob.core.windows.net/sales]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
     SECRET   = '<SAS token without the leading ?>';

BACKUP DATABASE Sales
TO URL = 'https://migstore.blob.core.windows.net/sales/Sales_full.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;

-- On the target: same credential, then restore
RESTORE DATABASE Sales
FROM URL = 'https://migstore.blob.core.windows.net/sales/Sales_full.bak';

On a VM, restore the full backup WITH NORECOVERY, keep applying log backups, and at cutover restore the tail-log backup WITH RECOVERY: the downtime then shrinks to the last log backup. On a Managed Instance, a manual NORECOVERY restore is not possible; for full plus differential plus log chains use LRS.

Option B: Log Replay Service (Managed Instance)

Put all backups of one database into one flat folder per database in the container (no subfolders), take them WITH CHECKSUM, and start LRS:

# Continuous mode: LRS keeps restoring new backups until you complete it
Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName 'rg-sql' `
    -InstanceName 'mi-prod-01' -Name 'Sales' `
    -Collation 'SQL_Latin1_General_CP1_CI_AS' `
    -StorageContainerUri 'https://migstore.blob.core.windows.net/migration/Sales' `
    -StorageContainerSasToken '<SAS token with read and list>'

# Progress
Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName 'rg-sql' -InstanceName 'mi-prod-01' -Name 'Sales'

# Cutover, after the tail-log backup is in the folder and restored
Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName 'rg-sql' `
    -InstanceName 'mi-prod-01' -Name 'Sales' -LastBackupName 'Sales_taillog.trn'

With -AutoCompleteRestore -LastBackupName ... on the start command, LRS completes on its own after that file is restored. Plan within the 30-day limit per job. For SQL Server 2019 and later, Microsoft recommends having accelerated database recovery enabled on the source with the persistent version store on PRIMARY.

Option C: Managed Instance link

Configure the link with the SSMS wizard (or scripts), let it seed and synchronize, validate on the readable target, and at cutover fail over the link. Of all the options, it gives you the longest possible migration window with minimal downtime, because the target can be used read-only for validation while replication runs.

Option D: Azure Database Migration Service

In the Azure portal, create or open a DMS instance, select Start migration, pick source and target type, the backup location and the migration mode, and monitor the migration in the DMS dashboard. Use it when you migrate many databases and want one place to orchestrate and monitor them.

Step 9: Cut Over

Write the cutover as a runbook with times, owners and a go/no-go decision point, and rehearse it in step 7. The core sequence:

1. Stop the workload. Applications, jobs, interfaces, ETL. Disable SQL Agent jobs on the source so nothing writes after the final backup.
2. Take the tail-log backup (or let the link / LRS / DMS apply the last changes) and confirm the target is fully caught up.
3. Bring the target online: restore WITH RECOVERY, complete LRS, fail over the link, or select Complete cutover in DMS.
4. Validate with the queries from step 7: row counts, checksums, business totals.
5. Switch the connections: connection strings, DSNs, configuration files, or a DNS alias if you prepared one (see DNS Aliases for SQL Server for the caching caveats).
6. Enable jobs on the target, start the applications, smoke test.
7. Set the source to read-only (or offline) so no one accidentally keeps writing to it.

Step 10: After the Migration

• Update statistics on all migrated databases and watch the plans of the top queries.
• Compatibility level: keep the old level first, enable Query Store, establish a baseline, and only then raise the level, so regressions are visible and reversible.
• Backups: on a VM, set up backups yourself (or with the SQL IaaS Agent extension). On Managed Instance and Azure SQL Database, automated backups run by default: check retention, and remove migrated backup jobs that no longer make sense.
• Monitoring and alerting for the new platform, compared against the baseline from step 2.
• Cost: review the actual bill after the first weeks; reserved capacity and Azure Hybrid Benefit for existing licenses often change the numbers considerably.
• Decommission the source after an agreed period, with a final backup kept according to your retention rules.

Checklist

• Target platform chosen and confirmed by the assessment
• Inventory and performance baseline captured
• Blockers from "Ready with conditions" resolved
• Migration method chosen and its duration measured in a test run
• Network, subnet (Managed Instance), storage and sector size checked
• Logins (with SIDs), jobs, linked servers, credentials, TDE certificates scripted and tested
• Validation queries prepared for source and target
• Cutover runbook with times, owners, go/no-go and rollback point
• Post-migration: statistics, Query Store, compatibility level, backups, monitoring

The Bottom Line

A successful Azure migration is decided before the first byte moves: choose the target deliberately, assess with the current tools (SSMS 22 or Azure Arc, not the retired DMA), move logins, jobs and everything else that lives outside the database, and rehearse the full run once with real durations. Then the migration itself is a backup and restore, a link failover or a completed LRS job, and the cutover is a runbook you have already executed.

Sources

• Microsoft Learn: Migrate SQL Server to Azure SQL (SSMS)
• Microsoft Learn: SQL Server to Azure SQL Managed Instance migration guide
• Microsoft Learn: Migrate databases by using Log Replay Service
• Microsoft Tech Community: Retirement of Data Migration Assistant
• Microsoft Tech Community: Alternatives after the deprecation of the Azure SQL Migration extension