What is Azure Database Migration Service?
-
Last updated: 23 September 2026
-
Azure -
Written by
Editorial Team
Azure Database Migration Service (Azure DMS) is Microsoft’s fully managed service for moving databases into Azure with as little downtime as possible. You connect it to a source, such as an on-premises SQL Server, Amazon RDS, MySQL, PostgreSQL, or MongoDB, choose an Azure target, and DMS handles the data movement, progress monitoring, and cutover orchestration.
A lot has changed since most guides on this topic were written. Data Migration Assistant has been retired. The Azure SQL Migration extension went away with Azure Data Studio on February 28, 2026. The classic version of DMS stopped supporting SQL Server scenarios on March 15, 2026. If your migration plan was built around any of those tools, it needs an update.
This guide explains what Azure DMS does today, which source and target combinations it supports, how online and offline migrations differ, where it sits among Microsoft’s other migration tools, what it costs, and a step-by-step process you can follow. It also covers the parts of a database migration that DMS does not handle, because that is usually where projects slip.
Key takeaways
- Azure DMS is now used through the Azure portal, Azure PowerShell, and Azure CLI. The Azure Data Studio route is retired.
- For SQL Server, DMS supports Azure SQL Managed Instance and SQL Server on Azure Virtual Machines both online and offline, and Azure SQL Database offline only.
- DMS also covers MySQL to Azure Database for MySQL flexible server, PostgreSQL to Azure Database for PostgreSQL flexible server (online), and MongoDB to Azure Cosmos DB.
- Assessment now happens before DMS, mainly through SQL Server enabled by Azure Arc or DMS automation with PowerShell and CLI.
- DMS moves databases. Logins, server-level objects, application connection strings, and performance tuning still need their own plan.
In this guide
- What Is Azure Database Migration Service?
- What Was Retired in 2025 and 2026
- Supported Sources and Targets
- Online vs Offline Migration
- Where DMS Fits Among Microsoft’s Migration Tools
- Step-by-Step Migration Process
- What DMS Does Not Handle
- Cost
- Common Mistakes
- DIY or Migration Partner?
- FAQs
What Is Azure Database Migration Service?
Azure Database Migration Service is a managed Azure resource that orchestrates database migrations from a source environment to an Azure data platform. Because it runs as a cloud service rather than a desktop utility, it can run several database migrations at the same time, track each one from a single place, and be scripted so the same process repeats across migration waves. You will also see it called the Azure data migration service or simply Azure DMS. All three names refer to the same product.
How DMS moves your data depends on the target you choose:
- Azure SQL Managed Instance and SQL Server on Azure VMs: DMS performs a physical migration by restoring your SQL Server backups. You place full, differential, and transaction log backups on an SMB network share or in an Azure Blob Storage container, and DMS restores them on the target. Backups taken with the CHECKSUM option are validated automatically during the restore.
- Azure SQL Database: DMS performs a logical migration. It reads rows from the source tables and writes them into the target tables, and you can monitor rows read and rows copied for each table while it runs.
Two details tend to come up in security reviews. First, Microsoft states that DMS does not store customer data. Second, the current version supports private endpoints for connecting to the source and target, so migration traffic does not have to travel over the public internet. When your backups sit on an on-premises file share, a self-hosted integration runtime installed inside your network gives DMS access to those files.
You create and monitor migrations in the Azure portal, or automate them with Azure PowerShell and Azure CLI. DMS also offers a free, optional tracking resource that registers the source SQL Server instance in Azure through the Microsoft.AzureArcData resource provider, which gives you better visibility into migration progress.
What Was Retired in 2025 and 2026, and What Replaced It
If you last looked at Microsoft’s database migration tooling a couple of years ago, three retirements change how you should plan a project today.
| Tool | Status | What to use instead |
|---|---|---|
| Data Migration Assistant (DMA) | Retired July 16, 2025, and no longer available to download | SQL Server enabled by Azure Arc for migration assessments, the SSMS migration component for version upgrades, and DMS PowerShell or CLI for scripted assessments |
| Azure SQL Migration extension for Azure Data Studio | Retired together with Azure Data Studio on February 28, 2026 | Azure DMS in the Azure portal, Azure PowerShell, or Azure CLI, with Azure Arc for assessments |
| Azure DMS (classic), SQL Server scenarios | Retired March 15, 2026 | The current version of Azure DMS |
| Azure DMS (classic), MySQL, PostgreSQL, and MongoDB scenarios | Outside the scope of the March 2026 SQL Server retirement | Check Microsoft’s current guidance for each engine before starting |
The practical effect is that assessment and migration are now separate activities. The portal version of DMS does not run compatibility assessments or SKU recommendations on its own. You assess first, usually with SQL Server enabled by Azure Arc, which refreshes migration assessments automatically on a weekly schedule by default. Then you execute the migration in DMS. Treat any guide that still tells you to download DMA or install the Azure Data Studio extension as out of date. You can confirm the details in Microsoft’s DMS (classic) retirement notice.
Which Migrations Does Azure DMS Support?
Microsoft organizes DMS support by target and by migration mode. This is the current picture from Microsoft’s scenario documentation:
| Source | Azure target | Offline | Online |
|---|---|---|---|
| SQL Server 2008 and later | Azure SQL Managed Instance | Yes (GA) | Yes (GA) |
| SQL Server 2008 and later | SQL Server on Azure VMs | Yes (GA) | Yes (GA) |
| SQL Server 2008 and later | Azure SQL Database | Yes (GA) | No |
| Amazon RDS for SQL Server | Azure SQL Managed Instance, SQL Server on Azure VMs, Azure SQL Database | Yes (GA) | Yes for Managed Instance and Azure VMs (GA) |
| Oracle | Azure SQL targets (through SSMA) | Preview | No |
| MySQL, Amazon RDS for MySQL, Amazon Aurora MySQL, Google Cloud SQL for MySQL, Percona MySQL | Azure Database for MySQL flexible server | Yes (GA) | Yes (GA) |
| PostgreSQL, Amazon RDS for PostgreSQL | Azure Database for PostgreSQL flexible server | No | Yes (GA) |
| MongoDB | Azure Cosmos DB | Yes (GA) | Yes (GA) |
Microsoft adds and revises scenarios over time, and preview scenarios may not be available in every region, so confirm your exact source and target pair on the DMS scenario status page before you commit to a plan.
Moving from Amazon RDS? The database is only half the job. If the application tier also runs on EC2, plan for moving the application servers from AWS in the same wave. Otherwise your application will be talking to a database in another cloud during the transition, which adds latency and outbound data transfer charges.
Online vs Offline Migration: How to Choose
This is the most important decision in a DMS project, because it determines how much downtime your users will see.
- Offline migration: Application downtime starts when the migration starts and lasts until all the data is copied and the application points at Azure. It is simpler, has fewer moving parts, and works well for smaller databases, development and test environments, and systems with a genuine maintenance window.
- Online migration: The source stays live while DMS keeps applying new changes, such as fresh transaction log backups for SQL Server targets. Downtime is limited to the cutover itself: stopping the application, letting the final changes apply, and switching connections to Azure.
Microsoft’s own recommendation is practical: run an offline test migration first to measure how long the copy actually takes. If that downtime fits your window, stay offline. If it does not, switch to online. Remember that DMS does not support online migration to Azure SQL Database, so a large database with a tight downtime budget may push you toward Managed Instance or a SQL Server VM instead.
Answer these questions before you choose a mode:
- How large is the database, and how quickly can you move its backups to Azure over your current connection?
- What is the longest outage the business will accept, including the time needed to test after cutover?
- How write-heavy is the workload during business hours? Busier systems generate more log backups that must be applied before cutover completes.
- Do dependent applications, reports, or integrations need to switch to Azure at the same moment?
Where DMS Fits Among Microsoft’s Migration Tools
When people search for Azure migration services, they usually find a confusing mix of Microsoft products. Each one covers a different layer of a migration, and DMS is the Azure migration service responsible only for moving databases. Here is how the current toolset divides the work:
| Tool | What it does | When to use it |
|---|---|---|
| Azure Migrate | Central hub to discover, assess, and migrate servers, databases, and web apps, and to track progress across tools | Estate-wide discovery, VM lift-and-shift, and planning migration waves |
| SQL Server enabled by Azure Arc | Migration readiness assessments for Azure SQL targets, right-sized recommendations, and projected costs | Assessing a SQL Server estate before running DMS |
| Azure Database Migration Service | Managed data movement and cutover orchestration for supported database pairs | Executing the database migration itself |
| SQL Server Management Studio (migration component) | Assessment and migration for SQL Server version upgrades | Upgrading to a newer SQL Server version on-premises or on Azure VMs |
| SQL Server Migration Assistant (SSMA) | Converts schema and code from Oracle, Db2, MySQL, SAP ASE, and Access to SQL Server | Heterogeneous migrations that need code conversion |
| Azure Data Box | Physical devices for offline bulk data transfer into Azure | Very large datasets where moving data over the network is impractical |
| Storage Migration Service | Migrates Windows Server file servers and their shares | File shares that need to move alongside applications |
Azure Migrate is available at no additional charge, and Microsoft’s DMS FAQ draws a clear boundary between the two services. Azure Migrate focuses on lift-and-shift migrations of VM-based workloads, while DMS is the specialized service for moving databases onto Azure data platforms such as Azure SQL Database and Azure SQL Managed Instance. Most projects use both: Azure Migrate for the servers and DMS for the databases.
Before any tool runs, decide how each workload should move. Your rehost, replatform, or refactor decision determines whether a database lands on a SQL Server VM (closest to what you run today), on Managed Instance (high compatibility with far less administration), or on Azure SQL Database (fully managed, with more feature differences to work through).
How to Migrate a Database With Azure DMS, Step by Step
The steps below reflect how a well-run DMS migration actually unfolds. The first half of the work happens before DMS moves a single row, and that preparation is what separates a quiet cutover weekend from a long one.
-
Discover and Inventory Your Databases
List every SQL Server instance and database in scope with its version, size, compatibility level, and owner. Then map what depends on each one: applications, reports, SSIS packages, SQL Server Agent jobs, linked servers, and any integrations with hardcoded server names. The goal is to know everything that touches a database before you move it. If you want a structured starting point, work through a full pre-migration checklist with your application owners.
-
Assess Readiness and Size the Target
Run a migration assessment through SQL Server enabled by Azure Arc, or through the DMS modules in Azure PowerShell and Azure CLI. The assessment flags blocking issues for each possible Azure SQL target, recommends a right-sized SKU based on performance data, and projects the monthly cost. If the recommendations conflict with what your application team expects, an independent architecture review can settle the question before you provision anything.
-
Choose the Target and Prepare the Azure Environment
Use the assessment to pick between Azure SQL Database, Managed Instance, and SQL Server on Azure VMs. If you are unsure which fits, it helps to understand how Azure SQL Database differs from a traditional SQL Server. Build the target inside a governed environment with networking, identity, and policies already in place. A properly designed landing zone saves you from retrofitting security and network controls after the data has arrived.
-
Fix Blockers and Migrate the Schema
Resolve the issues the assessment raised, such as unsupported features, deprecated syntax, or cross-database dependencies. For Azure SQL Database targets, DMS can migrate the schema before it moves the data. For Managed Instance and SQL Server VM targets, the schema arrives with the restored backups. If you are coming from Oracle or another non-Microsoft engine, SSMA handles schema and code conversion first.
-
Prepare Backups, Storage, and Connectivity
For Managed Instance and SQL Server VM targets, take full and log backups with the CHECKSUM option and place them on an SMB share or in an Azure Blob Storage container. If the share is on-premises, install the self-hosted integration runtime on a machine that can reach it. Confirm network paths, firewall rules, and permissions on both source and target, and use private endpoints where your security policy requires traffic to stay off the public internet.
-
Run the Migration and Monitor It
Create the migration in the Azure portal or launch it with PowerShell or CLI. DMS shows which backup files have been restored or, for Azure SQL Database, how many rows have been read and copied per table. In an online migration, DMS keeps restoring new log backups while the application stays in use, so the target stays close behind the source until you are ready to switch.
-
Cut Over to Azure
Stop writes on the source application, take the final log backup, and start the cutover in DMS. DMS shows any pending backup files that still need to be restored, and the cutover completes once they are applied. Point connection strings at the new target, run smoke tests on critical business functions, and only then reopen the application to users.
-
Validate, Optimize, and Hand Over to Operations
Compare row counts and key business totals between source and target, and check query performance on the workloads that matter most. Update statistics, review indexes, and confirm the database compatibility level you intend to run. Then set up backups, monitoring, alerts, and patching ownership. Many teams bring in ongoing Azure management at this point so the new environment is watched around the clock. Keep the source database read-only for an agreed rollback period before decommissioning it.
What Azure DMS Does Not Handle for You
DMS is very good at moving data reliably. It is not a complete migration project, and the following gaps show up in almost every engagement:
- Logins and server-level objects: Microsoft’s feature comparison lists login migration as unavailable in the portal version of DMS. Logins, SQL Server Agent jobs, linked servers, credentials, and server configuration live outside your user databases, so script and recreate them on the target. Azure SQL Database has no SQL Server Agent, so scheduled jobs need a new home such as elastic jobs or Azure Automation.
- TDE-encrypted databases: The same comparison lists Transparent Data Encryption support as unavailable. Plan certificate handling or an alternative method for encrypted databases early, not on cutover night.
- Assessment: The portal version of DMS does not assess compatibility or recommend SKUs. That work happens beforehand in Azure Arc or through PowerShell and CLI.
- Application changes: Connection strings, firewall rules, authentication (including a move to Microsoft Entra ID), and retry logic for cloud connections all belong to the application team.
- Performance tuning: A database that ran well on dedicated hardware can behave differently on a cloud SKU. Plan time to tune queries and indexes after the move.
- Rollback: DMS moves data forward. Deciding when to roll back, and how, is a business decision you should document before cutover.
How Much Does Azure Database Migration Service Cost?
Microsoft’s published DMS pricing is organized around the classic service. Its Standard tier supports offline migrations with 1, 2, or 4 vCores and is free. Its Premium tier adds online migrations and is billed hourly per vCore, with the 4-vCore Premium tier free for the first 183 days after the service is created. For the current version of DMS, check the Azure pricing page and pricing calculator for your region before you budget.
In practice, the DMS line item is rarely the largest cost. Budget for these as well:
- The target database: Sized from your assessment, and often running in parallel with the source during testing.
- Staging storage: Azure Blob Storage capacity and transactions for backup files.
- Integration runtime host: A server or VM to run the self-hosted integration runtime when backups sit on-premises.
- Connectivity: VPN or ExpressRoute capacity if your current link is too slow, plus outbound transfer fees if the source lives in another cloud.
- People and time: Assessment, remediation, test migrations, and the cutover itself.
Licensing is where you can recover some of that spend. If your SQL Server licenses include Software Assurance, you may be able to bring your existing SQL Server licenses to Azure and pay a reduced rate on eligible vCore-based targets. Factor that in when you compare Managed Instance, Azure SQL Database, and SQL Server VMs, because it can change which option is cheapest.
Common Azure Database Migration Mistakes to Avoid
-
Skipping the Test Migration
A test run is the only reliable way to learn how long the copy takes, which issues appear on the target, and whether your downtime estimate is realistic. Treat the first production-sized test as a rehearsal, with the same people and the same runbook you will use on cutover day.
-
Choosing the Target on Price Alone
Azure SQL Database may look cheapest on paper, but if your application depends on SQL Server Agent, cross-database queries, or CLR, the remediation effort can outweigh the savings. Let the assessment and your feature dependencies drive the choice, then optimize cost.
-
Forgetting the Hidden Dependencies
Reports that query the database directly, ETL jobs, scheduled scripts, and third-party tools with hardcoded server names are easy to miss. Each one becomes an outage if it still points at the old server after cutover.
-
Underestimating Network Throughput
Backup files have to reach Azure before DMS can restore them. Calculate transfer time from your real upload bandwidth, not the advertised speed, and consider seeding large databases early with a full backup so only log backups remain for cutover week.
-
Having No Rollback Plan
Decide in advance what failure looks like, who can call a rollback, and how long the source stays available. A written go or no-go checklist keeps that decision calm at 2 a.m.
-
Decommissioning the Source Too Early
Month-end processing and quarterly reports often surface issues that daily testing misses. Keep the source read-only for a defined period before you shut it down.
Do It Yourself or Work With a Migration Partner?
DMS makes data movement repeatable, and an experienced DBA team can run a straightforward migration on its own. A single SQL Server database moving offline to a SQL Server VM over a weekend is well within reach of most in-house teams.
Outside help pays off when the project looks more like this:
- Dozens of databases that need to move in coordinated waves.
- Downtime tolerance measured in minutes rather than hours.
- Heterogeneous sources, such as Oracle or MySQL, that need schema conversion.
- Compliance requirements that dictate network design, encryption, and audit trails.
- A small IT team that still has to keep production running during the project.
For organizations looking for Azure managed services, Apps4Rent can help plan and execute the migration while your internal team stays focused on production.
Apps4Rent is a Tier 1 Microsoft Cloud Solution Provider with more than 18 years of experience and 24/7 support by phone, chat, and email. If you would rather not run the assessment, cutover, and validation yourself, you can have our Azure team plan and run the move, using the same DMS process described in this guide.
Not sure which Azure SQL target or migration mode fits your databases?
Tell us what you are running today. Our Azure specialists will review your environment, flag the blockers, and outline a migration plan with a realistic downtime estimate before you commit to anything.
Azure Database Migration Service FAQs
-
What is Azure Database Migration Service used for?
Azure Database Migration Service is used to move databases from on-premises servers or other clouds into Azure data platforms. It supports SQL Server to Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VMs, as well as MySQL, PostgreSQL, and MongoDB migrations to their Azure equivalents.
-
Is Azure Database Migration Service free?
Microsoft’s published pricing for the classic service lists the Standard tier, which supports offline migrations, as free. The Premium tier, which adds online migrations, is billed hourly per vCore after 183 free days. You still pay for the target database, storage, and connectivity used during the migration.
-
What is the difference between online and offline migration in Azure DMS?
In an offline migration, application downtime starts when the migration starts. In an online migration, the source stays live while DMS keeps applying changes, so downtime is limited to the final cutover. Microsoft recommends testing offline first and switching to online if the downtime is too long.
-
Can I still use Azure Data Studio to run Azure DMS migrations?
No. Azure Data Studio and its Azure SQL Migration extension were retired on February 28, 2026. You now run DMS migrations through the Azure portal, Azure PowerShell, or Azure CLI, and use SQL Server enabled by Azure Arc for migration assessments.
-
What replaced the Data Migration Assistant?
Microsoft retired the Data Migration Assistant on July 16, 2025. For migrations to Azure SQL, assessments now run through SQL Server enabled by Azure Arc or the DMS modules in PowerShell and CLI. For SQL Server version upgrades, Microsoft points to the migration component in SQL Server Management Studio.
-
What is the difference between Azure Migrate and Azure Database Migration Service?
Azure Migrate is a central hub for discovering, assessing, and migrating servers, databases, and web apps, and it is best known for lift-and-shift VM migrations. Azure Database Migration Service is the specialized service that moves databases onto Azure data platforms. Most projects use Azure Migrate for servers and DMS for databases.
-
Which SQL Server versions can Azure DMS migrate?
Azure DMS supports SQL Server 2008 and later as a source. It also supports Amazon RDS for SQL Server as a source for Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VMs.
-
Does Azure DMS migrate logins and SQL Server Agent jobs?
No. Microsoft’s feature comparison lists login migration as unavailable in the portal version of DMS, and Agent jobs, linked servers, and other server-level objects sit outside the databases DMS moves. Script and recreate them on the target as part of your migration plan.
-
Can Azure DMS migrate Oracle databases?
Oracle to Azure SQL targets is available in preview as an offline migration, using DMS together with SQL Server Migration Assistant (SSMA). SSMA converts the Oracle schema and code first, and DMS then moves the data. Online migration from Oracle is not supported.
-
How long does an Azure database migration take?
It depends on database size, network bandwidth, the migration mode, and how much remediation the assessment uncovers. The data copy can take minutes or days, but with an online migration, user-facing downtime is limited to the cutover. A test migration gives you a reliable estimate.
Final Thoughts
Azure Database Migration Service is now the single, supported path for moving SQL Server and several open-source databases into Azure, and the tooling around it is simpler than it was a few years ago: assess with Azure Arc, migrate with DMS, and automate with PowerShell or CLI when you have more than a handful of databases. The service does its part well. The outcome depends on everything around it: a clear inventory, the right target, a tested runbook, and a plan for what happens after cutover. Get those right, and your database migration becomes a planned maintenance event rather than a leap of faith.
