Azure Database Migration Service, often shortened to DMS, is a managed Azure service that moves databases from a source system to a target in Azure with minimal effort and, when needed, minimal downtime.

The problem it solves

Databases are among the hardest things to move. They are large, they change every second, and almost every other part of the business depends on them. Copying files by hand is slow and risky. A copy taken at noon is already out of date by one o’clock, and a long copy of a busy database can leave the application unavailable for hours or days. Add the need to prove that nothing was lost, and a careless migration becomes a source of real fear.

Azure Database Migration Service takes over the mechanical parts of this work. It moves data in a controlled and monitored way, reports progress for each database, supports continuous synchronization so that downtime can be short, and lets you decide the exact moment to switch. It does not replace planning, but it removes a lot of manual and error-prone effort.

What it supports

The service supports many kinds of sources and targets, including SQL Server, MySQL, PostgreSQL and MongoDB, moving to Azure services such as Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure virtual machines, Azure Database for MySQL, Azure Database for PostgreSQL and Azure Cosmos DB. The exact list of supported paths, and whether each path supports offline, online or both, changes as Microsoft adds features, so always confirm your specific route in the current documentation.

Before choosing a tool, decide what you want from the move, because the goal shapes every later choice.

Common reasons to migrate

Three broad strategies

DMS is one member of a toolkit, and knowing what each tool does prevents confusion about where it fits.

Tooling changes over time

Microsoft has retired or replaced several tools in this area. Older standalone assessment tools and desktop-based migration experiences have been superseded by newer ones, including experiences inside the Azure portal and in Azure Arc. Because tool names and locations shift, this tutorial focuses on the concepts that stay stable, such as assessment, schema work, data movement, cutover and validation, and tells you to confirm the current tool for each step.

Every successful migration follows the same arc, whatever the databases involved.

flowchart LR
    D["1 Discover: find databases and dependencies"] --> A["2 Assess: check compatibility and size the target"]
    A --> C["3 Convert: fix schema and code where needed"]
    C --> M["4 Migrate: move the data"]
    M --> V["5 Validate: test data and application"]
    V --> CU["6 Cut over: switch the application"]
    CU --> O["7 Optimize: tune, secure and retire the old system"]
        

You cannot safely move what you have not fully counted, so the first real work is finding out what exists and how ready it is.

Discovery

Discovery answers basic questions. Which database servers exist? Which versions and editions are they? How big is each database, and how fast is it growing? Which applications use it, who owns it, and what other databases does it talk to? The answers often surprise people, because old systems accumulate hidden connections, such as a reporting job that reads from three different servers or a forgotten application that writes to a shared table.

Dependency mapping

Dependencies decide the order of migration. If an application talks to two databases, moving only one may break it, or make it painfully slow if the databases end up far apart over a network link. Mapping dependencies lets you group databases and applications that must move together into the same wave, so that cutover does not split a working system in half.

What assessment checks

Azure offers several homes for a database, and each trades control against convenience.

flowchart TD
    Q1{"Need full SQL Server feature set or OS access?"} -->|Yes| VM["SQL Server on Azure virtual machines"]
    Q1 -->|No| Q2{"Need instance-level features and easy lift?"}
    Q2 -->|Yes| MI["Azure SQL Managed Instance"]
    Q2 -->|No| Q3{"Single database, modern app, elastic scale?"}
    Q3 -->|Yes| SQLDB["Azure SQL Database"]
    Q3 -->|No| REV["Revisit requirements or consider other engines"]
        

Sizing and service tiers

Each target comes in sizes and tiers that differ in processor power, memory, storage speed and availability features. The assessment’s sizing recommendation is a good starting point, but plan to review it after the workload runs in Azure. The cloud allows you to resize, so it is better to start slightly generous and tune downward than to start too small and suffer slowdowns during cutover week.

The most important choice in the data movement phase is whether the application can stop while data is copied.

Offline migration

In an offline migration, the application stops writing to the source database, the data is copied in one pass, and the application is then pointed at the target. It is simpler and has fewer moving parts, but the downtime lasts as long as the copy takes. For a small or rarely used database, or one that can be taken down during a weekend, this is often perfectly fine.

Online migration

In an online migration, an initial copy is made while the source continues to serve users. The service then keeps applying new changes to the target, so the two stay almost identical. When you are ready, you stop writes briefly, let the last changes flow across and switch. Downtime shrinks to minutes because only the final small gap remains. The price is extra complexity, more preparation and the need to watch the synchronization.

flowchart LR
    subgraph OFF["Offline migration"]
        O1["Stop application"] --> O2["Copy all data"] --> O3["Start application on target"]
    end
    subgraph ON["Online migration"]
        N1["Initial copy while app runs"] --> N2["Continuous change sync"] --> N3["Brief stop, final sync, switch"]
    end
        

A basic picture of the moving parts makes problems much easier to diagnose.

The main components

flowchart LR
    SRC["Source database server"] --> IR["Integration runtime or agent on a machine you control"]
    SRC --> BK["Backup files on a network share or in storage"]
    BK --> STG["Azure storage account"]
    IR --> DMS["Azure Database Migration Service"]
    STG --> DMS
    DMS --> TGT["Target database in Azure"]
    DMS --> MON["Status and progress in the Azure portal"]
        

Two common mechanisms

For SQL Server migrations, one common mechanism uses backups. Full and log backups of the source are placed somewhere the service can read, then restored onto the target in sequence. Online migration keeps restoring new log backups as they arrive. Other routes, such as for MySQL, PostgreSQL and MongoDB, use data-copy and change-capture methods that read the data and changes directly. The mechanism affects what you must prepare, such as backup locations or replication settings on the source.

Managed Instance is a popular destination because it offers near-complete SQL Server compatibility without the burden of managing machines.

Why it is popular

Managed Instance supports many instance-level features that applications rely on, such as cross-database queries, the SQL Agent job scheduler and database mail. This makes it the easiest managed-service target for many existing applications, with minimal code change. Microsoft handles patching, backups and high availability.

How the migration works

Other options for this target

Besides the migration service, Managed Instance offers a feature called the Managed Instance link, which uses a technology similar to availability groups to keep a copy of a database in Azure continuously updated, and allows a very short cutover or even testing a read copy in the cloud first. There is also a log replay approach that can be driven from scripts. These alternatives are worth knowing when you need finer control, or when your scenario is not covered by the migration service route.

When you need complete control, or when the application depends on features no managed service offers, a virtual machine is the safest landing spot.

When to choose it

Virtual machine targets suit applications that need full operating system access, unusual third-party components, features not available in managed services, or a precise version of the software. They are also the quickest route for urgent moves, such as an end-of-support deadline, since they change the least. The cost is that you still manage the machine: patching, backups, high availability design and monitoring remain your job, although Azure provides tools to help.

Migration approach

The migration service can move databases to a SQL Server virtual machine using a backup-based method similar to the one for Managed Instance, in offline or online mode. Backups are restored on the virtual machine, and online mode keeps applying log backups until cutover. Because you control the virtual machine, you can also use traditional methods such as log shipping, backup and restore by hand or replication when they suit your situation.

Azure SQL Database is a fully managed service for individual databases, and it asks the most of the application in return for the least administration.

What is different

Azure SQL Database hosts single databases and elastic pools of databases, with no access to the operating system or to instance-level features. Some capabilities that applications use on a full SQL Server, such as cross-database queries in the traditional way, the SQL Agent scheduler or certain server-level settings, work differently or need alternatives. The assessment tool highlights these differences, and teams often have to change code or move jobs to other services.

Schema first, then data

For this target, migration usually begins by deploying the schema, which means the tables, indexes, views and code, to the new database. Then the data is copied into the existing structure. The migration service can handle the data movement, often in offline mode, and support for online mode depends on the current feature set. Because schema and data are handled as separate steps, it pays to test the schema deployment early, since compatibility problems show up at that stage.

Popular open-source engines have managed Azure services of their own, and migration follows the same principles with different details.

MySQL

MySQL databases can be migrated to Azure Database for MySQL. Offline migration copies the data in one pass, while online migration uses the source’s change log, called the binary log, to keep applying new changes until cutover. Preparation includes enabling the right logging settings on the source, checking version compatibility and making sure users and permissions exist on the target.

PostgreSQL

PostgreSQL databases move to Azure Database for PostgreSQL. Azure provides a migration capability that can copy schema and data, and it supports online approaches that use the database’s logical replication to follow changes. Care is needed with extensions, since the target supports a defined list, and with settings on the source that enable replication of changes.

Document databases have a different shape, but the plan still starts with assessment and ends with careful validation.

MongoDB to Azure Cosmos DB

Azure Cosmos DB offers compatibility with the MongoDB programming interface, so applications can often keep their existing drivers. The migration service can copy collections from a MongoDB source into Cosmos DB, in offline mode and, for some routes, with continuous synchronization. Planning must address how data is spread across partitions, which affects performance and cost, and how throughput is provisioned.

Think about data modeling

In non-relational databases, performance often depends on how data is divided and how queries access it. A design that worked in the old system may be inefficient in the new one if one partition receives most of the traffic. Reviewing the main queries and choosing a sensible partitioning approach before migration prevents expensive surprises later.

When the source and target are different database families, the data is only part of the work, and the logic around it needs translating.

Why conversion is needed

Each database engine has its own data types, functions, procedural language and behavior. A stored procedure written for one engine usually cannot run unchanged on another. Moving from Oracle to PostgreSQL, or from MySQL to SQL Server, means converting the table definitions, the programmed logic and sometimes the queries inside the application.

Conversion tools

Assistant tools exist that read the source, assess how much can be converted automatically, convert what they can, and flag the rest for manual work. Typical tools in this family cover several source engines and produce a report of the effort needed. The automatic part is often the majority, but the remaining manual part usually contains the trickiest business logic and dominates the schedule.

Many stalled migrations are really network problems in disguise.

Reaching Azure from your network

Data has to travel from the source to Azure, and the speed and reliability of that path decides how long the migration takes. Organizations usually choose between a site-to-site virtual private network over the internet and a dedicated private circuit such as Azure ExpressRoute. Dedicated circuits give more predictable bandwidth and lower latency, which matters for large, continuous synchronization, while a virtual private network is quicker to set up for smaller moves.

Firewalls and private endpoints

Both source and target usually sit behind firewalls. You must allow traffic between the migration components and each database on the correct ports, and keep those openings narrow. For targets, private endpoints let you reach Azure services over private addresses, and you can often disable public access entirely once the migration is finished. Name resolution is another common trap, since the migration components must resolve the database names correctly from where they run.

flowchart LR
    OP["On-premises network: source database"] --> FW["Firewall allowing only required ports"]
    FW --> LINK["VPN or ExpressRoute private link"]
    LINK --> VN["Azure virtual network"]
    VN --> PE["Private endpoint to target database"]
    VN --> ST["Staging storage with restricted access"]
        

A migration touches your most sensitive data and holds powerful credentials, so it needs careful protection.

Principles to follow

Protecting data copies

Backup files and intermediate copies are full copies of production data. If they sit in an open storage container or on a shared drive after the migration, they are a data breach waiting to happen. Treat every copy with the same care as the original, record where copies exist and make deleting them a formal step of the plan.

Compliance considerations

Regulated data may be subject to rules about where it is stored and who can handle it. Check that the target region satisfies data residency requirements, that staff and contractors with migration access are authorized and that audit logs capture the activity. In regulated industries, the migration plan often needs approval from security and compliance teams before it starts.

A calm migration is the product of repeated rehearsal, not heroic effort on the night.

The runbook

A runbook is a written, numbered procedure for the cutover, with owners, expected durations, checks and decision points. It should be detailed enough that a competent colleague could follow it at three in the morning. Update it after each rehearsal so it reflects what really worked, including the exact commands, screens and contact numbers.

While data is moving, the migration service reports a state for each database, and reading these states is a daily habit.

States of a database migration

stateDiagram-v2
    [*] --> Queued
    Queued --> InitialCopy
    InitialCopy --> Syncing
    InitialCopy --> Failed
    Syncing --> ReadyForCutover
    Syncing --> Failed
    ReadyForCutover --> CuttingOver
    CuttingOver --> Completed
    CuttingOver --> Failed
    Completed --> [*]
    Failed --> [*]
        

The exact names differ between routes, but the idea is stable. A database waits in a queue, receives its initial copy, and in online mode moves into a continuous sync state. When it has caught up, it shows that it is ready for cutover. After cutover is triggered and finished, it is complete. A failure at any stage shows an error with details that guide the fix.

What to watch

Cutover is the moment of truth: the instant that the new database becomes the real one.

The sequence

sequenceDiagram
    participant T as Team
    participant A as Application
    participant S as Source database
    participant D as Migration service
    participant G as Target database
    T->>A: Stop or pause writes
    A->>S: No more changes arrive
    T->>S: Take final backup or confirm last changes
    S->>D: Last changes delivered
    D->>G: Apply last changes
    T->>D: Complete cutover
    D->>G: Database brought online
    T->>A: Point connections to target
    A->>G: Normal operation resumes
    T->>T: Run validation checks
        

Go or no-go

Before pressing the final button, the team confirms a short checklist: the target has caught up, validation checks are ready, the application change is prepared, the rollback plan is understood, and the right people are present. If any item fails, the decision to stop and postpone is a sign of discipline, not failure. A postponed cutover costs a few hours; a rushed cutover that corrupts data costs far more.

The rollback plan

A rollback plan says how you will return to the old system if the new one misbehaves. Before writes begin on the target, rollback is easy: point the application back at the source. After the target accepts new writes, the two diverge, and rolling back means either losing those changes or copying them back. Decide in advance a point of no return, and for critical systems consider setting up reverse synchronization so a fallback remains possible for a while.

A migration is not finished when the tool says completed; it is finished when you can prove that everything works.

Layers of validation

Establish a baseline first

You cannot say whether performance is good or bad without a record of how the old system behaved. Capture query timings, resource use and batch durations before migration, ideally across a busy period. After migration, compare like with like. Differences can reveal missing indexes, outdated statistics or settings that need adjusting.

A database does not live alone, and several things around it need separate handling.

The hidden extras

Migrating the data and schema does not always carry over everything that makes the system work. Depending on the route, items such as server logins, database-level permissions, scheduled jobs, linked servers, alerts, custom messages, server settings and integration packages may need to be recreated or migrated using separate tools. Some newer experiences can migrate logins, but you should confirm the coverage for your route and always verify afterwards.

The migration is the beginning of life in the new home, and a few weeks of care make it a good one.

Performance tuning

A freshly migrated database may need housekeeping. Statistics that guide the query planner may be outdated and should be refreshed. Indexes may need review, since the new hardware and storage characteristics differ. If the engine version changed, some queries may behave differently under new optimizer rules, and built-in query history tools can help find regressions and fix them. Compare against your baseline and tune where the numbers have worsened.

Right-sizing

Initial sizing is a guess based on assessment data. After a few weeks of real usage, review actual resource use and adjust the tier, scaling down where capacity is idle and up where it is stretched. The cloud makes resizing easy, so continuous adjustment is normal practice.

Security and protection

The price of a migration includes more than the price of the migration service itself.

Cost drivers

Pricing of the migration service itself differs by route and has changed over time, with some paths available at no extra charge and others billed by usage, so check the current pricing page for your scenario. The larger costs are usually the target environment, the people doing the work, and the period when both old and new systems run side by side. A long, drawn-out migration therefore costs more than a quick, well-rehearsed one.

Licensing benefits

Organizations that already own licenses for database software with active software assurance may be able to use them in Azure through the Azure Hybrid Benefit, which can reduce the compute cost of the target significantly. Reserved capacity, which means committing to a level of usage for a year or more, gives further discounts for stable workloads. Extended security updates for older versions are another factor, since moving to Azure can provide them for products that have reached end of support. Always confirm the current terms with Microsoft or your reseller.

Moving hundreds of databases calls for a repeatable process, not a series of one-off projects.

Wave planning

A wave is a group of databases and applications migrated together. Early waves contain small, low-risk, low-dependency systems, so the team learns the process and fixes the playbook. Later waves handle larger and more critical systems with confidence. Grouping by dependency, business owner, technology and acceptable downtime keeps each wave coherent and manageable.

flowchart LR
    W0["Wave 0: pilot with low-risk databases"] --> W1["Wave 1: similar small systems, refine playbook"]
    W1 --> W2["Wave 2: medium systems with moderate dependencies"]
    W2 --> W3["Wave 3: critical systems with online migration"]
    W3 --> W4["Wave 4: special cases and engine changes"]
        

The migration factory

At scale, organizations build a factory: a standard process, shared tooling, templates for networks and targets, automated checks and a dedicated team. Each database passes through the same stations of assessment, preparation, migration, validation and handover, and lessons from each wave improve the next. Automation of repeated tasks, such as target creation and validation reports, saves enormous time.

Teams that migrate smoothly share habits, and teams that struggle share traps.

Patterns worth adopting

Traps to avoid

A short checklist, followed by examples of the ideas working together.

Real-world scenarios

sequenceDiagram
    participant PM as Project team
    participant AS as Assessment tools
    participant DM as Migration service
    participant APP as Application owners
    participant OPS as Operations
    PM->>AS: Inventory and assess databases
    AS-->>PM: Readiness report and sizing
    PM->>DM: Rehearsal migration
    DM-->>PM: Timings and issues
    PM->>APP: Test application on rehearsal target
    APP-->>PM: Sign-off or fixes
    PM->>DM: Production migration and cutover
    DM-->>OPS: Database online in Azure
    OPS->>PM: Hypercare, tuning and decommissioning
        

It is a managed Azure service that moves databases from a source system to Azure targets, offering offline and, for supported routes, online migration with continuous synchronization to keep downtime short.

Offline migration stops the application while data is copied, so downtime lasts as long as the copy. Online migration copies data while the application runs and keeps applying changes, so downtime is limited to a short final cutover.

The main choices are SQL Server on Azure virtual machines, Azure SQL Managed Instance and Azure SQL Database. They trade off compatibility and control against the amount of administration you hand over to Azure.

It depends on the route and tool. Some experiences can migrate logins, but jobs, linked servers and other server-level items often need separate handling. Always inventory them and verify after migration.

Yes, it is strongly recommended. Assessment finds compatibility problems, recommends a target size and estimates cost, and avoids discovering blockers during the cutover.

It depends on data size, network throughput, how busy the source is and the route used. Measure throughput with a test and run a rehearsal to get a realistic estimate rather than relying on theoretical numbers.

Before writes begin on the target, you can usually point the application back to the source. Define the point of no return in advance, keep the source intact for a fallback period and consider reverse synchronization for critical systems.

Yes, but it needs schema and code conversion in addition to data movement. Conversion tools handle much of the work automatically, while complex logic usually needs manual rewriting and thorough testing.

It can be, if you use encrypted connections, least-privilege accounts, private connectivity, protected credentials and secure staging storage, and remove all temporary access and copies afterwards.

Charges for the service itself depend on the route and have changed over time, so check current pricing. The larger costs are usually the target environment, supporting infrastructure and the period of running old and new systems together.

Begin with an inventory and assessment, pick a small low-risk database as a pilot, rehearse the migration end to end, write a runbook and learn from the pilot before tackling critical systems.

Azure Database Migration Service helps move databases to Azure with controlled, monitored data transfer, in offline or online modes depending on the route. Successful migrations begin long before the tool runs, with discovery, dependency mapping and assessment, and they end long after, with validation, tuning, security cleanup and decommissioning. The right target depends on how much compatibility, control and administration you need, and the right method depends on how much downtime the business can accept. Rehearsal, clear runbooks, careful networking, attention to items outside the database and a tested fallback turn migration from a gamble into a routine. Tools and features in this area change often, so confirm the current guidance for your exact source and target before you start.