A SQL Server migration assessment tells you what's compatible with your target Azure platform, what will break, and what size infrastructure you actually need. Done properly, it takes the guesswork out of migration planning. Done poorly, or skipped entirely, it creates months of post-migration firefighting.

Here's how we run assessments at DBA Services, including the performance baselining that most guides either rush through or ignore completely.

What Happened to the Data Migration Assistant?

If you've run SQL Server migration assessments before, you probably used Microsoft's Data Migration Assistant. That tool is gone. Microsoft officially retired DMA on 16 July 2025, and it's no longer available for download.

The replacement is split across three tools:

  • Azure Migrate with the Azure SQL assessment feature handles discovery and compatibility checks at scale across large environments
  • Azure Data Studio with the Azure SQL Migration extension covers assessment, SKU recommendations, and the actual migration process
  • Azure CLI (az datamigration) handles scripted performance data collection and SKU sizing for automated or repeatable workflows

One thing worth knowing: Azure Data Studio itself is on a deprecation path, with Microsoft steering users toward VS Code with the MSSQL extension. The migration extension still works in Azure Data Studio for now, but that's worth monitoring if you're building repeatable processes around it.

If you have old DMA reports or scripts that depended on it, those need replacing. The newer toolset is genuinely better for performance-based sizing, which was always DMA's weakest area.

What Does a SQL Server Migration Assessment Actually Cover?

A proper assessment covers four distinct areas, in this order:

  1. Discovery - what SQL Server instances and databases exist in your environment
  2. Compatibility - what features or syntax won't work on your target platform
  3. Performance baselining - what your workload actually demands under real conditions
  4. SKU sizing - what Azure tier and service objective you need to match current performance

The order matters. You can't size accurately without a performance baseline. You can't assess compatibility without knowing which databases and features you're dealing with. Teams that jump straight to SKU selection based on current on-premises specs consistently end up either over-provisioned or, more painfully, under-provisioned after go-live.

Step 1: Discovery

Before you assess anything, you need to know what you have. This sounds obvious, but we regularly find undocumented SQL Server instances during discovery, sometimes running production workloads nobody has touched in years.

Azure Migrate handles discovery well at scale. Deploy the Azure Migrate appliance in your network, point it at your IP ranges or provide a list of server names, and let it scan. It picks up SQL Server instances, versions, databases, and basic configuration details.

For smaller environments, you can skip the appliance and connect directly through the Azure SQL Migration extension in Azure Data Studio. Connect to each instance and it pulls the database inventory.

What you need out of discovery:

  • Every SQL Server instance and version in scope
  • Database sizes and counts per instance
  • Current edition and licensing details
  • Features in use: replication, Service Broker, CLR assemblies, linked servers, SQL Agent jobs, SSIS packages

That feature inventory is critical. Linked servers, Service Broker, CLR, SQL Agent jobs, and SSIS packages don't migrate automatically to Azure SQL Database. Some work on Managed Instance. All of them need a documented plan before you commit to a target platform.

Step 2: Compatibility Assessment

This is where you find out what breaks. The Azure SQL Migration extension runs compatibility checks against your chosen target: Azure SQL Database, Azure SQL Managed Instance, or SQL Server on Azure VM.

Run the assessment against each target type, not just the one you're planning to use. The results fall into two categories:

  • Breaking issues: features or syntax that won't function on the target platform. Cross-database queries against Azure SQL Database are a common example.
  • Behavioural changes: things that technically work but behave differently, such as collation handling, tempdb configuration differences, or changes in how certain trace flags operate.

In our experience, most databases targeting Managed Instance pass with minor issues. Azure SQL Database is considerably more restrictive. If you're using cross-database queries, CLR, or Service Broker, Managed Instance or SQL Server on Azure VM are your realistic options.

Don't just run the tool and forward the report to stakeholders. Read the issues, classify them by remediation effort, and use that to validate whether your target platform choice still makes sense. A database with 40 breaking issues against Azure SQL Database might be a two-hour fix or a two-month project, depending on what those issues actually are.

Step 3: Performance Baselining

This is the step most teams rush, and it's the one that causes the most pain after migration. Sizing based on current CPU and RAM specs without understanding actual workload behaviour is how you end up with an Azure SQL instance that can't handle month-end processing or an expensive tier that's idle 90% of the time.

A proper performance baseline captures data over a representative period, typically a minimum of one full business cycle. For most organisations that means at least one week, and ideally two to four weeks that include any known peak periods such as month-end, payroll runs, or batch processing windows.

What to collect:

  • CPU utilisation (average and peak, not just average)
  • Memory usage and page life expectancy trends
  • Disk I/O: reads, writes, and latency at the database and file level
  • Wait statistics, particularly for PAGEIOLATCH, CXPACKET, and SOS_SCHEDULER_YIELD
  • Active connection counts and peak concurrency

The Azure CLI az datamigration performance-data-collection command automates this collection and feeds directly into the SKU recommendation engine. For environments where you need more granular query-level data, Query Store combined with DMV queries against sys.dm_exec_query_stats and sys.dm_os_wait_stats gives you the detail you need to understand what's driving resource consumption.

Don't baseline during a quiet period and call it done. If your busiest day of the month is the 1st, make sure the baseline captures it.

Step 4: SKU Sizing

With a real performance baseline in hand, SKU sizing becomes a data-driven exercise rather than a guess. The Azure SQL Migration extension uses the collected performance data to recommend a service tier and compute size.

Treat the recommendation as a starting point, not a final answer. Factor in:

  • Growth projections over the next 12 to 24 months
  • Any workload changes planned post-migration
  • Whether you need reserved capacity pricing (which requires committing to a specific tier)
  • High availability requirements, since Business Critical tier includes a read replica that General Purpose does not

For Managed Instance specifically, check the instance-level resource limits carefully. A single Managed Instance has a maximum of 80 vCores and 400 GB of memory in the Business Critical tier. If your consolidated workload exceeds those limits, you're looking at multiple instances or SQL Server on Azure VM.

Key Takeaways

  • DMA is retired as of July 2025. Use Azure Migrate and the Azure SQL Migration extension in Azure Data Studio for all new assessments.
  • Run assessments against multiple target types (Azure SQL Database, Managed Instance, SQL Server on Azure VM) before committing to a platform. The compatibility results often change the decision.
  • Performance baselines must cover at least one full business cycle, including peak periods. Sizing from average utilisation alone is a common and expensive mistake.
  • The feature inventory from discovery (linked servers, CLR, Service Broker, SSIS, SQL Agent jobs) determines your realistic target platform options before compatibility assessment even runs.
  • SKU recommendations from the tooling are a starting point. Adjust for growth, workload changes, and HA requirements before finalising.

DBA Services has been running SQL Server migration assessments for Australian organisations for over 20 years. If you're planning a move to Azure and want an assessment done properly, get in touch with our team.