A managed Azure service that helps you move databases from where they live today into Azure database services, with limited downtime and clear progress tracking.

Starting with the word “database”

A database is an organized store of information that applications read and change. A shop’s website uses a database to remember products, customers, and orders. A database engine is the software that manages it, for example SQL Server, MySQL, PostgreSQL, Oracle, or MongoDB. Each engine has its own rules, features, and file formats, a bit like different brands of filing cabinet.

What is a migration?

A migration is the planned move of something from one place to another. A database migration moves the data, the structure of that data (tables, columns, relationships), and often the logic inside the database (stored procedures, jobs, users) from a source to a target. The source might be a server in your own office, a data center, or another cloud. The target is an Azure database service.

What the service does

Azure Database Migration Service, often shortened to DMS, is a managed Microsoft service that performs the heavy lifting of copying databases into Azure. “Managed” means Microsoft operates the underlying machinery, and you configure and monitor the migration instead of building your own copy tools. It is designed to:

• Connect to a source database and a target Azure database.
• Copy the data in an orderly, trackable way.
• Support moves that need a planned outage (offline) and moves that keep the old database running while changes are continuously copied (online).
• Report progress, errors, and completion so you can decide when to switch over.

Understanding the difficulties explains why a dedicated service exists.

The data is alive

Moving files is easy when nobody is using them. A live database is different: customers place orders every second. If you copy it at noon and switch at midnight, you miss everything that happened in between. The core challenge is moving something that keeps changing while you move it.

Size and time

A small database copies in minutes. A database of several terabytes may need many hours or days, even on a fast connection. The longer a copy takes, the more changes pile up behind it.

Differences between engines

If the source and target are the same kind of engine, such as one SQL Server to another SQL Server, the move is called a homogeneous migration. It is usually simpler. If they are different, such as Oracle to PostgreSQL, it is a heterogeneous migration. Data types, functions, stored code, and behavior can differ, so the structure and code must be converted and tested, not only copied.

The hidden connections

Databases rarely stand alone. Applications connect to them with connection strings. Reports read from them. Scheduled jobs run inside them. Other databases link to them. Forgetting one of these connections causes the classic Monday morning surprise: “The new database is perfect, but the finance report cannot find it.”

The pressure of downtime

Businesses want to move without stopping. Every minute of outage may mean lost sales or unhappy users. This pushes teams toward online migration, which is more complex but keeps the interruption short.

The biggest decision in any migration is how much downtime the business can accept.

Offline migration

In an offline migration, the source database stops accepting changes at a chosen time. The data is copied to the target. When the copy is verified, applications are pointed to the new database. Downtime lasts from the moment you stop the source until applications run on the target, which can range from minutes to many hours depending on size.

• Good for: smaller databases, systems with a natural quiet window such as a weekend, and teams that want simplicity.
• Trade-off: the application is unavailable during the copy.

Online migration

In an online migration, the source database keeps running. The service first copies the existing data (the initial load), and then continuously captures new changes from the source and applies them to the target (change synchronization, sometimes called continuous sync or replication). When the target has nearly caught up, you schedule a short cutover: stop writes at the source, let the final changes drain, and switch applications.

• Good for: large or busy systems that cannot afford a long outage.
• Trade-off: more setup, stricter source requirements (often logging must be configured so changes can be read), more things to monitor.

flowchart TD
    subgraph OFF["Offline migration"]
      O1["Stop writes on source"] --> O2["Copy all data"]
      O2 --> O3["Validate target"]
      O3 --> O4["Point applications to target"]
    end
    subgraph ON["Online migration"]
      N1["Source keeps running"] --> N2["Initial load of existing data"]
      N2 --> N3["Continuous sync of new changes"]
      N3 --> N4["Short cutover window"]
      N4 --> N5["Point applications to target"]
    end
    

DMS is one tool in a toolbox. Knowing the others tells you where it fits.

Typical sources

Commonly discussed sources include SQL Server, MySQL, PostgreSQL, MongoDB, and Oracle, running on-premises, on virtual machines, or in other clouds. The exact list of supported source versions and combinations depends on the migration path, so always check current documentation.

Typical Azure targets

The helpers around DMS

flowchart LR
    D["Discover estate with Azure Migrate"] --> A["Assess compatibility and sizing"]
    A --> C["Convert schema and code if engines differ"]
    C --> M["Move data with Database Migration Service"]
    M --> V["Validate"]
    V --> X["Cut over and operate"]
    

The moving parts that sit between your old database and your new one.

The core pieces

Two broad ways to move SQL Server data

For SQL Server sources, two broad approaches exist. A backup-and-restore approach takes database backup files, places them where Azure can read them, and restores them into the target. For online moves, further backup files holding recent changes are applied continuously until cutover. A logical data copy approach reads the tables and rows from the source and writes them into the target. Backup-based moves are typically fast and keep the database very close to the original. Logical copy approaches are more flexible when the target or engine differs.

flowchart TD
    SRC["Source database on premises or other cloud"] --> RT["Helper runtime inside your network"]
    RT --> DMS["Azure Database Migration Service"]
    SRC -->|"backup files"| ST["Azure storage account"]
    ST --> DMS
    DMS --> TGT["Target Azure database service"]
    DMS --> MON["Status and monitoring in portal"]
    

What runs where

• Inside your network: the source database and the helper runtime that reads from it.
• In Azure: the migration service, staging storage, and the target database.
• On the path between: your network link to Azure, such as a VPN or a private line.

How the pieces cooperate inside a job

When you start a migration, the service first checks that it can reach the source and the target and that the accounts have the needed permissions. These checks are like a pilot’s pre-flight list: they catch easy problems before any data moves. Next, the service builds a plan of what to move, such as which databases, which tables, or which backup files, and in which order. Work is then split into units so several can run at the same time. Each unit reports its own status, so a failure in one table does not hide the success of the others. When all units finish, the service performs final steps, such as confirming that every unit completed, and marks the job ready for cutover or completed.

Because each unit is tracked separately, you can often fix and retry a single failed table without starting over. This is one of the practical reasons to use a managed service instead of a one-off script: progress is recorded, repeatable, and visible to the whole team instead of living in one person’s terminal window.

An hour of assessment can save a week of rework.

What an assessment checks

An assessment is an automated review of your source database against the chosen target. It looks for features the target does not support, behavior that changes between versions, and settings that need attention. It then produces a readiness report and often recommends a target size and service tier based on observed usage.

Choosing the right target from the assessment

If the database uses many server-level features, such as cross-database queries, agent jobs, or linked servers, a managed instance or a virtual machine target may fit better than a single database. If it is a self-contained application database, a single database may be simplest and cheapest. Assessment results turn this from a guess into an evidence-based choice.

Collect real performance data

Sizing from a quiet afternoon leads to a target that struggles on payday. Collect performance data across a representative period, including month-end peaks. This is like measuring how much luggage a family has after a holiday season, not after a week when they were away.

Assessing the people and the process

Assessment is not only about software. Ask who owns each database, who uses it, and who can approve downtime. Find out which teams must change connection settings, which vendors support applications that cannot be changed easily, and whether any application is so old that it only works with an old database driver. Some older applications cannot talk to newer database versions without an update, and this surprise can block an otherwise perfect plan. Add a column to your inventory for “application readiness” and treat it as seriously as database readiness.

Finally, estimate the effort honestly. A typical project spends only a small portion of its time on the actual data transfer. Most of the time is spent on discovery, fixing compatibility issues, networking approvals, testing, and communication. Teams that plan only for the copy are the ones that run out of schedule.

Data is only half of a database. The structure and logic must arrive intact too.

What is the schema?

The schema is the blueprint of a database: its tables, columns and their types, keys that identify rows, relationships between tables, indexes that speed up searches, and rules that keep data valid. If you move data without the blueprint, there is nowhere to put it.

Beyond tables: the logic inside

Many databases contain code. Stored procedures are named programs saved in the database. Triggers run automatically when data changes. Views are saved queries that look like tables. Functions compute values. Jobs run on a schedule. Users and permissions control who can do what. For same-engine moves, most of this travels with the database. For different-engine moves, it must be converted line by line, tested, and sometimes rewritten.

Schema first, data second

A reliable pattern, especially for logical copies, is to deploy the schema to the target first, review and adjust it, and only then load data. Some tools migrate the schema as a separate step so you can check it before a single row moves. This also allows you to create indexes and constraints at the best moment: loading data into tables with fewer indexes is faster, and indexes can be added afterward.

Follow a simple offline move from the first meeting to the final switch.

sequenceDiagram
    participant B as Business owner
    participant T as Migration team
    participant S as Source database
    participant M as Migration service
    participant G as Target database
    participant A as Applications
    B->>T: Approve maintenance window
    T->>S: Final backup and stop writes
    T->>M: Start migration job
    M->>S: Read data
    M->>G: Write data
    M-->>T: Progress and completion status
    T->>G: Validate counts and sample data
    T->>A: Update connection settings
    A->>G: Normal operation resumes
    T-->>B: Report success
    

Before the window

• Prepare the target: create the target database service, size it, set networking, and deploy the schema.
• Prepare connectivity: make sure the service can reach both source and target, and test using a small trial database.
• Rehearse: run the complete migration on a copy, time each step, and write down what you learned.
• Communicate: tell users when the outage will occur and how long it should last.

During the window

After the window

Keep the source database untouched but offline for an agreed period, such as days or weeks, as insurance. Watch performance closely for the first few busy days. Only after the business confirms everything is correct should the old system be retired.

How a near-zero-downtime move works, and why the cutover is the most delicate moment.

sequenceDiagram
    participant A as Applications
    participant S as Source database
    participant M as Migration service
    participant G as Target database
    participant T as Migration team
    M->>S: Read existing data
    M->>G: Initial load
    A->>S: Normal reads and writes continue
    M->>S: Capture new changes
    M->>G: Apply changes continuously
    M-->>T: Lag is near zero
    T->>A: Pause writes at cutover time
    M->>G: Apply last pending changes
    T->>G: Final validation
    T->>A: Switch to target
    A->>G: New reads and writes
    

Phase one: initial load

The service copies the existing data while the application continues to run. This phase may take a long time for large databases. During it, the source records every change that happens, so nothing is lost.

Phase two: catching up and staying in sync

Once the initial load completes, the service applies the backlog of changes that accumulated during the copy. Then it keeps applying new changes as they arrive. The delay between a change at the source and its arrival at the target is called lag. A healthy migration shows small, steady lag.

Phase three: testing without hurry

Because the source still serves production, you can take your time to test the target. Run read-only queries, compare results, test reports, and check performance, as long as you do not write to the target in ways that conflict with the sync. This is the great advantage of online migration: confidence before the switch.

Phase four: cutover

Cutover is the switch from old to new. A careful cutover has these steps.

1. Announce the brief interruption.
2. Stop writes to the source by pausing applications or setting the database to read-only.
3. Wait for lag to reach zero, so every last change has arrived at the target.
4. Complete the migration in the service, which stops synchronization and makes the target the standalone copy.
5. Validate quickly with a prepared set of checks.
6. Redirect applications to the target.
7. Monitor the first minutes and hours closely.

What can go wrong during synchronization

Several things can disturb a synchronized migration, and knowing them in advance makes them easier to handle. If the source runs a large batch job, such as a nightly import of millions of rows, the stream of changes suddenly becomes much bigger and lag grows. If the target is too small, it cannot apply changes as fast as they arrive. If the network link is shared with other traffic, the flow slows at busy times. If someone changes the structure of a table at the source while synchronization is running, for example by adding a column, the target may not know how to apply new changes until the structure is aligned. Many teams therefore declare a change freeze during the migration period: no structure changes, no big one-off batch jobs, and no unplanned maintenance on the source.

Another subtle point is the handling of tables without a reliable unique identifier. Change synchronization works best when each row can be identified uniquely, usually by a primary key. Tables without one can be hard to synchronize correctly, because the service cannot tell exactly which row a change refers to. Review such tables during assessment and add keys or handle them separately.

The road between old and new must exist, be wide enough, and be safe.

The three connections

• From the migration helper or service to the source.
• From the migration service to the target.
• From your network to Azure, over which the data travels.

Network options

Doing the arithmetic

Before choosing, calculate how long the initial copy will take. A rough rule: divide the data size by the realistic sustained bandwidth, not the advertised one. A database of several terabytes on a modest link may need days. Add overhead for compression, retries, and sharing the link with other users. If the number is too large, you need a faster link, a seeding approach using backup files, or a phased plan.

Firewalls and private access

Both the source and the target usually sit behind firewalls. You must allow the migration service or helper to pass. Many organizations require that traffic never crosses the public internet, so the target is placed on a private network with private endpoints, which give an Azure service a private address inside your virtual network. Migration then runs through that private path. Plan name resolution (DNS) carefully, because a private endpoint needs the right name to point to the private address.

flowchart LR
    ONP["On-premises network: source and helper"] -->|"VPN or ExpressRoute"| VNET["Azure virtual network"]
    VNET --> PE["Private endpoint for target"]
    PE --> TG["Target database"]
    VNET --> SA["Staging storage via private access"]
    FW["Firewalls on both sides"] -.-> ONP
    FW -.-> VNET
    

A migration moves your most valuable information. Treat the whole journey as a secured transport.

Protect data in transit

Data traveling between source, service, and target should be encrypted using standard secure connection protocols. Where possible, avoid the public internet and use private connections. Check that older, weaker protocol versions are disabled on both ends.

Protect data at rest

Backup files placed in staging storage are as sensitive as the database itself. Use a dedicated storage account, restrict who can read it, use encryption at rest (provided by default for Azure storage), and delete the backup files when the migration is finished and verified.

Protect credentials

• Use accounts created only for the migration, with the minimum permissions required.
• Store passwords and keys in a secret store such as Azure Key Vault, not in documents or chat.
• Prefer identity-based access (managed identities or integrated sign-in) where supported.
• Disable or delete migration accounts when finished.

Protect access to the migration itself

Anyone who can change a migration job can read or alter data in flight. Use Azure role-based access control to limit who can create or manage migration resources, require multi-factor sign-in, and log all actions.

Sensitive data and compliance

Know what personal or regulated data the database holds and where it is allowed to go. Choose target regions that satisfy residency rules. Where policy requires it, mask or exclude sensitive fields in non-production copies used for rehearsal. Keep an audit record of who migrated what and when.

What makes a migration fast or slow, and how to size the target for loading and for life afterward.

What limits speed

Scale up for the move, scale down after

A common technique is to temporarily choose a larger target size during the migration so writes run quickly, and then reduce to the right-sized level once the move and tuning are finished. Many Azure database services allow changing the size without rebuilding, though a brief reconnection may occur. Check your target’s rules and any limits on how often you can change.

Make loading efficient

• Load large tables in parallel where the tool allows it.
• Defer building non-essential indexes until after the data is loaded.
• Run heavy reads against a secondary or backup copy of the source, if available, to protect production.
• Avoid running other large jobs, like backups or index rebuilds, at the same time.
• Migrate in waves: small and simple databases first to learn, large and critical ones later.

After the move: performance may differ

Even when everything is correct, performance can feel different on the new platform. The hardware, storage speed, query optimizer version, and compatibility settings may differ. Plan a post-migration tuning stage: update statistics, review slow queries, compare against baseline timings, and adjust indexes or sizing. A baseline taken before the move makes this much easier.

A migration is only finished when you can prove that the new database is correct.

Levels of checking

Subtle differences to look for

• Character sets and sorting rules: may change how text compares or sorts.
• Date and time handling: time zone defaults and precision can differ.
• Number precision: rounding of decimals may vary between engines.
• Case sensitivity: some engines treat “Smith” and “smith” as different.
• Identity values: automatically increasing numbers must continue from the right place.

Dress rehearsal

Practice the whole migration, including cutover and rollback, at least once on realistic data. Time every step. The rehearsal result is your best estimate of the real outage, and the issues it reveals are the cheapest you will ever fix.

What to watch while a migration runs, and how to react when something goes wrong.

What to watch

Common problems and likely causes

A calm method for troubleshooting

1. Read the exact error message and the object it names.
2. Check the simple things: credentials, network, disk space, permissions.
3. Look at the logs for the migration job and for both databases.
4. Reproduce the issue on a small test, if possible.
5. Change one thing at a time and record what you changed.
6. If stuck, gather the details, such as job identifiers, timestamps, and versions, and open a support request.

Setting up alerts and a shared status view

A migration that runs overnight should not depend on someone staring at a screen. Set alerts for failed jobs, for lag above an agreed number, and for low disk space on the source and target. Send them to a channel that the whole migration team can see. Keep a simple shared status page or document that lists every database, its current state, its owner, and its next step. During a large program this single page becomes the heartbeat of the project, answering the question “where are we?” without a meeting.

Also decide in advance who has the authority to pause, resume, or abandon a migration. In stressful moments, unclear authority wastes precious minutes. A short list of names, phone numbers, and decision rights in the runbook solves this.

What a migration costs, how to keep it under control, and how to repeat it reliably for many databases.

Where the money goes

Licensing considerations

Moving database software licenses can offer savings. Microsoft has offered programs that let eligible customers use existing licenses on Azure targets at reduced rates, and rules on older products have included special support arrangements. These offers have conditions and change, so ask your licensing specialist and read current terms rather than assuming.

Automating repeated migrations

If you must move dozens or hundreds of databases, doing each by hand invites inconsistency. Use automation: command-line tools, scripts, templates, and pipelines can create targets, start migrations, check status, and run validation the same way every time. Keep migration plans and settings in version-controlled files, and give each wave a runbook with clear steps and responsible people.

flowchart TD
    INV["Inventory and assessment results"] --> WAVE["Group databases into waves"]
    WAVE --> TPL["Deploy targets from templates"]
    TPL --> RUN["Start migrations by script"]
    RUN --> MON["Monitor status centrally"]
    MON --> VAL["Run automated validation"]
    VAL --> CUT["Scheduled cutover by runbook"]
    CUT --> RET["Retire source after hold period"]
    

Strategies that experienced teams reuse, and traps that cause trouble.

Pattern: pilot, then waves

Start with a low-risk database to learn the tools, network, and process. Then move databases in waves, ordered by risk and dependency. Each wave improves the next.

Pattern: seed with backups, finish with sync

For large databases, seed the target from a full backup, which is usually faster than reading rows, and then apply log or change backups until the target is nearly current. The final cutover then only has to apply a small last portion.

Pattern: migrate applications and databases together

Databases and the applications that use them should be considered as one unit. If an application stays far away from its new database, latency can make it painfully slow. Move them close together, or confirm that the latency is acceptable.

Pattern: parallel run for critical systems

For the most critical systems, keep both old and new running for a short period with comparison checks before the old one is retired.

A checklist to follow, and a list of stumbles to skip.

Best practices

Common mistakes

These are composite examples that show typical situations. They are illustrations, not reports about specific companies.

DMS is one of several ways to move a database. Choose by size, downtime, and difference between engines.

flowchart TD
    Q["Start with your constraints"] --> A{"Can you accept a long outage"}
    A -->|"yes"| OFF["Offline migration or native backup and restore"]
    A -->|"no"| B{"Same database engine on both sides"}
    B -->|"yes"| ON1["Online migration with seeding and sync"]
    B -->|"no"| C["Convert schema, then move data with testing"]
    C --> ON2["Consider online sync after conversion is stable"]
    

A good migration is quiet: planned, rehearsed, and uneventful.

We started with a family moving house, and the picture holds true all the way through. You decide why you are moving, measure the new home, pack carefully, choose between closing for a day or moving while still living there, check every box on arrival, and keep the old keys for a while. Azure Database Migration Service is the managed moving crew that carries your data and keeps you informed. Assessment tells you what will fit, conversion tools adapt what will not, and your own testing proves that the result is right.

The deeper lesson is that technology is only part of the work. The biggest wins come from clear business goals, early assessment, tested networks, realistic rehearsals, honest validation, and calm cutovers. The tool helps with the transfer, but people make the plan.