The End of an Era for DMA

For years, the Data Migration Assistant (DMA) was the bread and butter for any DBA planning an upgrade. It was the tool we used to sniff out breaking changes, compatibility issues, and behavior changes before committing to a production migration. But Microsoft is consolidating their ecosystem. With the release of SQL Server Management Studio (SSMS) 21 (Preview) and the latest updates to SSMS 20, the standalone DMA is officially on notice. The functionality has been folded directly into the SSMS Migration component.

If you are still downloading the old .msi for DMA, you are wasting time. The future is integrated, Azure-connected, and frankly, a lot faster once you get past the initial learning curve. Here is the practical reality of using the new SSMS Migration component to move your workloads to SQL Server 2022 or Azure SQL.

Why Microsoft Made the Move

Standalone tools are a maintenance nightmare. By moving the migration assessment engine directly into SSMS, the engineering team can push updates to the rulesets (like new T-SQL syntax blockers) without requiring you to install a separate application.

The new component isn't just a UI skin; it leverages the underlying assessment engine seen in the Azure Data Studio migration extension. It provides a more streamlined path for those moving from on-premises to Azure SQL Database, Azure SQL Managed Instance, or even just a higher version of SQL Server on-premises. The core benefit resides in the 'Assess' functionality, which has become significantly more granular regarding feature parity and 'Cloud-readiness.'

Getting Started with the Migration Component

To use the new workflow, you need to be on at least SSMS 20, though SSMS 21 is where the deeper integration resides. In the Object Explorer, you simply right-click the database you intend to migrate and navigate to Tasks > Migrate to Azure SQL.

Wait, what if you aren't going to Azure? Even if your target is a local instance of SQL Server 2022, the assessment engine remains the most powerful way to check for 'Deprecated features' and 'Compatibility level' blockers. The UI will prompt you to create a new migration project. Unlike the old DMA which felt like a wizard you ran and forgot, the new component treats migrations as a persistent project that you can save and return to.

Running the Assessment: Production Reality

When you start the assessment, you have two primary categories: Assessment and Migration. Never skip the assessment. I've seen junior DBAs try to jump straight to the migration phase only to have the process fail four hours in because of a legacy CLR trigger or an unsupported cross-database query.

The assessment engine checks for:

1. Breaking Changes — T-SQL syntax that worked in 2012 but will fail in 2022.

2. Behavior Changes — Code that works but might return different results due to cardinality estimator updates.

3. Feature Parity — Ensuring features like Filestream or certain Broker configurations exist on your target Azure target.

One pro-tip for production DBAs: the assessment can be resource-intensive if you choose to include 'extended events' for workload analysis. If you are running this against a heavily loaded production server, stick to the schema-only assessment first. This will catch 95% of your problems without impacting the buffer pool or CPU cycles significantly.

Navigating the Assessment Results

The output of the SSMS Migration component is categorized by the target platform. If you select 'Azure SQL Database', the tool will be ruthless. It will flag every single unsupported system-level call. If you are migrating from SQL 2016 to SQL 2022 on-premises, the results will be much leaner, focusing primarily on deprecated syntax.

The Issue Details pane is where the real value lies. It doesn't just tell you that your code is broken; it provides the specific line number and a link to the documentation on how to fix it. This is your punch-list. Before you even think about the 'Migrate' button, every 'Critical' issue in this report must be resolved in your source or staging environment.

Executing the Migration

Once the assessment is green, the migration component offers a seamless way to move data. For smaller databases, the offline migration (which takes a backup and restores it) is fine. For mission-critical systems, the component integrates with the Azure Database Migration Service (DMS) for an online migration. This uses Log Replay to keep the target in sync with the source until you are ready for the cutover.

The cutover process in the new SSMS extension is much more robust than the old DMA. It handles the tail-log backup and the final restore to the target, ensuring zero data loss during the transition. If you are moving to an Azure VM or an on-premises instance, you are still essentially performing a backup/restore, but the automation within SSMS handles the connection string validation and user mapping that usually trips people up.

The Verdict

Is the SSMS Migration component perfect? No. It still feels a bit 'heavier' than the lightweight DMA app. However, the depth of the assessment and the integration with Azure services make it a superior tool for the modern DBA. Stop looking for the DMA download link. Open SSMS, right-click your database, and start getting used to the new workflow. The automation of the assessment reports alone will save you dozens of hours in your next upgrade cycle.