Zero-Downtime Migration: How to Move SQL Server to an Azure SQL VM Using DMS Online Mode

If you have ever tried to find a comprehensive, step-by-step guide on migrating an on-premises SQL Server to an Azure SQL Virtual Machine (VM) using Azure Database Migration Service (DMS) Online Mode, you’ve probably noticed a glaring gap online. Most documentation covers offline migrations or targets Azure SQL Database (PaaS) instead of SQL Server on Azure VMs (IaaS).

Recently, I set up a lab environment to test this exact scenario. During the process, I uncovered a few critical nuances — especially regarding how DMS handles differential backups during a live cutover.

Get Wkkum’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Whether you are preparing for an upcoming production migration or setting up your own proof-of-concept, here is the complete blueprint for executing a successful, zero-downtime online database migration.

Why Online Mode with DMS?

The primary advantage of DMS Online Mode is minimal downtime.

• The Continuous Sync: Your source database remains fully operational and online. DMS continuously restores transaction log and differential backups from an intermediate Azure Blob Storage account directly into your target Azure SQL VM.
• The Cutover Control: The final application downtime is restricted entirely to the moment you choose to finalize the migration (cutover), which typically takes just a few minutes.

The Pre-Requisites

Before clicking “Start” in DMS, ensure you have:

1. An on-premises SQL Server (Source) with a database in Full Recovery Model.
2. An Azure SQL Virtual Machine (Target).
3. An Azure Storage Account with a dedicated blob container (this acts as the staging area for your backup files).
4. An Azure Database Migration Service instance configured in the Online tier.

Step 1: Prepare the Staging Area (Azure Storage Account)

DMS requires a shared workspace where the source machine can drop backup files and the target Azure VM can pull them.

1. Navigate to the Azure Portal and create a standard Storage Account.
2. Inside the Storage Account, create a new container specifically designated for your migration backups (e.g., migrate).

Creating storage account and its container

Step 2: Configure Backups on the Source Machine

Next, you need to tell your on-premises SQL Server to back up directly to your newly created Azure Blob URL.

1. On your source SQL Server instance, open SQL Server Management Studio (SSMS).

2. Configure a backup job targeting the URL of your Azure Blob storage container.

Backup the first version of data from source SQL

3. When prompted, select “Add” and choose “New Container”.

Configure backup destination (1)

4. Authenticate using your Azure Storage Account credentials, map it to your container, and execute an initial Full Backup to the cloud storage.

Configure backup destination (2)

Configure backup destination (3)

Step 3: Set Up the DMS Online Migration Project

With your initial backup sitting securely in Blob storage, it’s time to build the bridge.

1. Go to your Azure DMS instance in the portal and create a New Migration Project.

Prepare migration for SQL server

2. Set the Source server type to SQL Server and the Target server type to Azure SQL Virtual Machine. Crucially, choose Online data migration as the activity type.

Choose for online mode to minimize cutover time

3. Fill in the source and target connection details when prompted.

Choose the source database to migrate

Choose the target database

4. In the Migration Settings, point DMS to your network share or the specific Azure Blob directory containing your backups. Input your target database name and initiate the migration pipeline.

Configure the desired database name and the backup file path

5. At this point, DMS will look at the blob container, find your initial full backup, and begin restoring it to the target SQL VM in a Ready for cutoverstate.

The server is ready for cutover

The Real-World Scenario: Simulating a Cutover Next Week

Imagine this scenario: you set up this sync today, but the official application cutover isn’t scheduled until next week. Over the course of the week, data keeps changing on your source database.

Initial database

One week later

To ensure the new database matches the old database perfectly right before you flip the switch, you need to perform another Differential Backup to storage account (repeat step 2).

New backup before cutover

Latest backup on storage account

The Cutover Catch: What Actually Happens in the Portal

When the cutover window arrives, you will navigate to the source machine and run a final Differential Backup to the same Blob container.

Pro-Tip for Saving Time: Using a differential backup instead of a full backup right before cutover saves massive amounts of network bandwidth and time because it only captures the data changed since your initial full backup. Leave the backup file name as default; DMS is smart enough to detect new files in that directory.

However, when you click “Start Cutover” in the Azure Portal, you might notice something alarming: The UI may still display your old backup file name in the preview pane.

Do Not Panic!

If you see the old file name listed in the cutover window, don’t cancel the operation. Azure DMS processes queue items sequentially. As long as your latest differential backup file resides in the exact same blob container path configured earlier, DMS will pick it up.

The file is showing using old backup file (labdb_backup_2026_05_29_040704.bak)

Go ahead and confirm the action by running Complete Cutover. As the process runs, you will watch the backend log refresh, the interface update, and the system pull the newest differential backup file.

Complete cutover

Once processing finishes, the status will flip to Completed, confirming that your databases are perfectly synchronized and the target database on your Azure SQL VM is brought fully online.

New backup file auto detected and implemented (labdb_backup_2026_05_09_041416.bak)

Target SQL virtual machine with the latest data appear!

Key Takeaways

1. Keep Paths Consistent: DMS relies heavily on path monitoring. Never change your backup directories midway through an online migration lifecycle.
2. Trust the Backend over the UI: The Azure Portal UI can lag during live migrations. If you know your differential files are in the blob container, let DMS execute the cutover pipeline; it evaluates the file tree accurately upon execution.
3. Network Latency Matters: Because the source database backs up to Blob storage over the internet (or VPN) and the Azure VM downloads it, ensure your network bandwidth can handle the delta size of your transaction logs/differentials during your maintenance window.

Have you tried migrating to an Azure SQL VM using DMS? Let me know in the comments if you ran into similar UI quirks or if you found alternative ways to smooth out the process!