Before the tool, we need to understand the job it is built to do.

A migration is a change of home for living data

A database migration means moving a database from one place to another. The old place is called the source, and the new place is called the target. The source might be a server in your own data center, a virtual machine in another cloud, or an older database product. The target is usually a managed database on Azure, such as Azure SQL Database, Azure SQL Managed Instance, Azure Database for PostgreSQL or Azure Database for MySQL. “Managed” means Microsoft operates the servers, patches the software, handles backups and monitors the health, so your team spends less time on plumbing.

Organizations migrate for many reasons. Hardware is old and expensive to renew. A data center contract is ending. Licenses are costly. The business wants elastic capacity, built-in high availability, better security tooling or access to modern analytics and AI services. Sometimes the reason is a merger, and sometimes it is simply a goal of leaving the burden of running servers.

The three big risks

Every migration fights three enemies. The first is data loss or corruption: something is missed or damaged on the way. The second is downtime: the application is unavailable for longer than the business can tolerate. The third is surprise: the application behaves differently on the new platform because of version differences, unsupported features or changed performance. A good migration plan is mostly a plan to defeat these three risks one by one.

A managed service that moves data and, in some cases, keeps the target in step with a live source.

Azure Database Migration Service is a managed Azure offering designed to simplify, guide and automate the movement of databases to Azure. The word “managed” matters: you do not build your own copying machinery. You describe the source, the target and the databases to move, and the service does the heavy lifting, reports progress, and tells you when it is ready for the final switch.

Its central promise is minimal downtime where the scenario allows it. For some source and target combinations the service can perform an online migration, meaning the target is kept continuously synchronized with the live source while users keep working, and the actual downtime shrinks to the short window needed to switch over. For others, only an offline migration is available, where the application must stop writing during the copy.

A moving landscape: check the current status

Microsoft has offered several experiences under the migration umbrella over the years. There was an original service experience, often called the classic experience, built around creating a service instance in a chosen pricing tier and then creating projects and activities inside it. Newer guided experiences were introduced for particular targets, including a portal-based flow and tooling that used a helper component called a self-hosted integration runtime. For some targets, such as Azure Database for PostgreSQL, a migration capability is now built right into the target service itself. Parts of the older tooling have been announced for retirement and replaced by newer paths.

What DMS is not

DMS is not a magic converter for any database to any other. It is not a full application modernization tool. It does not rewrite your application’s queries or stored logic for a different database engine; for that, separate assessment and conversion tools exist. It is not a permanent replication product for ongoing, long-term data synchronization between systems; it is built for a migration project with a beginning and an end.

Every migration is a pair: where from, and where to. The pair decides what is possible.

The most common source for Azure migration projects is Microsoft SQL Server, because so many organizations run it. Its common targets are three different Azure choices, and picking among them is the first big decision.

Homogeneous versus heterogeneous migrations

A homogeneous migration moves between the same database family, for example SQL Server to Azure SQL. The data types, language and behaviors are largely the same, so the work is mostly copying and compatibility checking. A heterogeneous migration moves between different families, for example Oracle to PostgreSQL. Here the table structures, data types, stored programs and functions all need translation. Heterogeneous projects are typically longer, riskier and need far more testing.

The most important choice for the business is how long the application can be unavailable.

Offline migration

In an offline migration, the source database stops receiving changes, the data is copied to the target, and then the application is pointed at the new database. Downtime lasts for the whole copy and the switch. For a small database this may be minutes. For a very large one it may be many hours. The big advantage is simplicity: there is one moment of copying, a clear starting state, and fewer moving parts that can fail.

Online migration

In an online migration, the service first makes an initial copy of the data while the source continues to work normally. It then keeps applying new changes from the source to the target, so that the two stay almost identical. When you are ready, you pause writes to the source briefly, let the last changes flow across, and switch the application. Downtime is reduced to a short cutover window, often just minutes. The price is more complexity, more prerequisites, a need for steady network connectivity, and the requirement that the source supports the change-capture mechanism the service uses.

sequenceDiagram
  participant App as Application
  participant Src as Source database
  participant DMS as Migration service
  participant Tgt as Target database
  Note over App,Tgt: Phase 1 - Initial copy while users keep working
  App->>Src: Reads and writes continue
  DMS->>Src: Read full data
  DMS->>Tgt: Load full data
  Note over App,Tgt: Phase 2 - Continuous sync of changes
  App->>Src: New changes arrive
  DMS->>Src: Capture changes
  DMS->>Tgt: Apply changes
  Note over App,Tgt: Phase 3 - Cutover
  App->>Src: Stop writes briefly
  DMS->>Tgt: Apply last changes
  App->>Tgt: Switch connection to target
        

Successful teams follow a repeatable path rather than improvising.

flowchart LR
  A["1. Discover and assess"] --> B["2. Convert schema and fix issues"]
  B --> C["3. Migrate data"]
  C --> D["4. Cutover"]
  D --> E["5. Validate and optimize"]
  E -.->|lessons learned| A
        

You cannot move what you have not found, and you cannot size what you have not measured.

Assessment answers four questions. What databases exist? Are they compatible with the target? What size and performance level does the target need? What is the best target type? Microsoft provides tools for these steps, and a migration project typically uses several of them together.

What a good assessment reports

Look for features the target does not support, behaviors that changed between versions, deprecated syntax, use of components such as the common language runtime, cross-database queries, linked servers to other systems, scheduled jobs, and special security configurations. Each finding should have a decision beside it: fix, replace, accept or choose a different target.

Collect performance data over a full business cycle

Sizing from a single quiet afternoon is a classic mistake. A database busy at month end looks calm in mid-month. Collect usage data over a period that includes your busiest times, such as closing days, sale events and batch windows, and size the target for the peaks plus a safety margin.

The target decision shapes cost, effort and future flexibility.

flowchart TD
  A["Start: SQL Server workload"] --> B{"Needs instance-level features such as agent jobs or cross-database queries?"}
  B -->|Yes| C{"Needs operating system access or unsupported features?"}
  C -->|Yes| D["SQL Server on Azure Virtual Machines"]
  C -->|No| E["Azure SQL Managed Instance"]
  B -->|No| F{"Single application database with modern design?"}
  F -->|Yes| G["Azure SQL Database"]
  F -->|No| E
        

What actually sits between your source and your target?

flowchart LR
  S["Source database"] --> R["Migration runtime or service node"]
  R --> T["Target database"]
  S -.->|backup files| ST["Azure Storage or network share"]
  ST -.->|restore| T
  P["Azure portal and control plane"] --> R
  R --> M["Azure Monitor"]
        

Two data paths

It helps to know that migrations to SQL Server-family targets follow one of two broad data paths. In the logical path, the service reads rows and writes them to the target, table by table, and for online mode reads changes using a change-capture mechanism. In the backup and restore path, a full backup of the source is restored on the target, followed, for online mode, by a series of smaller log backups that are continuously restored until cutover. Managed Instance and virtual machine targets commonly use the backup path because it preserves the database exactly, including its internal structures.

Simple on the surface, with several careful steps underneath.

Duration is a function of size, bandwidth and parallelism

A rough estimate for offline duration is data size divided by effective throughput, plus time for rebuilding indexes and validation. Effective throughput is limited by whichever is slowest: the source read speed, the network link, the migration runtime, or the target’s ability to accept writes. This is why a rehearsal that measures real throughput is far more trustworthy than a calculation on paper.

The heart of minimal downtime is keeping a copy continuously up to date.

Stage one: the initial load

The service takes a consistent starting point and copies the data to the target while the source stays in use. For a backup-based path, this is a restore of a full backup. For a logical path, it is a table-by-table load.

Stage two: change synchronization

While the initial load runs, the source continues to change. The service must therefore capture those changes and apply them. In the backup path, changes arrive as transaction log backups: periodic files that record everything that happened since the last backup. Each one is picked up and restored on the target in order. In the logical path, a change-capture feature on the source records inserts, updates and deletes, and the service reads those records and replays them on the target. Both approaches keep the lag small, and you can watch it shrink as the service catches up.

Stage three: ready for cutover

When the lag is tiny and stable, the migration reaches a state where cutover can be requested. Until you trigger it, the service keeps syncing, which gives you time to test the target, run reports against it, and prepare the application in calm conditions.

flowchart TD
  A["Initial load running"] --> B["Initial load complete"]
  B --> C["Applying changes, lag shrinking"]
  C --> D["In sync, ready for cutover"]
  D --> E["Stop writes at source"]
  E --> F["Apply final changes"]
  F --> G["Complete cutover"]
  G --> H["Application uses target"]
        

Why a log chain matters

In the backup path, log backups form a chain. If one file in the middle is missing or taken out of order by another backup tool, the chain breaks and the target cannot continue. For this reason, during an online migration the source must not have another process taking competing log backups or truncating logs in a way that breaks the sequence. Coordinate with the team that runs the regular backup jobs.

Source load during synchronization

Change capture and log backups add some work for the source. On a source that is already close to its limits, this extra load can hurt users. Assess headroom before an online migration, and schedule the heaviest initial copy for quieter hours where possible.

Most failed migrations fail because two machines could not talk to each other.

The migration runtime must reach both source and target. If the source is in your own data center, you need a private connection between it and Azure. The usual options are a site-to-site virtual private network, which creates an encrypted tunnel over the internet, or ExpressRoute, a dedicated private line from your network to Azure with more predictable bandwidth and latency. For large or long-running migrations, dedicated connectivity is strongly preferred.

Firewalls, ports and name resolution

Source firewalls must allow the migration runtime to connect on the database port. Target firewalls must allow the runtime as well. If you use private endpoints, name resolution must return the private address, which usually requires correct private DNS zones. A very common symptom is “the connection times out” because a firewall rule, a missing route, or a DNS entry pointing to the wrong address blocks the path. Test connectivity from the actual machine that will run the migration, not from your laptop.

Bandwidth planning

Divide the data size by the realistic bandwidth you can dedicate, and then add safety. If a database is large and the link is modest, the initial copy might take days, and an online migration must then also keep up with the daily volume of change. A migration cannot catch up if the link carries less data per hour than the source produces in changes. Check both numbers before choosing a method.

A migration touches your most sensitive data, so protect it at every step.

Least privilege

The accounts used by the migration need enough permission to read the source and write the target, and no more. Use dedicated migration accounts, not personal administrator accounts, and remove or disable them after the project. Document exactly which permissions were granted and why, so that auditors and security teams can review them.

Encryption in transit and at rest

Connections should use encrypted transport. Backup files placed in storage should be protected with access controls, and storage accounts used for migration should restrict access to the specific runtime or identity. Azure targets encrypt data at rest by default, and organizations with stricter requirements can use their own encryption keys. Check that the migration does not copy sensitive data into places with weaker protection, such as a shared folder that many people can read.

Sensitive data and test copies

Rehearsals use real-shaped data, which may contain personal information. If a rehearsal uses a copy of production data, treat the rehearsal environment with production-level protection, or mask the sensitive columns before the copy. This is a frequent compliance gap in otherwise careful projects.

A plan turns hope into a schedule.

The cutover runbook

A good runbook lists who announces the start, who stops application writes, who confirms the migration lag is zero, who triggers the cutover, who updates connection settings, who runs smoke tests, and who decides about rollback. It lists exact times, expected durations and the evidence required at each step. When pressure is high, nobody should have to invent a decision.

The control-plane flow looks similar across most experiences.

The moment of truth, and the checks that prove the move worked.

The cutover sequence

The sequence is predictable. Announce the maintenance window. Stop the application or put it into read-only mode. Confirm that no active writes remain at the source. Let the service apply any final changes so that the lag reaches zero. Complete the cutover in the service. Update the application connection settings or the name resolution. Start the application. Run smoke tests. Declare success or roll back based on the agreed criteria.

flowchart LR
  A["Announce window"] --> B["Stop writes"]
  B --> C["Final sync, lag zero"]
  C --> D["Complete cutover"]
  D --> E["Switch connections"]
  E --> F["Smoke tests"]
  F --> G{"Pass?"}
  G -->|Yes| H["Go live"]
  G -->|No| I["Rollback to source"]
        

What to validate

Keep the source safe for a while

After cutover, do not delete the source immediately. Keep it intact, and ideally read-only, for an agreed period. If a serious problem appears in the first days, the source is your fallback. If you made writes on the target after cutover, a rollback requires a plan to carry those writes back, so decide that plan in advance, even if you hope never to use it.

The data is only part of what an application depends on.

A database does not live alone. Around it sit server-level objects that belong to the instance rather than to the database. Depending on the path and the target, many of these are not carried automatically, and you need to plan how to recreate them.

Speed matters twice: how fast the data moves, and how fast the new system runs.

Speeding up the migration itself

Performance after the move

Even a perfect copy can run differently on the new platform. Statistics may be stale, query plans may differ because of version changes, and the sizing may be a little off. Update statistics, rebuild fragmented indexes where needed, and compare against the pre-migration baseline. Query performance features of the target can help you detect regressions and, in some cases, automatically revert to a better plan. Plan a tuning period after cutover rather than assuming day-one perfection.

When something stalls, a calm routine beats panic.

What to watch

Common problems and their usual causes

DMS is one road. Sometimes another road fits better.

A migration has its own cost, and so does the destination.

Cost shows up in three places. First, the migration itself: the tooling or service tier used while the migration runs, the runtime machine, network charges, temporary storage and extra target capacity during the load. Second, the people: assessment, testing, application changes and weekend cutovers are usually the largest cost of all. Third, the destination: the monthly cost of the target service for years afterward.

What experienced teams do, and what they learned not to do.

Patterns worth adopting

Anti-patterns to avoid

A last review before any production move.

Realistic situations show how the ideas combine.

Short answers to common beginner questions.

No. It is a migration tool and orchestration service. It moves data from a source database to a target database, and it is not meant to be where your data lives afterwards.

Offline stops changes at the source during the copy, so downtime lasts for the whole migration. Online copies the data while the source keeps working and then keeps applying changes, so downtime is limited to a short cutover window.

Not truly. Online migration reduces downtime to minutes, but writes must pause briefly during cutover, and the application must be redirected to the target.

Engine conversion is handled by separate assessment and conversion tools. The migration service focuses on moving data and, for same-family paths, databases as a whole. Always check what your specific path includes.

Use assessment tools to find compatibility issues and recommend a target size, such as Azure Migrate and the Data Migration Assistant for SQL Server sources. For other engines, use the conversion tool suited to that engine.

Choose Azure SQL Database for a single, modern application database, Managed Instance when you need broad instance-level compatibility with minimal change, and SQL Server on a virtual machine when you need operating system access or features the managed options do not support.

It depends on data size, network bandwidth, source and target performance, and the method. The reliable way to know is a rehearsal that measures real throughput on realistic data.

Often not. These live at the server level and usually need separate handling. Inventory them during assessment and test them during rehearsal.

The source is untouched by the copy, so it remains your safe fallback. Investigate the error, fix the cause, and retry or restart the affected database. Keep the source available until the target is fully validated.

For anything beyond small tests, yes, it is strongly recommended. A VPN works for modest sizes and a dedicated private line is better for large or long-running migrations.

It depends on your source, target and version. Microsoft has introduced newer experiences and retired some older ones, and some targets now include their own migration features. Check the current official guidance for your exact pair before committing, and use the concepts in this guide to judge any option.

Only after validation passes, the business signs off, and a stabilization period has ended. Keep it read-only during that period, and delete it with formal approval and secure disposal of any backup files.

Skipping assessment and rehearsal. Hidden dependencies, unsupported features and connectivity issues are cheap to find early and very expensive to find during cutover.

Azure Database Migration Service exists to take the anxiety out of moving databases to Azure. It helps you copy data safely, track progress, and, where the scenario supports it, keep the target in step with a live source so that downtime shrinks to a short cutover window. But the tool is only one part of a journey that begins with assessment, includes conversion and fixes, and ends with validation, tuning and a careful retirement of the source. The teams that succeed treat migration as a project with stages, owners, rehearsals and a rollback plan. They also stay honest about the moving parts of Microsoft’s tooling and check current documentation before they commit. Master the ideas in this guide, and you can handle any specific experience the portal shows you, today or in the future.