Azure Database Migration Service Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Migration

1. Introduction

Azure Database Migration Service is Microsoft’s managed migration orchestration service for moving databases from on-premises, virtual machines, and other clouds into Azure data platforms. It helps you plan and execute database migrations with structured projects, guided workflows, and progress tracking.

In simple terms: you create a migration service in Azure, connect it to a source database and a target Azure database, then run a migration job (offline or online, depending on the scenario). You monitor progress and validate that the target is ready for cutover.

Technically, Azure Database Migration Service provides a managed “migration runtime” hosted in Azure that connects to source/target endpoints over the network, performs schema and/or data movement depending on the migration type, and reports status back to the Azure control plane (Azure Portal/ARM). It’s typically deployed into an Azure virtual network (VNet) so it can securely reach private source systems.

The main problem it solves is that real migrations are rarely just “export/import.” Teams need repeatable steps, secure connectivity, minimal downtime options, and reliable status reporting. Azure Database Migration Service provides a structured way to move databases into Azure while reducing risk and manual effort.

Important note on current positioning: Microsoft also provides newer guided experiences for some migrations (for example, Azure SQL migration experiences in Azure tools/portals). In some cases, those experiences may use Azure Database Migration Service under the hood or may be the preferred workflow for specific sources/targets. Always confirm the current recommended approach and support matrix in official documentation before you commit to a tooling path.

2. What is Azure Database Migration Service?

Official purpose (what it’s for):
Azure Database Migration Service is designed to enable database migrations to Azure by providing a managed service that coordinates and executes migration tasks. It supports a range of source engines and Azure targets, with capabilities that vary by migration scenario.

Core capabilities (high level): – Create migration projects and run migration activities/jobs – Support for offline migrations (cutover requires downtime) and online migrations (reduced downtime) for certain engines/targets – Guided selection of source/target types and migration modes – Progress monitoring, basic error reporting, and orchestration support for iterative migration work

Major components: – Azure Database Migration Service resource: The service instance you deploy in a subscription/resource group, usually into a VNet subnet. – Migration project: A logical container where you choose source/target types and organize migration activities. – Migration activities/tasks: The operations that move schema/data (depending on scenario) and track progress. – Networking dependencies: VNet/subnet placement, DNS, routing, NSGs, VPN/ExpressRoute, firewall rules—these often determine whether migrations succeed.

Service type:
A managed Azure service (PaaS-style control plane), typically deployed into your network boundary to reach private endpoints.

Scope (regional/subscription/resource group): – You create Azure Database Migration Service as an Azure resource in a specific region. – It lives in a subscription and resource group. – For most non-trivial scenarios, it is associated with an Azure VNet/subnet in that region (regional resource with regional networking).

How it fits into the Azure ecosystem: – Works alongside assessment and readiness tooling such as: – Azure Migrate (discovery/assessment at a broader level) – Database-specific assessment tools (for example, SQL assessment tools).
Exact tooling depends on engine and target—verify in official docs. – Pairs with Azure database targets such as: – Azure SQL Database – Azure SQL Managed Instance – Azure Database for PostgreSQL – Azure Database for MySQL – Other supported targets as listed in Microsoft’s support matrix (varies over time—verify)

3. Why use Azure Database Migration Service?

Business reasons

Reduce migration risk with a guided process and predictable stages.
Shorten project timelines compared to building custom migration pipelines.
Support modernization by moving from self-managed databases to managed Azure services.
Enable phased cutovers and rehearsal migrations (especially valuable for regulated environments).

Technical reasons

Supports structured migration workflows (offline/online depending on scenario).
Works in private networking contexts (VNet-integrated), which is common for production databases.
Provides a central Azure-native place to manage migration activities and status.

Operational reasons

Repeatable migrations across environments (dev/test/prod) with clearer orchestration than ad-hoc scripts.
Monitoring via portal-based status and error views; integrates with standard Azure governance patterns (tags, RBAC, resource groups).

Security/compliance reasons

Can be deployed into a private subnet and connected over VPN/ExpressRoute to keep traffic off the public internet.
Leverages Azure RBAC for access to the migration service resource.
Helps implement separation of duties (migration operators vs. target platform admins).

Scalability/performance reasons

Offloads migration execution into a managed service that can be sized/selected via service tier options (exact tiers and capabilities vary—verify in pricing/docs).
Supports parallelization patterns in some scenarios (for example, migrating multiple databases or tables), subject to service and target constraints.

When teams should choose it

Choose Azure Database Migration Service when: – You need a guided, Azure-supported migration path. – You require VNet-based connectivity to private sources. – You want online (reduced downtime) migration where supported. – You want a migration approach that fits Azure governance and enterprise controls.

When teams should not choose it

Avoid or reconsider Azure Database Migration Service when: – Your migration is a simple one-time export/import and you already have safe, tested scripts. – Your source/target pair is not supported or your required migration mode (online/offline) isn’t available for that pair. – Your biggest issues are application refactoring, not data movement (you may need app modernization work first). – You can use a more specialized or recommended workflow (for example, a database-specific migration toolchain) that better matches your target architecture—verify current recommendations.

4. Where is Azure Database Migration Service used?

Industries

Finance and insurance (controlled change windows, audit needs)
Healthcare (regulated data handling, strict network boundaries)
Retail/e-commerce (minimize downtime, scale managed services)
Manufacturing/IoT (legacy databases in plants moving to cloud)
Government (private connectivity, compliance-driven migrations)
SaaS providers (consolidating customer databases onto managed platforms)

Team types

Platform engineering teams building standardized migration runbooks
Database administrators (DBAs) leading migration execution
Cloud center of excellence (CCoE) defining migration patterns
DevOps/SRE teams responsible for reliability and cutover operations
Security engineers reviewing network and identity controls

Workloads

Line-of-business apps backed by SQL databases
Reporting databases migrating to Azure-managed database platforms
Multi-tenant SaaS databases consolidating or replatforming
Legacy on-premises SQL/MySQL/PostgreSQL environments moving to Azure

Architectures

Hub-and-spoke networking with shared services VNets
Hybrid networks (on-prem to Azure via VPN/ExpressRoute)
Landing zone deployments where migrations must follow tagging, RBAC, and policy controls
Blue/green cutover patterns for applications

Real-world deployment contexts

Production migrations with carefully controlled cutover windows and rollback plans
Dev/test migrations for modernization testing and performance validation
Disaster recovery migrations (less common, but sometimes used to seed data into Azure)

5. Top Use Cases and Scenarios

Below are realistic scenarios where Azure Database Migration Service is commonly used. Each includes the problem, why the service fits, and an example.

1) SQL Server to Azure SQL Database (offline)

Problem: Move a SQL Server database to Azure SQL Database with a planned downtime window.
Why it fits: Provides a guided workflow and status tracking for moving data into Azure SQL Database.
Example: A departmental app migrates from a SQL Server VM to Azure SQL Database over a weekend maintenance window.

2) SQL Server to Azure SQL Managed Instance (replatform with reduced downtime where supported)

Problem: Maintain high compatibility with SQL Server features while reducing downtime.
Why it fits: Online/reduced-downtime patterns may be supported depending on versions and configuration (verify).
Example: A CRM database uses SQL Agent and cross-database features; team chooses Azure SQL Managed Instance and runs a minimized downtime cutover.

3) MySQL to Azure Database for MySQL (replatform)

Problem: Replace self-managed MySQL with managed MySQL in Azure.
Why it fits: Orchestrates schema/data movement (scenario-dependent) with centralized management.
Example: A LAMP stack uses MySQL on a Linux VM; team migrates to Azure Database for MySQL for patching/backup automation.

4) PostgreSQL to Azure Database for PostgreSQL (migration with replication-based cutover where supported)

Problem: Minimize downtime while moving a PostgreSQL database.
Why it fits: Some PostgreSQL migrations can use online methods (verify exact requirements).
Example: A fintech service migrates from on-prem PostgreSQL to Azure Database for PostgreSQL during a short cutover.

5) Oracle to Azure (engine-specific pathways)

Problem: Leave expensive on-prem licensing and hardware while retaining database capabilities.
Why it fits: Azure migration pathways exist, but Oracle migrations can be complex and may require additional tooling (verify current best practice).
Example: An enterprise ERP system migrates Oracle databases to Azure targets with a combination of tools and staged cutover.

6) Hybrid migrations over VPN/ExpressRoute

Problem: Source database cannot be exposed to the internet.
Why it fits: Deploy Azure Database Migration Service into a VNet and route privately to on-prem networks.
Example: A hospital migrates a patient system database over ExpressRoute, keeping all traffic private.

7) Multi-database wave migrations

Problem: Hundreds of small databases need standardized migration execution.
Why it fits: Projects and activities create consistent operational workflows and auditing.
Example: A SaaS provider moves per-customer databases in waves, tracking each migration and cutover.

8) Pre-production rehearsal and cutover validation

Problem: Need repeatable rehearsals to validate downtime, performance, and rollback.
Why it fits: Enables structured runs and iteration (even if you recreate the target each time).
Example: Team runs three rehearsal migrations to refine timing and confirm the application works with the Azure target.

9) Consolidation into fewer managed instances/databases

Problem: Reduce operational overhead by consolidating multiple on-prem databases into Azure-managed services.
Why it fits: Supports a controlled migration plan with staged moves.
Example: Ten on-prem SQL Server databases move into a smaller number of Azure SQL Managed Instances.

10) Data center exit deadlines

Problem: Fixed deadline to vacate a data center; migrations must be executed reliably and tracked.
Why it fits: Provides a standardized, Azure-native migration execution approach.
Example: A retailer uses an Azure landing zone, then migrates databases in prioritized order with traceable migration status.

11) Split production and reporting workloads

Problem: Reporting workload overloads production database.
Why it fits: Migration can move the reporting database to Azure as a first step, then production later.
Example: Move a replicated reporting database to Azure SQL first, then plan the OLTP migration.

12) Regulated change control with evidence

Problem: Need evidence of steps, timing, and validation for audits.
Why it fits: Projects/activities plus Azure Activity Log and operational runbooks support audit trails.
Example: A bank runs migrations under change tickets, capturing configurations, results, and validation queries.

6. Core Features

Feature availability depends on the source engine, target engine, versions, and chosen migration mode. Always validate your exact scenario against Microsoft’s official support matrix.

1) Migration projects and guided workflows

What it does: Organizes migrations by source/target type and provides guided steps to configure endpoints and run activities.
Why it matters: Reduces missed steps and provides consistency across migrations.
Practical benefit: Faster onboarding for new operators; repeatable execution.
Caveats: UI and available project types change over time—verify the latest portal/tooling flow in official docs.

2) Offline migrations (planned downtime)

What it does: Moves data in a batch; applications are typically stopped during final cutover to avoid data changes.
Why it matters: Simplest and often most reliable migration mode.
Practical benefit: Predictable run steps; fewer moving parts than continuous replication.
Caveats: Requires downtime window; large databases can exceed the window without careful planning.

3) Online (reduced downtime) migrations (scenario-dependent)

What it does: Uses continuous synchronization patterns to reduce cutover downtime.
Why it matters: Enables near-zero or reduced downtime migrations for critical systems.
Practical benefit: Shorter outages; business continuity.
Caveats: Not supported for every source/target; may have prerequisites (replication settings, log retention, permissions). Verify exact requirements.

4) VNet-integrated deployment for private connectivity

What it does: Deploys the service into your VNet subnet so it can reach private IPs for source systems.
Why it matters: Production databases are commonly private; public exposure is often prohibited.
Practical benefit: Works with VPN/ExpressRoute; aligns with enterprise security.
Caveats: Subnet sizing and NSG rules are common failure points; plan networking early.

5) Status monitoring and progress tracking

What it does: Shows progress of migration activities, including errors and completion status.
Why it matters: Operators need visibility and ability to troubleshoot quickly.
Practical benefit: Easier coordination during cutover windows.
Caveats: Depth of logs/metrics can vary; for deep troubleshooting you may still need source/target engine logs.

6) Integration with Azure governance (RBAC, tags, resource groups)

What it does: Uses standard Azure resource management controls.
Why it matters: Enterprises need consistent access controls and cost allocation.
Practical benefit: Least privilege access and chargeback/showback.
Caveats: RBAC controls access to the service resource; it does not automatically grant database-level permissions on source/target.

7) Support for multiple database engines and Azure targets (via support matrix)

What it does: Provides a single Azure-native service for multiple migration types.
Why it matters: Standardization reduces tool sprawl.
Practical benefit: Shared runbooks and operational patterns.
Caveats: Capability differences across engines are significant; validate per engine.

7. Architecture and How It Works

High-level architecture

Azure Database Migration Service consists of: – A control plane: Azure Resource Manager + Azure Portal (and sometimes other Microsoft tools) to create/manage the DMS resource and migration projects. – A data plane: The migration runtime deployed into your VNet that connects to source/target endpoints and transfers data.

Request/data/control flow (typical)

You create Azure Database Migration Service in Azure (control plane operation).
You create a migration project and activity in the portal (control plane).
The DMS runtime connects to: – Source database (often private IP reachable through VNet routing/VPN/ExpressRoute) – Target Azure database (public endpoint with firewall rules or private endpoint)
Data is moved according to the selected mode.
DMS reports status back to the portal.

Integrations with related services

Common integrations (not all are required): – Azure Virtual Network: Required for many scenarios so DMS can reach private sources. – Azure VPN Gateway / ExpressRoute: For hybrid connectivity to on-prem sources. – Azure SQL / Azure Database for PostgreSQL/MySQL: Targets. – Azure Storage: Sometimes used in migration workflows (for example, backup files), depending on scenario—verify. – Azure Monitor / Activity Log: Operational governance around resource changes; deeper telemetry varies—verify.

Dependency services

DNS resolution between DMS subnet and source/target endpoints
Network routing (UDRs, VPN/ER routes)
Firewalls/NSGs
Database engine permissions on source and target

Security/authentication model

Azure RBAC controls who can create/manage the DMS resource and migration projects.
Database authentication to source/target typically uses database credentials you provide (SQL logins, database users, etc.).
Where Azure AD authentication is an option (for example, Azure SQL), DMS support depends on the scenario—verify in official docs.

Networking model

DMS is commonly deployed into a dedicated subnet.
It must have IP connectivity to:
Source database host/port
Target database host/port
Targets may be accessed via:
Public endpoint + firewall rules (and sometimes “Allow Azure services…” style settings for Azure SQL)
Private endpoint (requires private DNS + VNet integration)

Monitoring/logging/governance considerations

Use resource tags and naming conventions for traceability.
Track operator activity via Azure Activity Log (who created/modified the service/projects).
Capture migration run logs/status screenshots/exports as part of change management evidence (where required).
For performance and errors, also monitor source/target engine logs and metrics (DTU/vCore utilization, locks, replication lag, storage IOPS, etc.).

Simple architecture diagram (Mermaid)

flowchart LR
  U[Operator] --> P[Azure Portal / ARM]
  P --> DMS[Azure Database Migration Service<br/>in Azure VNet subnet]
  DMS --> SRC[Source DB<br/>SQL Server on VM/on-prem]
  DMS --> TGT[Target DB<br/>Azure SQL Database]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph OnPrem[On-premises / Legacy environment]
    SRCDB[(Source Database)]
    APP[Application Servers]
  end

  subgraph Azure[Azure Subscription]
    subgraph Hub[Hub VNet]
      VPN[VPN/ExpressRoute Gateway]
      DNS[DNS / Private Resolver (optional)]
    end

    subgraph Spoke[Spoke VNet - Migration]
      subgraph Subnets[Subnets]
        DMSNET[Dedicated DMS Subnet]
        MGMT[Ops/Bastion Subnet (optional)]
      end
      DMS[Azure Database Migration Service]
      BASTION[Azure Bastion (optional)]
      JUMP[Jumpbox/VM for tools (optional)]
    end

    subgraph Data[Azure Data Platform]
      AZSQL[(Azure SQL Database / Managed Instance)]
      KV[Key Vault (recommended for secrets mgmt)]
      MON[Azure Monitor / Log Analytics (verify DMS telemetry options)]
    end
  end

  APP --> SRCDB
  SRCDB <-->|Private routes| VPN
  VPN <-->|VNet peering / routing| Spoke
  DMS -->|DB port| SRCDB
  DMS -->|DB port| AZSQL
  U[Admins/Operators] --> BASTION --> JUMP
  JUMP --> SRCDB
  JUMP --> AZSQL

8. Prerequisites

Azure account/subscription requirements

An active Azure subscription with permission to create:
Resource groups
Virtual networks/subnets
Azure Database Migration Service resource
Target database service (Azure SQL, etc.)

Permissions / IAM roles (typical)

Exact role needs vary by org policy; common minimums: – Contributor on the resource group (to create resources), or more restrictive custom roles: – Ability to create/manage DMS – Ability to create/manage VNet/subnet resources (or have networking team do it) – Ability to create/manage Azure SQL resources (or have DBA/platform team do it) – Database-level permissions: – On source: privileges sufficient to read schema/data and, for online migrations, replication/log access (scenario-dependent) – On target: privileges to create schema/objects and write data

Billing requirements

DMS service tier charges (usage-based)
Target database charges (Azure SQL)
VM charges if you host a source database in Azure for testing
Networking charges if using VPN/ExpressRoute
Storage charges for backups/logs if used

Tools needed (for this tutorial)

Azure Portal access
Azure CLI (optional but recommended): https://learn.microsoft.com/cli/azure/install-azure-cli
SQL client for validation:
sqlcmd (for SQL Server/Azure SQL) or Azure Data Studio/SSMS on your workstation
In this lab we’ll use sqlcmd on a Linux VM for repeatability

Region availability

Azure Database Migration Service is a regional service.
Not every region supports every combination or feature. Verify region support in official docs before choosing a region.

Quotas/limits

Subnet sizing and service constraints can block deployment.
Migration throughput depends on service tier, network bandwidth/latency, and target performance tier.
Always review DMS limits and constraints in official docs for your migration type.

Prerequisite services (for typical hybrid production)

Azure VNet + dedicated subnet for DMS
VPN Gateway or ExpressRoute (if source is on-prem and private)
Target database provisioned and reachable from DMS

9. Pricing / Cost

Current pricing model (how you are charged)

Azure Database Migration Service pricing is primarily based on: – Selected service tier/SKU (for example, tiers that may differentiate offline vs online capability) – Compute/time the migration service runs (billing often correlates with hours the service is provisioned or actively running—confirm exact billing rules on the pricing page) – Potentially other SKU dimensions (region-dependent)

Because pricing changes and is region-dependent, do not rely on blog posts for numbers. Use: – Official pricing page: https://azure.microsoft.com/pricing/details/database-migration/ – Azure Pricing Calculator: https://azure.microsoft.com/pricing/calculator/

Verify the current tier names and exactly what is billed (provisioned hours vs active hours) in the official pricing page. The model has changed over time.

Pricing dimensions to plan for

DMS service tier (capabilities and performance)
Runtime duration (hours/days the service exists and/or runs migrations)
Data volume migrated and how many attempts/rehearsals you run
Network path (VPN/ExpressRoute vs in-Azure)
Target database sizing (Azure SQL tier/vCores/storage)
Source environment costs (VMs, storage, licenses) if you run migration staging in Azure

Free tier

Azure Database Migration Service has historically had limited-time or scenario-specific considerations; assume no free tier unless explicitly stated on the official pricing page.

Key cost drivers (direct + indirect)

Direct: – DMS tier + hours – Target database compute/storage (often the dominant cost in production)

Indirect/hidden: – Rehearsal migrations (multiple runs multiply compute/time) – Network egress from on-prem or other clouds (ISP/MPLS costs, cloud egress) – VPN Gateway / ExpressRoute hourly + data processing costs – Operational time: troubleshooting connectivity, performance tuning, and validation – Downtime cost: offline migrations can have business impact

Network/data transfer implications

Data movement within Azure is typically cheaper than cross-cloud.
Moving data out of other clouds usually incurs significant egress fees.
Hybrid migrations depend on your network throughput/latency; slow links increase migration duration (and therefore cost).

How to optimize cost

Prefer offline migrations for non-critical workloads when downtime is acceptable.
Run rehearsals on smaller subsets or restored copies to validate steps before full runs.
Right-size:
DMS tier (don’t overpay for features you can’t use)
Target database tier during migration (you may temporarily scale up for load, then scale down)
Keep the service alive only as long as needed; delete resources after migration if not required.

Example low-cost starter estimate (model, not numbers)

A low-cost lab typically includes: – 1 small Linux VM (B-series) for a source SQL Server test instance – 1 small Azure SQL Database for target – 1 Azure Database Migration Service instance (lowest tier that supports your scenario) – Minimal networking (single VNet)

Total cost depends on: – Region – VM hours – Azure SQL tier and storage – DMS tier and hours
Use the Azure Pricing Calculator to model these components.

Example production cost considerations

For production, plan for: – Separate environments (dev/test/prod) and at least one rehearsal = multiple runs – Higher Azure SQL tiers during migration windows – VPN/ExpressRoute costs if hybrid – Operational overhead for monitoring, cutover support, rollback readiness – Data validation tooling and potential parallel run periods

10. Step-by-Step Hands-On Tutorial

This lab demonstrates an offline migration of SQL Server to Azure SQL Database using Azure Database Migration Service. The source SQL Server runs on a small Linux VM in Azure to keep networking simple and costs controllable.

Objective

Migrate a sample SQL Server database from a SQL Server instance running on an Ubuntu VM to Azure SQL Database using Azure Database Migration Service (offline migration), then validate data and clean up resources.

Lab Overview

You will: 1. Create a resource group and virtual network with two subnets (VM + DMS). 2. Deploy an Ubuntu VM and install SQL Server Developer Edition. 3. Create a sample database and data on the source SQL Server. 4. Create an Azure SQL Database target. 5. Deploy Azure Database Migration Service into a dedicated subnet. 6. Create a migration project and run an offline migration. 7. Validate row counts on the target. 8. Clean up all resources.

Expected outcome:
You can log into Azure SQL Database and query the migrated tables with matching row counts.

Step 1: Create the Azure resource group, VNet, and subnets

Why: DMS commonly requires VNet integration, and you want the DMS runtime to reach the source SQL Server privately.

In Azure Portal, create a Resource group (example: rg-dms-lab).
Create a Virtual network (example: vnet-dms-lab) in the same region.

Create two subnets: – subnet-vm (example: 10.10.1.0/24) – subnet-dms (example: 10.10.2.0/27)

DMS subnet sizing requirements can be strict (often requiring at least /27 and dedicated use). Verify current subnet requirements in official docs if deployment fails.

Expected outcome:
A VNet with two subnets exists.

Verification: – Azure Portal → Virtual networks → vnet-dms-lab → Subnets shows both subnets.

Step 2: Deploy an Ubuntu VM for the source SQL Server

Why: You need a source database endpoint accessible to DMS over the network.

Create an Ubuntu LTS VM (example size: Standard_B2s) in subnet-vm.
Allow inbound: – SSH (22) from your public IP (for admin access)
Do not expose SQL Server (1433) to the internet.

NSG rule for SQL Server (internal only): – Inbound rule on VM’s NSG: – Source: 10.10.2.0/27 (the DMS subnet) – Destination port: 1433 – Protocol: TCP – Action: Allow

Expected outcome:
VM is reachable via SSH, and port 1433 is reachable from the DMS subnet only.

Verification (SSH): From your workstation:

ssh azureuser@<VM_PUBLIC_IP>

Step 3: Install SQL Server on Ubuntu and create sample data

On the VM, install SQL Server Developer Edition (or another supported edition). Microsoft’s installation steps can change by distro/version, so follow the official SQL Server on Linux install guide and then return here.

Official docs entry point (verify current version steps):
https://learn.microsoft.com/sql/linux/sql-server-linux-setup

After installation: 1. Ensure SQL Server is running 2. Enable TCP/IP on port 1433 (default on Linux installs) 3. Set the sa password and confirm local connectivity

Install sqlcmd tooling (for validation on Linux):
Follow the official sqlcmd installation guide (package names vary by distro/version): – https://learn.microsoft.com/sql/tools/sqlcmd/sqlcmd-utility

Create a sample database and table Run on the VM (adjust SA_PASSWORD as set during install):

export SA_PASSWORD='YourStrong!Passw0rd'
/opt/mssql-tools*/bin/sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -Q "SELECT @@VERSION;"

Create a database and insert rows:

/opt/mssql-tools*/bin/sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -Q "
CREATE DATABASE DmsLabDb;
GO
"

Now create schema and data:

/opt/mssql-tools*/bin/sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -d DmsLabDb -Q "
CREATE TABLE dbo.Customers
(
  CustomerId INT IDENTITY(1,1) PRIMARY KEY,
  FullName NVARCHAR(200) NOT NULL,
  Email NVARCHAR(320) NULL,
  CreatedAt DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME()
);

INSERT INTO dbo.Customers (FullName, Email) VALUES
('Ada Lovelace','ada@example.com'),
('Grace Hopper','grace@example.com'),
('Linus Torvalds','linus@example.com');

SELECT COUNT(*) AS CustomerCount FROM dbo.Customers;
"

Expected outcome:
CustomerCount returns 3.

Verification:
Also capture the VM private IP (needed for DMS to connect):

hostname -I

Record the VM private IP address (example: 10.10.1.4).

Step 4: Create the Azure SQL Database target

Why: DMS needs a target database provisioned in Azure.

Azure Portal → Create → Azure SQL → SQL Database
Create a new SQL server (logical server) with: – SQL authentication admin user and password (store securely) – Region same as DMS for best performance
Choose a low-cost tier for testing (any tier that meets minimum needs). Exact tier naming changes; select something entry-level for labs.

Networking: – For simplest lab connectivity, use the default public endpoint and set: – Add your client IP to firewall rules (so you can validate with a client) – Enable the Azure SQL server setting often called “Allow Azure services and resources to access this server” (wording may vary). This can help DMS reach the server.

Security note: In production, prefer private endpoints and strict firewall rules. For a lab, the “Allow Azure services…” setting is convenient but broader.

Expected outcome:
An Azure SQL Database exists and is reachable.

Verification (optional from VM): Install sqlcmd (already installed for SQL Server) and test connecting to Azure SQL:

/opt/mssql-tools*/bin/sqlcmd -S tcp:<your-sql-server-name>.database.windows.net,1433 \
  -U <sql-admin-user> -P '<sql-admin-password>' -d <db-name> \
  -Q "SELECT @@VERSION;"

If your Azure SQL firewall blocks the VM, run validation from your workstation instead, after allowing your IP.

Step 5: Create Azure Database Migration Service

Why: This is the migration runtime that will connect to source SQL Server and target Azure SQL Database.

Azure Portal → Create a resource → search for Azure Database Migration Service
Create the service: – Subscription + resource group: rg-dms-lab – Name: dms-lab-001 – Region: same as VNet and Azure SQL – Select a tier/SKU that supports offline SQL Server to Azure SQL Database migrations
(often a “Standard” tier supports offline migrations; verify current tiers in docs/pricing) – Networking: select vnet-dms-lab and subnet-dms

Expected outcome:
DMS resource is deployed successfully into subnet-dms.

Verification: – Azure Portal → DMS resource → Overview shows “Succeeded”.

Step 6: Create a migration project and start an offline migration

The portal experience can vary by update, but the core inputs are consistent: source type, target type, migration mode, connectivity details, database selection, then run.

Open the DMS resource in the Azure Portal.
Create a New Migration Project (name example: sqlserver-to-azuresql-offline-lab).
Choose: – Source server type: SQL Server – Target server type: Azure SQL Database – Migration activity type: Offline (or “offline data migration”)
Configure Source connection: – Server name: VM private IP (example 10.10.1.4) – Port: 1433 – Authentication: SQL Authentication – User: sa – Password: your sa password
– Encrypt connection: depends on your setup; if you enabled encryption or require TLS, configure accordingly. If unsure, verify in docs and prefer encrypted connections in real environments.
Configure Target connection: – Azure SQL logical server name (FQDN): <your-sql-server-name>.database.windows.net – Authentication: SQL Authentication (admin or a migration user) – Ensure target firewall permits DMS (see Step 4 notes)
Select the database: – DmsLabDb – Select tables (for this lab, dbo.Customers)
Start the migration activity.

Expected outcome:
Migration activity starts and shows progress; eventually it completes successfully.

Verification: – In the migration activity view, confirm: – Status: Running → Completed – Rows migrated for dbo.Customers equals 3 (or shows completion without errors)

Step 7: Validate data on the target

Connect to Azure SQL Database and confirm row counts.

From your workstation (Azure Data Studio/SSMS) or via sqlcmd:

/opt/mssql-tools*/bin/sqlcmd -S tcp:<your-sql-server-name>.database.windows.net,1433 \
  -U <sql-admin-user> -P '<sql-admin-password>' -d <db-name> \
  -Q "SELECT COUNT(*) AS CustomerCount FROM dbo.Customers;"

Expected outcome:
CustomerCount returns 3.

Additional validation queries (recommended):

SELECT TOP 10 * FROM dbo.Customers ORDER BY CustomerId;
SELECT MIN(CreatedAt) AS MinCreatedAt, MAX(CreatedAt) AS MaxCreatedAt FROM dbo.Customers;

Validation

Use this checklist to confirm the lab succeeded:

[ ] DMS service deployed in the correct region and subnet
[ ] DMS can reach the source SQL Server VM private IP on port 1433 (NSG allows it)
[ ] DMS can connect to Azure SQL Database (firewall/“Allow Azure services…” configured)
[ ] Migration activity completes successfully
[ ] Row counts match between source and target

To verify source count:

/opt/mssql-tools*/bin/sqlcmd -S localhost -U sa -P "$SA_PASSWORD" -d DmsLabDb -Q \
"SELECT COUNT(*) AS CustomerCount FROM dbo.Customers;"

Troubleshooting

Common issues and realistic fixes:

DMS deployment fails due to subnet constraints – Cause: Subnet too small, not dedicated, or has conflicting policies. – Fix: Create a dedicated subnet (often /27 or larger) for DMS and retry. Verify requirements in official docs.
DMS can’t connect to source SQL Server – Cause: NSG blocks 1433, SQL Server not listening on network interface, wrong private IP. – Fix:
- Confirm VM private IP
- Confirm inbound NSG rule allowing 10.10.2.0/27 → 1433
- Confirm SQL Server listens on 0.0.0.0:1433 (or the VM IP)
- Confirm VM firewall (ufw/iptables) allows 1433 from DMS subnet
Login failed for user – Cause: Wrong credentials; SQL auth disabled; password policy. – Fix: Reset the sa password; ensure SQL auth works; test locally with sqlcmd.
DMS can’t connect to Azure SQL Database – Cause: Azure SQL firewall blocks DMS; “Allow Azure services…” not enabled; wrong server FQDN. – Fix:
- Confirm server name is <server>.database.windows.net
- Enable “Allow Azure services and resources…”
- Ensure target database exists and credentials are correct
Schema missing on target – Cause: Some migration flows migrate data only or require schema pre-creation depending on scenario. – Fix: Create schema first (manually or via supported tooling) and rerun. Verify whether your migration activity migrates schema for your chosen mode.
Performance is slow – Cause: Small target tier, limited VM size, network bottleneck. – Fix: Temporarily scale up target tier during migration; verify throughput; run during low usage.

Cleanup

To avoid ongoing charges, delete lab resources:

Stop/delete the VM (and its disks/public IP).
Delete Azure SQL Database and logical server (after confirming no needed data).
Delete the DMS resource.
Delete the VNet (if not used by anything else).
Delete the resource group rg-dms-lab (fastest for full cleanup).

Expected outcome:
No chargeable resources remain.

11. Best Practices

Architecture best practices

Decide migration mode early (offline vs online) based on downtime tolerance.
Separate work into phases: 1. Assess (compatibility/performance) 2. Pilot (small representative workload) 3. Rehearsal (full procedure) 4. Production cutover (change-controlled)
Use a landing zone approach: standardized networking, identity, policies, and logging before migrations.

IAM/security best practices

Use least privilege:
Azure RBAC: give operators only what they need (often Contributor on a dedicated RG).
Database permissions: use migration-specific users, not sysadmin, where possible.
Keep secrets out of chat/tickets; store in a secret manager (for example, Azure Key Vault) and handle carefully during operator workflows.

Cost best practices

Delete DMS resources after migration waves if not needed.
Scale Azure SQL target tier up for migration throughput, then scale down after validation.
Minimize rehearsal data volume when practicing, but run at least one full rehearsal before production.

Performance best practices

Co-locate resources in the same region to reduce latency.
Ensure target is sized to handle migration write load (IOPS/CPU).
Avoid migrating during peak usage (even for offline, do prep steps off-hours).

Reliability best practices

Always have a rollback plan:
For offline: keep original source untouched until validation passes.
For online: have a cutback plan and understand resync implications.
Use maintenance windows with clear go/no-go criteria.

Operations best practices

Run migrations with a checklist:
Connectivity validation
Backup verification
Migration start/end timestamps
Post-migration validation queries
Monitor:
Source: CPU/memory/disk, transaction log growth
Target: CPU/storage/DTU or vCore metrics, blocking, tempdb usage

Governance/tagging/naming best practices

Tag resources:
CostCenter, Environment, App, Owner, MigrationWave
Use consistent names:
dms-<app>-<env>-<region>-<nnn>
Use Azure Policy to enforce:
Allowed regions
Required tags
Private networking requirements (where applicable)

12. Security Considerations

Identity and access model

Azure RBAC governs who can manage Azure Database Migration Service resources and projects.
Database credentials provided to DMS must have the required permissions on source/target.
Prefer dedicated migration accounts with scoped permissions and rotation after cutover.

Encryption

Use encrypted connections (TLS) where supported for source/target connections.
Azure SQL encrypts data at rest by default (platform-managed); verify encryption settings for other targets.
For source systems, confirm disk encryption and backup encryption practices.

Network exposure

Prefer private connectivity:
DMS in a private subnet
Source reachable via private IP (VPN/ExpressRoute)
Target via private endpoint where feasible
Avoid exposing database ports publicly for the sake of migration.

Secrets handling

Treat source/target passwords as high sensitivity:
Store in Key Vault
Use short-lived access where possible
Limit who can view/edit migration project settings

Audit/logging

Use Azure Activity Log to track changes to the DMS resource (creation, deletion, configuration changes).
Database auditing:
Azure SQL auditing can record logins and queries (configure per policy)
Source database audit logs should be preserved during migration windows

Compliance considerations

Ensure data residency requirements match the Azure region.
Validate that your migration path meets regulatory requirements (PII/PHI handling, encryption-in-transit, access controls).
Document evidence for change control (who ran the migration, when, results, validation).

Common security mistakes

Allowing public access to source DB “just for migration”
Leaving broad firewall rules enabled after cutover
Reusing production admin credentials in migration projects
Not rotating secrets after migration

Secure deployment recommendations

Use private networking and strict NSG rules.
Use separate resource groups and RBAC roles for migration operations.
Perform a pre-migration security review of connectivity and credential handling.

13. Limitations and Gotchas

Because capabilities vary by scenario and evolve over time, treat these as common pitfalls and validate details in official docs.

Known limitations (scenario-dependent)

Not all source/target pairs support online migrations.
Some migrations require schema to be prepared ahead of time.
Certain database features may not be supported on the target platform (for example, SQL Server instance-level features when moving to Azure SQL Database).

Quotas

Subnet sizing and dedicated subnet requirements can block deployment.
Throughput is limited by network and target service tier.

Regional constraints

DMS is regional; not all regions support all features.
Cross-region migrations add latency and complexity—avoid if possible.

Pricing surprises

Leaving DMS resources running longer than needed can increase cost.
Target database scaling during migration can increase costs (plan scale-down steps).

Compatibility issues

Collation differences, unsupported data types, or feature gaps can break application behavior.
Azure SQL Database vs SQL Server differences are significant; use assessments and testing.

Operational gotchas

NSGs and firewalls are the #1 cause of failed connectivity.
DNS resolution issues in VNets (especially with private endpoints) can prevent connections.
Transaction log growth (for online/replication-based migrations) can cause source disk issues.

Migration challenges

Large objects (LOBs), very large tables, and high-write workloads need careful planning.
“It migrated” does not equal “the app works.” Plan application regression testing.

14. Comparison with Alternatives

Azure Database Migration Service is one option in a broader migration toolkit.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Azure Database Migration Service	Azure-native database migrations with guided workflows	VNet-integrated runtime, structured projects, offline/online options depending on scenario	Support and features vary by engine; networking can be complex	When you want an Azure-supported migration execution service
Azure SQL migration tooling/experiences (Microsoft)	SQL Server to Azure SQL family migrations	Often provides assessments + guided steps; may integrate multiple components	Tooling changes over time; may be SQL-specific	When migrating to Azure SQL and Microsoft recommends it for your scenario (verify)
Native engine tools (backup/restore, dump/restore, replication)	Simple or highly controlled migrations	Transparent, scriptable, no extra service dependency	More manual orchestration; less centralized tracking	When you want maximum control and have DBA automation expertise
Azure Data Factory / Synapse pipelines	Data movement/ETL rather than lift-and-shift DB migration	Great for transformation and ongoing integration	Not a full-fidelity DB migration tool	When you are transforming data, not migrating databases as databases
Third-party migration tools	Complex heterogeneous migrations	Mature wizards, transformations, validations	Licensing cost, vendor lock-in	When you need cross-engine transformations and enterprise migration suites
AWS Database Migration Service (AWS)	Migrations into AWS	Managed migrations and replication in AWS	Not Azure-native; cross-cloud adds complexity	When your target is AWS, not Azure
Google Database Migration Service (GCP)	Migrations into GCP	GCP-native migration tooling	Not Azure-native	When your target is GCP

15. Real-World Example

Enterprise example: Hybrid SQL Server estate moving to Azure SQL Managed Instance

Problem: A company has 50+ SQL Server databases on-prem, strict security policies, and limited downtime windows. Some databases rely on SQL Server instance-level features.
Proposed architecture:
ExpressRoute from on-prem to Azure hub VNet
Spoke VNet for migration with Azure Database Migration Service in a dedicated subnet
Target: Azure SQL Managed Instance in a dedicated subnet (plus private DNS)
Controlled cutover waves, with rehearsals in pre-prod
Why Azure Database Migration Service was chosen:
Fits private networking requirements
Provides structured project-based migration execution
Supports reduced downtime patterns for some SQL scenarios (verify exact support)
Expected outcomes:
Reduced patching/backup overhead by adopting managed services
Repeatable migration process across waves
Documented cutovers aligned with change control

Startup/small-team example: Move from SQL Server on a VM to Azure SQL Database

Problem: A startup runs SQL Server on a single VM and wants to reduce maintenance while improving availability.
Proposed architecture:
Source: SQL Server on VM
Target: Azure SQL Database (General Purpose tier sized for workload)
Azure Database Migration Service for a weekend offline migration
Why Azure Database Migration Service was chosen:
Simple migration workflow without building custom scripts
Clear progress tracking and repeatable process
Expected outcomes:
Less operational burden (patching, backups, HA)
Easier scaling and monitoring
Faster recovery options using built-in Azure SQL capabilities

16. FAQ

Is Azure Database Migration Service the same as Azure Migrate?
No. Azure Migrate is broader (discovery/assessment across servers/apps). Azure Database Migration Service focuses on executing database migrations. They are often used together.
Do I always need a VNet for Azure Database Migration Service?
Many common scenarios deploy DMS into a VNet subnet, especially to reach private sources. Exact requirements depend on the migration type—verify in official docs.
Can Azure Database Migration Service migrate schema and data?
It can for some scenarios, while others require you to prepare schema separately. Always confirm your scenario’s workflow in official docs.
What’s the difference between offline and online migration?
Offline is a batch move requiring downtime at cutover. Online aims to reduce downtime by continuously syncing changes until cutover. Online support is scenario-specific.
How do I minimize downtime with DMS?
Use online migrations where supported, rehearse cutover steps, pre-provision target performance, and keep validation automated.
Can I migrate from on-prem to Azure without exposing my database to the internet?
Yes—use VPN/ExpressRoute and deploy DMS into a VNet with private routing to the source.
Does DMS support migrations from other clouds?
If network connectivity and your source engine are supported, yes. But data egress costs and network design are your responsibility.
How do I estimate how long a migration will take?
Base it on data size, network throughput/latency, target write capacity, and migration mode. Run a pilot on representative data.
What’s the most common reason migrations fail?
Networking and connectivity: NSGs/firewalls, DNS, routing, and authentication issues.
Do I need DBA access on the source database?
You need enough permissions to read schema/data and possibly logs/replication settings for online migrations. Exact permissions vary by engine and mode.
Can I pause and resume a migration?
Capabilities depend on the migration type and tooling flow. Plan for restartability by keeping source stable and documenting steps. Verify pause/resume behavior for your scenario.
Should I run DMS in production permanently?
Typically no. It’s used during migration waves and then removed to reduce cost and attack surface.
How do I validate data correctness after migration?
Use row counts, checksums/hashes (where feasible), sampled data comparisons, application-level tests, and performance tests on target queries.
What about stored procedures, jobs, and users?
It depends on the target platform. For Azure SQL Database, some instance-level features don’t exist. Plan a full “database + surrounding objects” migration strategy.
Where do I find the exact list of supported migrations and prerequisites?
In Microsoft Learn documentation for Azure Database Migration Service and the specific migration tutorial for your source/target pair: https://learn.microsoft.com/azure/dms/

17. Top Online Resources to Learn Azure Database Migration Service

Resource Type	Name	Why It Is Useful
Official documentation	https://learn.microsoft.com/azure/dms/	Primary reference for concepts, supported scenarios, and step-by-step guides
Official pricing page	https://azure.microsoft.com/pricing/details/database-migration/	Authoritative pricing model and tier information
Pricing calculator	https://azure.microsoft.com/pricing/calculator/	Build scenario-based cost estimates (DMS + target DB + network)
Azure SQL documentation	https://learn.microsoft.com/azure/azure-sql/	Target platform details, firewall/private endpoint guidance, performance tiers
SQL Server on Linux docs	https://learn.microsoft.com/sql/linux/sql-server-linux-setup	Repeatable lab setup for a source SQL Server on Ubuntu
sqlcmd utility docs	https://learn.microsoft.com/sql/tools/sqlcmd/sqlcmd-utility	Command-line validation and scripting for SQL Server/Azure SQL
Azure networking fundamentals	https://learn.microsoft.com/azure/virtual-network/	VNets, subnets, NSGs, routing—critical for DMS connectivity
Azure VPN Gateway	https://learn.microsoft.com/azure/vpn-gateway/	Hybrid connectivity patterns often used for production migrations
ExpressRoute	https://learn.microsoft.com/azure/expressroute/	Private connectivity for enterprise-scale hybrid migrations
Azure Architecture Center	https://learn.microsoft.com/azure/architecture/	Reference architectures and best practices that inform migration designs

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, cloud engineers	Azure operations, DevOps practices, migration-adjacent skills	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate practitioners	DevOps/SCM fundamentals, automation foundations	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers and operators	Cloud ops, deployment/operations skills	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, platform teams	Reliability engineering, monitoring, incident response	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams exploring AIOps	Monitoring automation, AIOps concepts	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content (verify offerings)	Students, working professionals	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training (verify course coverage)	Beginners to intermediate DevOps engineers	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps help/training platform (verify)	Teams seeking short-term help	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support/training (verify)	Ops/DevOps teams needing guidance	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify exact offerings)	Migration planning, cloud ops, implementation support	Migration runbooks, Azure landing zone alignment, cutover planning	https://cotocus.com/
DevOpsSchool.com	Training + consulting services (verify catalog)	DevOps transformation, cloud migration assistance	Building CI/CD for migration tooling, operational readiness	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify exact offerings)	DevOps practices, automation, cloud enablement	IaC standardization, environment automation for migration waves	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Azure Database Migration Service

Database fundamentals:
Backups/restores, transaction logs, indexing, constraints
Basic performance troubleshooting
Azure fundamentals:
Resource groups, RBAC, VNets/subnets, NSGs
Target platform basics:
Azure SQL Database vs Azure SQL Managed Instance differences
Authentication and firewall/private endpoint patterns

What to learn after

Advanced migration patterns:
Online migration prerequisites and change data capture concepts
Data validation automation and reconciliation
Production operations:
Azure Monitor, alerting, auditing
Cost management and capacity planning
Modernization:
Refactoring apps for managed databases
Resiliency patterns and DR design in Azure

Job roles that use it

Cloud engineer / cloud migration engineer
DBA / database platform engineer
Solutions architect
DevOps / SRE (cutover and reliability support)
Security engineer (networking and access reviews)

Certification path (Azure)

Microsoft certification names and requirements change. Consider: – Azure fundamentals and administrator tracks – Azure database-focused learning paths – Architecture certifications for end-to-end migration design
Verify current certification options on Microsoft Learn: https://learn.microsoft.com/credentials/

Project ideas for practice

Migrate SQL Server on a VM to Azure SQL Database and implement:
Private endpoints
Azure AD authentication (where supported)
Automated validation scripts
Build a “migration factory”:
Standard naming/tagging
Pre-flight network checks
Automated target provisioning and post-migration smoke tests
Compare offline vs online approaches with measurable downtime and performance metrics (where supported)

22. Glossary

Cutover: The moment you switch the application from the source database to the target database.
Offline migration: A migration mode where data is moved in batch; typically requires downtime at cutover.
Online migration: A migration mode designed to reduce downtime by continuously syncing changes until cutover (scenario-dependent).
Source: The database system you are migrating from.
Target: The Azure database service you are migrating to.
VNet (Virtual Network): Azure networking boundary used to isolate and route traffic privately.
Subnet: A range of IP addresses within a VNet; DMS often requires a dedicated subnet.
NSG (Network Security Group): Azure firewall-like rules controlling inbound/outbound traffic to subnets/NICs.
Private endpoint: A private IP interface in your VNet that connects to an Azure PaaS service privately.
Azure RBAC: Role-Based Access Control for managing access to Azure resources.
Logical SQL Server (Azure SQL): The Azure resource that hosts Azure SQL Databases and defines firewall/auth settings.
Throughput: Effective data transfer rate during migration, constrained by network and system performance.

23. Summary

Azure Database Migration Service is Azure’s managed service for orchestrating and executing database migrations into Azure targets. It matters because migrations require more than data copy—they require secure connectivity, repeatable workflows, and operational visibility, especially in enterprise environments.

It fits best as the migration execution engine in an Azure migration program, often working alongside assessment tools and landing zone architectures. Cost is primarily driven by service tier and runtime duration, plus the frequently larger costs of target database sizing and hybrid networking. Security success depends on private networking, least privilege access, and disciplined secrets handling.

Use Azure Database Migration Service when you want an Azure-native, structured migration approach and your source/target scenario is supported. Next, deepen your skills by validating your scenario against Microsoft’s support matrix and running a rehearsal migration using the official documentation: https://learn.microsoft.com/azure/dms/

Category