Moving a production database to the cloud sounds straightforward until you are staring at a maintenance window, a replication lag alert, and a rollback plan that nobody has tested. Azure Database Migration Service (DMS) exists to reduce that complexity. It is a fully managed service built into the Azure portal that handles schema conversion, data transfer, and continuous synchronization so your team can migrate databases to Azure SQL, Azure Database for MySQL, or Azure Database for PostgreSQL without rebuilding pipelines from scratch.
DMS is part of the broader Azure cloud ecosystem, but it is not the only migration tool Microsoft offers and it is not the right choice for every scenario. This guide explains what DMS actually does, which source databases it supports, how the migration process works phase by phase, and where DMS falls short compared to alternatives like Azure Migrate, SQL Server Migration Assistant (SSMA), and Azure Data Factory.
75% of databases will be deployed to or migrated to a cloud platform by 2025, according to Gartner. Azure holds 24% of the global cloud infrastructure market (Flexera, 2025), making Azure DMS one of the most commonly encountered migration tools in enterprise environments.
What Azure Database Migration Service Does?
Azure Database Migration Service is a managed migration tool that transfers database schemas and data from on-premises, other clouds, or Azure VMs to Azure-managed database services. It handles the heavy lifting of migration: assessing source database compatibility, converting schemas when needed, copying data, and synchronizing changes during cutover.
The service operates in two modes. Offline migration takes a snapshot of the source database, transfers it to Azure, and requires downtime during the entire copy process. Online migration sets up continuous replication between source and target, synchronizing changes in near real-time so the cutover window shrinks to minutes rather than hours.
DMS runs inside the Azure portal with no separate software to install. You create a migration project, connect your source and target databases, select the tables you want to migrate, and DMS handles the transfer. For SQL Server migrations specifically, there is also an Azure SQL Migration extension for Azure Data Studio that provides a guided desktop experience.
The distinction that matters: DMS moves databases. It does not move virtual machines, applications, or storage accounts. If your migration involves the entire server stack, you will need a broader Azure migration and modernization approach. A lift-and-shift migration handles full VM transfers, while DMS focuses specifically on the database layer. For the underlying infrastructure, an Azure landing zone should be configured before any migration begins.
Get a Cloud Migration Assessment
What Databases Can You Migrate?
DMS supports migrations from several source database engines to their Azure-managed equivalents. The supported combinations determine whether DMS is the right tool for your project.
SQL Server → Azure SQL Database / Azure SQL Managed Instance
The most mature migration path. Supports SQL Server 2005 through 2022. Both offline and online modes available. Online mode maintains continuous sync with under 5 minutes of cutover downtime for databases up to 10 TB. Schema assessment identifies compatibility issues before migration starts.
MySQL → Azure Database for MySQL
Supports MySQL 5.6, 5.7, and 8.0 as sources. Online migration with continuous replication available. Handles schema differences between MySQL versions automatically. Particularly useful for organizations running MySQL on-premises or on AWS RDS that want to consolidate on Azure.
PostgreSQL → Azure Database for PostgreSQL
Supports PostgreSQL 9.5 through 16 as sources. Online migration uses logical replication to synchronize changes. Extensions and custom types require manual validation before migration. Best suited for teams already using PostgreSQL who want managed infrastructure without rewriting application queries.
MongoDB → Azure Cosmos DB
Migrates MongoDB collections to the Azure Cosmos DB API for MongoDB. Supports MongoDB 3.4 through 6.0. Online mode available for continuous sync. Shard key mapping and indexing strategy need to be planned separately since Cosmos DB uses a different partitioning model.
Oracle → Azure Database for PostgreSQL
Requires Oracle-to-PostgreSQL schema conversion using SSMA or ora2pg before DMS handles the data transfer. Not a fully automated path, which makes it more complex than SQL Server or MySQL migrations. Planning for stored procedure and PL/SQL conversion is essential.
Get Azure Cloud Managed Support
How Azure DMS Works: Three Migration Phases
A successful database migration is not a single step. It breaks into three phases, each with its own tooling, decisions, and failure modes. DMS covers the middle phase directly and integrates with other tools for the first and third. Teams that follow a structured digital transformation roadmap consistently achieve faster cutovers and fewer rollbacks.
Phase 1: Assess
Before migrating anything, you need to know whether the source database is compatible with the target Azure service. DMS includes an assessment engine that scans your database for unsupported features, deprecated syntax, and schema elements that will not transfer cleanly.
For SQL Server, the Azure SQL Migration extension generates a readiness report flagging issues like cross-database queries, SQL Agent jobs, linked servers, and Service Broker usage. The report categorizes each issue by severity so your team can decide whether to refactor, work around, or choose Azure SQL Managed Instance instead.
This assessment step prevents the most expensive migration failures: discovering incompatibilities after the data has already been transferred.
Phase 2: Migrate
Once assessment is clean, DMS creates a migration project that connects the source database to the target Azure service. You select which schemas and tables to include, configure network connectivity (VPN, ExpressRoute, or public endpoint), and choose between offline and online migration modes.
During migration, DMS handles schema creation on the target, initial data copy (full load), and in online mode continuous change data capture from the source. A progress dashboard shows table-by-table status, row counts, and any errors.
For SQL Server online migrations, DMS reads the transaction log to capture changes during the copy. The source database continues operating normally while migration runs in the background. Cutover happens when replication lag drops to near zero.
Phase 3: Optimize
After cutover, the migration is technically complete but the work is not finished. Post-migration optimization includes repointing application connection strings, validating data integrity, re-creating indexes, and tuning query performance for the Azure-managed environment.
Azure SQL provides built-in performance recommendations through the Intelligent Performance dashboard. This phase is where Microsoft Fabric components connect to the newly migrated database for analytics, and where a data governance framework ensures migrated data stays clean, compliant, and well-documented.
Post-migration is also the right time to build data pipelines that feed the migrated database into downstream analytics, reporting, and AI systems. Teams with a data engineering function in place complete this phase significantly faster.
Online vs Offline Migration
The choice between online and offline migration depends on how much downtime your application can tolerate.
|
Factor |
Offline Migration |
Online Migration |
||
|
Downtime |
Hours to days depending on size |
Under 5 minutes for cutover |
||
|
Data sync |
Single snapshot; no ongoing sync |
Continuous replication until cutover |
||
|
Complexity |
Lower one-time copy |
Higher change data capture setup |
||
|
Network |
One-time bulk export/import |
Persistent, reliable connection required |
||
|
Best for |
Dev/test, planned maintenance, <100 GB |
Production, 24/7 apps, >100 GB |
||
|
Source impact |
Minimal single read pass |
Continuous log reading, small I/O overhead |
||
Online migration mode supports continuous sync for databases up to 10 TB without extended downtime windows. For production workloads where every minute of downtime translates to revenue loss, online mode is almost always the right choice.
Common Migration Pitfalls and How to Fix Them?
Database migrations fail for predictable reasons. These are the issues that surface most frequently in enterprise Azure migrations, along with the fixes that prevent them.
|
Pitfall |
Fix |
|
Running migration without an assessment, then discovering the target Azure service does not support features your application depends on like cross-database joins, CLR assemblies, or SQL Agent jobs. |
Always run the DMS assessment or Azure SQL Migration extension assessment first. If the report flags critical incompatibilities, evaluate Azure SQL Managed Instance (which supports 99% of SQL Server features) instead of Azure SQL Database. |
|
Network connectivity issues during online migration cause replication to stall. The source database accumulates hours of unsynced changes, pushing the cutover window out by days. |
Use Azure ExpressRoute or site-to-site VPN with guaranteed bandwidth. Monitor replication lag continuously. Set alerts for lag exceeding 60 seconds for production migrations. |
|
Migrating schema and data but forgetting logins, users, permissions, and database-level security. Applications fail after cutover because service accounts do not exist on the target. |
Export logins separately using sp_help_revlogin or dbatools PowerShell. Create a pre-cutover checklist covering logins, permissions, linked servers, and database mail. Business process automation tools can script these steps into a repeatable runbook, and DevOps automation tools can version-control the entire migration playbook. |
|
Assuming post-migration performance matches on-premises without tuning. Azure-managed databases use different I/O subsystems, and queries optimized for local SSDs may perform differently. |
Run representative workloads on the target before cutover. Use Azure SQL’s Query Performance Insight and Intelligent Tuning to identify slow queries. Adjust vCore count, storage tier, and indexes based on actual Azure metrics. |
|
Treating migration as a one-time event and neglecting post-migration data quality. Without governance, migrated data degrades through inconsistent updates, orphaned records, and undocumented schema changes. |
Implement a data governance framework immediately after migration. Assign data stewards, define quality rules, and automate validation checks. Organizations with master data management in place maintain significantly higher data quality post-migration, especially when integrating MDM with ERP systems. |
Azure DMS vs Other Migration Tools
Microsoft offers several tools that overlap with DMS. Choosing the right one depends on what you are migrating, from where, and at what scale.
|
Tool |
Best For |
Limitations |
|
Azure DMS |
Database-to-database migrations with online sync. SQL Server, MySQL, PostgreSQL, MongoDB. |
Does not migrate VMs, apps, or storage. Oracle requires separate schema conversion. |
|
Azure Migrate |
Full-stack discovery and migration: servers, VMs, databases, web apps. |
Database migration uses DMS under the hood. Discovery is the real value add. |
|
SSMA |
Schema conversion from Oracle, MySQL, SAP ASE, Access, DB2 to SQL Server/Azure SQL. |
Handles schema only does not transfer data at scale. |
|
Azure Data Factory |
ETL/ELT pipelines. 100+ sources. Ongoing data integration. |
Not designed for database migration. No schema migration, no online sync. |
The practical rule: use DMS when you are moving a database to its Azure-managed equivalent and need minimal downtime. Use Azure Migrate for full-environment discovery. Use SSMA for Oracle/SAP schema conversion. Use Data Factory for ongoing data movement.
For organizations managing complex master data environments across multiple databases, the migration strategy often combines DMS for the transfer with Data Factory for ongoing integration. The MDM-to-ERP integration pattern is especially common in enterprises consolidating on Azure.
Pricing: What Azure DMS Actually Costs
DMS pricing has changed over the years, and the current model is simpler than most migration teams expect.
The standard tier of Azure Database Migration Service is free. Microsoft does not charge for the DMS service itself when performing offline migrations. You pay only for the target Azure database resources.
The premium tier, required for online (continuous sync) migrations, is billed per vCore-hour. As of 2026, pricing runs approximately $0.404 per vCore-hour. A typical migration using 4 vCores running for 24 hours costs roughly $38.78 for the DMS component a fraction of total Azure spending.
Network egress charges may apply for cross-cloud sources (AWS, GCP). Azure does not charge for data ingress, so moving data into Azure is free.
Free tier availability: Azure DMS standard tier (offline migrations) costs $0. Premium tier runs ~$0.404 per vCore-hour. Most enterprise migrations complete the DMS portion for under $100 in compute costs.
Frequently Asked Questions
Is Azure Database Migration Service free?
The standard tier is free for offline migrations. The premium tier, required for online migrations with continuous replication, charges per vCore-hour (~$0.404/vCore-hour as of 2026). You still pay separately for target Azure database resources.
What is the Azure equivalent of AWS Database Migration Service?
Azure Database Migration Service is the direct equivalent. Both handle schema conversion and data transfer from on-premises or cross-cloud sources. Both support online and offline modes targeting managed database services.
How long does an Azure database migration take?
Duration depends on size, bandwidth, and mode. A 50 GB SQL Server database on 1 Gbps typically completes initial copy in under 2 hours. Online mode limits cutover to under 5 minutes. Databases over 1 TB may require 12-48 hours for initial copy.
Can I migrate from AWS RDS to Azure?
Yes. DMS supports migrations from AWS RDS for SQL Server, MySQL, and PostgreSQL. Network connectivity must be established via VPN or direct connect. Cross-cloud migrations incur AWS data egress charges; Azure does not charge for data ingress.
What happens if migration fails midway?
DMS supports resumable migrations. Restart from the last checkpoint rather than starting over. Online replication resumes automatically when connectivity is restored. Source databases are never modified, so there is zero risk to production data.
Do I need an Azure landing zone before migrating databases?
For enterprise-scale migrations, yes. An Azure landing zone provides the networking, identity, governance, and security foundation your migrated databases will run on. Migrating without this foundation leads to retroactive rework. For smaller migrations, a well-configured resource group and virtual network may be sufficient.
What should I do with my data after migration?
Connect it to analytics and AI workloads. Microsoft Fabric provides a unified analytics platform that integrates directly with Azure SQL. Build data pipelines to feed migrated data into dashboards, reporting, and enterprise AI implementations without manual intervention.
Conclusion
Azure Database Migration Service plays a focused role in modern cloud adoption by simplifying the movement of databases from on-premises or other cloud environments into Azure. It reduces migration risk through structured phases, supports multiple database engines, and enables minimal-downtime transitions using online replication. However, its success depends on proper assessment, the right migration strategy, and alignment with broader infrastructure components such as landing zones, governance, and data pipelines.
For businesses planning an Azure database migration, Centric helps manage the full journey from assessment and migration planning to execution, optimization, and ongoing support. With the right approach, Azure DMS becomes more than a migration toolit becomes a reliable part of a scalable, cloud-ready data environment.
