12.3 Database Migration Design (Data Migration Service, Database Migration Assistant)

Why This Topic Matters

The official bullet here is "Recommend a solution for migrating databases." Database migrations are consistently among the highest-stakes AZ-305 scenarios because they combine a target-selection decision (which Azure data platform?) with a tooling decision (how do you actually move the data with acceptable downtime?) — and because the tooling landscape has changed significantly, which is exactly the kind of freshness trap a 2026 guide needs to call out explicitly.

2026 Tooling Reality Check (Read This Before Studying Older Material)

Older AZ-305 prep material often names the Data Migration Assistant (DMA) standalone download and the Azure SQL Migration extension inside Azure Data Studio as the primary assessment/migration tools. Both are now retired: the Azure SQL Migration extension retired February 28, 2026 along with Azure Data Studio itself, and the legacy self-hosted Azure Database Migration Service (classic) for SQL Server scenarios retired March 15, 2026. If you see a question or older resource pointing you toward downloading DMA or opening Azure Data Studio for a SQL migration, treat that as outdated — the current, unified path is the Azure Database Migration Service (DMS) experience directly in the Azure portal, which uses the same underlying technology as the Azure Arc SQL Server readiness assessment to produce compatibility recommendations before migration, with no separate assessment tool download required. Ongoing hands-on migration work now happens through Visual Studio Code with the MSSQL extension rather than Azure Data Studio.

Choosing a Target: SQL Database vs. Managed Instance vs. SQL Server on Azure VM

Exam trap: a scenario mentioning heavy use of SQL Agent jobs, cross-database queries, or linked servers with a requirement to move to a managed (PaaS) target is asking for Azure SQL Managed Instance, not Azure SQL Database — Azure SQL Database's PaaS simplicity comes at the cost of exactly those instance-level features.

Offline vs. Online Migration

• Offline migration: the source stays reachable during the data copy, but the application must stop writing before cutover; total downtime roughly equals the copy duration. Simpler, but riskier for large databases with tight maintenance windows.
• Online migration: DMS performs an initial full load, then continuously replicates ongoing transactions until you choose to cut over — downtime shrinks to the final cutover window (often seconds to minutes) rather than the full copy time. This is the answer whenever a scenario specifies a short, defined downtime window for a production database.

Non-SQL Server Engines

Azure Database Migration Service is not SQL-Server-only. It also supports migrating MySQL and PostgreSQL workloads to Azure Database for MySQL/PostgreSQL Flexible Server, and open-source-to-Azure paths exist for MongoDB workloads moving to Azure Cosmos DB. When a scenario names a specific open-source engine rather than SQL Server, the recommendation pattern is the same — assess compatibility first, then choose online or offline migration based on the allowed downtime window.

Exam Scenarios

A financial services firm has a production SQL Server database that heavily uses SQL Agent jobs and cross-database queries, and the maintenance window allows only five minutes of downtime. Recommend Azure SQL Managed Instance as the target and an online migration through Azure Database Migration Service to keep the cutover window inside five minutes.

A separate legacy application depends on a very old, OS-specific SQL Server feature (for example, FileStream combined with a Windows-authenticated linked server) with no PaaS equivalent. The only viable target is SQL Server on an Azure VM — a rehost, not a DMS-managed database migration.

Key Takeaways

• Data Migration Assistant and the Azure Data Studio SQL Migration extension are retired (Feb 28 and Mar 15, 2026); the current path is the unified Azure Database Migration Service in the Azure portal, using Azure Arc-based readiness assessment.
• Azure SQL Managed Instance is the target when SQL Agent, cross-database queries, or linked servers must be preserved in a PaaS-managed service.
• Azure SQL Database offers the lightest management overhead but requires giving up instance-scoped features.
• Online migration minimizes downtime to a short cutover window; offline migration is simpler but ties downtime to full copy duration.
• SQL Server on an Azure VM remains the only option when a feature or version has no PaaS equivalent.
• Azure Database Migration Service also covers MySQL, PostgreSQL, and MongoDB-to-Cosmos DB paths, not just SQL Server.