AZ-305 database migration questions are usually not asking you to name a tool first. They are asking whether you can design the migration path from the constraints: source engine, target fit, compatibility findings, downtime budget, backup location, validation, and cutover risk.
The exam decision model is simple: assess before you choose, verify before you promise downtime, and validate before you cut over.
Start With Target Fit
For SQL Server estates, assessment output is the design input. Use compatibility findings, instance-level dependencies, database schemas, performance data, and target recommendations to decide whether the answer should be Azure SQL Database, Azure SQL Managed Instance, or SQL Server on Azure VM.
Azure SQL Database is a strong modernization target when the workload fits the platform constraints. Azure SQL Managed Instance is often a better fit when the estate needs broader SQL Server compatibility or instance-level features. SQL Server on Azure VM keeps the most operating-system and instance control, but it also keeps more management responsibility.
For heterogeneous sources, do not force the same SQL Server migration path. Source-specific tooling such as SQL Server Migration Assistant can be part of the assessment and conversion plan for engines such as Oracle, MySQL, Db2, Access, or SAP ASE.
Use Downtime as the Main Split
After target fit, ask what outage the business can tolerate. Offline migration means downtime starts when migration starts. Online migration reduces downtime to the final cutover only when the source-target scenario supports that mode.
That support check matters. Current Microsoft Learn guidance for Azure SQL Database with Azure Database Migration Service is an offline path, and it states that online migrations to Azure SQL Database are not available through DMS. If the scenario requires minimal downtime, the target or method may need to change.
For Azure SQL Managed Instance, Managed Instance link is an exam-relevant online migration alternative to an offline copy when the scenario supports it.
Worked Scenario
A company runs several on-premises SQL Server databases. The assessment shows some instance-level dependencies, and the business wants to keep the final outage short. The team first considers Azure SQL Database because it is a managed PaaS target.
For AZ-305, that is not enough. The dependencies and compatibility findings must drive target choice. Azure SQL Managed Instance may fit better than Azure SQL Database if the workload needs instance-level compatibility. The downtime requirement then changes the migration method: an offline DMS copy may be valid when downtime is acceptable, but a short-cutover requirement for Managed Instance should make you evaluate Managed Instance link where supported.
If the source backups are stored in an on-premises SMB share, plan for the DMS self-hosted integration runtime. If backups are already in Azure Blob Storage, do not add SHIR just because the word "migration" appears in the scenario. Also do not reuse an Azure Data Factory self-hosted integration runtime for DMS database migration.
The final architecture answer should include schema migration, application compatibility testing, data consistency checks, monitoring, cutover, and rollback readiness. A plan that only moves data is incomplete.
Compact Exam Rules
Use these rules to keep the answer defensible:
| Scenario signal | Better exam move |
|---|---|
| Compatibility findings or instance dependencies are mentioned | Choose the Azure SQL target from assessment output, not from a service keyword. |
| Source and target are not both SQL Server family | Consider source-specific assessment and conversion tooling such as SSMA. |
| Downtime can begin when migration starts | Offline migration can be acceptable if the source-target scenario supports it. |
| Minimal downtime is required | Verify online support for that exact target and method before recommending it. |
| Target is Azure SQL Database with DMS | Treat the current DMS path as offline. |
| Backups are in an on-premises SMB share | Use DMS self-hosted integration runtime. |
| Backups are already in Blob Storage | Do not add SHIR solely for backup access. |
One major trap: "Use Azure Database Migration Service" is not a complete answer. DMS can be the right enterprise migration service for large or complex moves, but the exam answer still needs supported source-target mode, compatibility, downtime, plumbing, validation, and rollback.
Quick Recap
If the interactive components do not load, remember the core sequence: assess the source estate, choose the target from compatibility and operating-model needs, verify supported source-target migration mode, split the method by downtime budget, prepare network and backup access, then validate schema, application behavior, data consistency, monitoring, cutover, and rollback.
Ready to test this under realistic constraints? Take the targeted AZ-305 assessment and look for migration scenarios where the right answer changes because of compatibility findings or downtime limits.
