The DP-300 exam's migration section asks which tool to use for a given scenario. More than memorizing names, you need to understand which stage of the pipeline each tool covers. Like moving to a new home, database migration follows a sequence: assess, choose your target, move the data, then verify.
Measuring the New Space — Data Migration Assistant
Before moving, you check whether the furniture fits through the door. In database migration, that job belongs to .
DMA connects to an on-premises SQL Server instance and scans for deprecated features, syntax unsupported by Azure SQL Database, cross-database queries, and more. It produces a report with recommended fixes. Without DMA, blockers surface during the migration run itself — the equivalent of finding your furniture does not fit once the truck has already arrived.
DMA can also migrate schemas and data for small databases, not just assess them. goes a step further — it captures a workload, replays it on both source and target simultaneously, and compares query-level performance. Use DEA when you want to validate that query behavior will not regress after the migration.
Choosing the Right Destination — Target Platform Selection
Before packing, you decide what type of home you are moving into. The Azure SQL family offers three options.
is a fully managed PaaS service. It does not support SQL Server instance-level features — SQL Agent Jobs, CLR, Linked Servers, and cross-database queries are unavailable. It suits cloud-native workloads. supports most instance-level features and is the natural fit for lift-and-shift migrations. When DMA assessment reveals instance-level dependencies such as SQL Agent Jobs or cross-database ownership chaining, Managed Instance is the realistic choice. is an IaaS approach providing full OS control and custom patching schedules — at the cost of full infrastructure management responsibility.
Choosing How to Move — Azure Database Migration Service
Will you close the shop during the move, or keep it running throughout? That is the difference between offline and online migration.
is the fully managed service for actual data movement. You configure a project in Azure Portal, specify source, target, and connection details, and Azure handles the rest. stops the source database, copies all data to the target, then switches the connection. A Standard-tier DMS instance is sufficient, but downtime equals the full copy time. keeps the source running. After restoring an initial full backup to the target, it continuously applies changes via CDC or transaction log streaming. The DBA triggers a manual cutover when ready, limiting downtime to a few minutes. Online migration requires a ; Standard tier does not support it.
Everything in One Box — BACPAC
For a small move, a car trunk beats a full moving truck. packages a database's schema (DDL) and data (DML) into a single file. Export and import run through or Azure Portal.
BACPAC suits scenarios where downtime is acceptable, small databases, or development and test environment moves. If data changes during export, consistency is compromised — stop the application before exporting to be safe. For databases of several hundred gigabytes or more, the time cost makes BACPAC impractical.
A Precision Path for Managed Instance — Log Replay Service
Imagine a technician assembling furniture by following instruction sheets one by one, in strict order. works exactly that way — it replays transaction log backup files sequentially to restore a Managed Instance to a target point in time. LRS is and cannot target Azure SQL Database.
The process is straightforward: upload a full backup from the on-premises SQL Server to Azure Blob Storage, then keep uploading transaction log backups. LRS restores the full backup on the MI and replays log files in order. The database stays in state until a cutover command brings it online. LRS enables Managed Instance migration without a DMS service and allows precise manual control of the cutover window. Backup file naming must follow a convention matching transaction sequence order, and Blob Storage access permissions (SAS token or Managed Identity) must be configured correctly.
Comparison Table and Common Exam Traps
If the scenario involves assessment, choose DMA or DEA. For actual data movement, choose among DMS, LRS, or BACPAC.
| Tool | Role | Target | Downtime | |:--|:--|:--|:--| | DMA | Compatibility assessment + small migration | Azure SQL DB / MI | None (assessment only) | | DEA | Performance comparison | Azure SQL DB / MI | None | | DMS Offline | Full copy then switch | DB / MI / VM | Yes (Standard tier OK) | | DMS Online | Sync while running + cutover | DB / MI / VM | Minimal (Premium required) | | BACPAC | Portable schema + data package | Azure SQL DB / MI | Yes (small DBs) | | LRS | Sequential transaction log replay | MI only | Short (manual cutover) |
Common exam traps: DMS Online requires Premium tier — choosing Standard is a frequent wrong answer. LRS is MI-only and cannot migrate to Azure SQL Database. BACPAC effectively requires stopping the application during export to guarantee data consistency.
!4 migration tools compared
After the Move — Cutover and Post-Migration Validation
Moving the boxes does not mean the job is done. You still need to verify that everything functions correctly in the new environment.
In online migration, is a point of no return. Until cutover, the source stays live and rollback is always possible. Plan a strategy in advance — if the application connects via a DNS name rather than a direct IP, reverting is as simple as changing a single DNS record. Post-migration validation needs more than a row count comparison. Run checksum comparisons, sample record verification on key tables, and application integration tests. Enable before migration to compare query performance before and after with real data. Keep the same as the source at first, then raise it gradually.
Exam Key Takeaways
"Compatibility assessment", "deprecated feature check" -- Data Migration Assistant (DMA) "Performance comparison", "workload replay" -- Database Experimentation Assistant (DEA) "Minimize downtime", "24/7 operation", "manual cutover" -- DMS Online (Premium tier required) "Downtime acceptable", "maintenance window" -- DMS Offline (Standard tier OK) "Small database", "portability", "portable package" -- BACPAC (SqlPackage.exe) "Managed Instance only", "log chain restore", "manual cutover control" -- Log Replay Service (LRS) "Use LRS with Azure SQL Database" -- Not possible (MI only) "DMS Online with Standard tier" -- Not possible (Premium required) "Instance-level features" (SQL Agent, CLR, Linked Server) -- Azure SQL Managed Instance "Rollback after cutover" -- DNS cutover strategy "Pre- and post-migration performance comparison" -- Enable Query Store early "Compatibility level strategy" -- Match source level, upgrade gradually
DMA = pre-move compatibility check, DMS = data transport, LRS = MI-only log replay, BACPAC = small-scale portable package